Merge ICS
BetaDrop several .ics calendar exports and download one combined .ics for a single import or archive. Every event is kept by default, each time zone is written once, and an optional dedupe keeps the newest copy of an event that appears in more than one file. Nothing is uploaded.
- Free, no sign-up
- REST + MCP
- Updated
- Reviewed by Olgun Ozoktas
Leave it empty to keep the name every file agrees on, or no name when they differ.
The merged calendar will appear here..
Why Merge ICS Files in the Browser?
An iCalendar file is one VCALENDAR component holding a header, zero or more VTIMEZONE definitions, and the events, to-dos and journal entries themselves. Merging is a matter of reading every file into that tree, keeping the first VTIMEZONE seen for each TZID, and writing every other component back out under one new header. This page does exactly that. Each component is written with every property it arrived with: recurrence rules, exception dates, alarms, attendees, descriptions, locations and vendor X- properties. The long lines are folded again at 75 octets, and a parameter value that holds a comma, colon or semicolon is written back in quotes, as the format requires.
The header of the merged calendar is rebuilt. VERSION is 2.0 and the PRODID names this tool. CALSCALE and METHOD are kept when every file that states them agrees, and set to GREGORIAN and PUBLISH when they do not. The calendar name is the one you type, else the name every file agrees on, else none. The X-WR-TIMEZONE hint is kept when the files agree on it. Up to twenty files can be merged at once.
Duplicates are your call. By default every copy stays, which is what the popular merge tools do too. With the UID dedupe on, the tool keeps one component per UID and RECURRENCE-ID, choosing the newest by LAST-MODIFIED, then DTSTAMP, then SEQUENCE, and leaves it in the place the first copy held so the file order survives. With New UIDs on, every UID becomes a new deterministic identifier of the form [email protected]; a recurrence master and its exceptions keep sharing one. Recurrence rules are never expanded, no calendar URL is fetched, and the files never leave the browser.
How it compares
Importing calendars one by one works when there are two. With a Google export of six or eight calendars it means six or eight import dialogs, and a re-import later means doing them again. A text editor can join the files, but one broken folded line or a duplicated VTIMEZONE block is enough for an importer to refuse the whole file. Online merge sites upload the calendars to do the same job. This page reads the standard format with its folding and escaping rules, writes one valid calendar, and keeps the files in the tab.
Merge Tips
- File order is output order. Drop the calendar you want first, first; the events inside each file keep their own order.
- The dedupe key is the UID together with the RECURRENCE-ID, so a modified occurrence of a recurring meeting is never mistaken for a duplicate of the whole series.
- Every property is copied as read: RRULE, EXDATE, VALARM, ATTENDEE, DESCRIPTION, LOCATION and the X- properties a calendar app adds. Only the calendar header is rebuilt.
- A time zone definition (VTIMEZONE) is written once per TZID even when every file carries a copy. The times themselves are never converted; each keeps the zone it was stated in.
- A file that is not a calendar is reported next to its name and skipped. The other files still merge.