ICS Calendar Merger

An ICS merger combines several event exports into one calendar file without placing complete VCALENDAR wrappers one after another. Choose your .ics files to collect supported events and embedded time-zone definitions, skip identical events, and review conflicts before downloading. This ICS merger identifies a recurring instance by its UID together with RECURRENCE-ID, so a changed occurrence is not mistaken for the whole series. Conflicting versions stop the merge rather than letting file order silently choose the event you keep.

How the ICS merger combines calendars

A standalone iCalendar file has its own wrapper and header. Simply concatenating two complete files does not create one coherent calendar. This ICS merger parses the sources, gathers the supported components and writes one new .ics document. It preserves event data and embedded time-zone definitions within the supported scope.

The supported components are VEVENT and VTIMEZONE. Tasks, journal entries and other calendar component types are excluded. If your exports contain reminders represented as tasks rather than event properties, merging them here is not a complete backup of every component. Retain the original files for those wider uses.

Merge several files and review the result

1. Select Choose file and choose the .ics exports you want to combine. The interface supports multiple selected files.
2. Review the file-order list. Use its Up and Down controls when you want to change the input order.
3. Select Process files after changing the selection or order. File selection also starts local processing.
4. Inspect the merge summary and any conflict messages before downloading the resulting calendar.
5. Import the download into a temporary calendar first and compare representative events with the originals.

The example control demonstrates a short recurring event. For a meaningful test of your own merge, use two small exports containing a known meeting and a known recurrence exception. A correct file structure does not establish that the calendar app will apply your preferred overwrite behavior when importing into an existing account.

Duplicates: UID is more reliable than a title

Suppose export A and export B both contain an identical event with UID:meeting-1@example.test. The ICS merger keeps one matching event instead of writing two identical copies. If those events have different titles or dates but the same identity, it reports a conflict and stops for review.

Two events titled “Weekly planning” are not automatically duplicates when they have different UIDs. They may be two independently created appointments. This ICS merger does not perform fuzzy title-and-time matching or choose the “newest-looking” event from display text. Review duplicate-looking appointments in your source calendar when their identifiers are different.

Recurring events and time zones

A changed occurrence in a recurring series usually shares the master’s UID but carries a RECURRENCE-ID identifying that occurrence. The merger uses both values in its event identity. This allows the master and its separately changed instance to coexist, rather than discarding the exception as though it were a redundant copy of the series.

Embedded time-zone definitions are preserved, but two different definitions for the same TZID require review. Choosing one silently could move meetings in the other source. The merger therefore stops on that conflict. It does not contact a calendar service or remotely replace a source definition with one assumed to be correct.

Troubleshooting and checking before import

If parsing fails, confirm each source is a genuine calendar export with correctly closed components. Do not rename a CSV to .ics or paste one event into a wrapper by guesswork. For a spreadsheet schedule, CSV to ICS conversion is the appropriate starting point and has its own date and time-zone limits.

Use the ICS structural validator to investigate basic line and component errors. To inspect calendar rows in a spreadsheet, export ICS to CSV, but remember that a table export is not a lossless replacement for recurrence rules, exceptions and other calendar properties.

The merger operates locally and creates a downloadable result; it does not subscribe to calendar feeds or synchronize an account. For the full format model, see RFC 5545. Before a full import, compare an all-day event, an event near a daylight-saving transition and a modified recurrence occurrence in a temporary calendar. Delete that test calendar only after you have confirmed the intended result.

Common ICS merger errors and how to fix them

When the ICS merger cannot use a file, it stops with one clear message instead of producing a half-finished download. These are the problems people run into most often, with the fix for each:

• Calendars contain different versions of the same event. Resolve the conflict first. Two files contain the same UID (and recurrence ID) with different details. The merger stops instead of choosing one.
• A time zone is missing or has conflicting definitions. Two files define the same TZID differently.
• The calendar or recurrence rule is malformed. One of the files is not a complete VCALENDAR.
• A warning that an identical event was skipped Exact duplicates are merged once and listed.

Privacy: the ICS merger runs in your browser

ICS merger processing happens with JavaScript in a background worker on this page. Your file is not uploaded to a FileFix server, and the results you download are created in your browser’s memory. Calendars reveal meetings, names and locations, so local processing keeps that schedule private. When you finish on a shared computer, clear the selection or close the tab.

Sources

• RFC 5545 (iCalendar)

Questions about this tool