How to Split a Large ICS File for Google Calendar

To split a large ICS file for Google Calendar, keep each recurring series together and put every output inside its own complete calendar wrapper. Include the time-zone definitions that its events reference. Cutting at an arbitrary line or month boundary can separate an exception from its master event.

Google currently documents an import limit of 1 MB or smaller. Its first suggestion for oversized files is to export a shorter date range from the source application (Google import troubleshooting, checked November 5, 2026).

Key Takeaways

• Measure each finished file in bytes, including its calendar wrapper and time-zone definitions.
• Group the master event and its exceptions by UID.
• Preserve recurrence rules, excluded dates, alarms, and referenced time zones.
• If one complete series exceeds the limit, ordinary grouping cannot solve the problem.

Start with the least complicated export

Keep the full original export. Check whether the source application can export only the calendar or period you need. Examine the result: a date-range option can affect how a recurring series is represented, so a smaller file still needs verification.

If you must partition the file yourself, use an iCalendar-aware parser or editor. A line-based split command does not understand component nesting. Even selecting a complete VEVENT is insufficient when a related override appears elsewhere in the file.

Aim below the documented size ceiling, rather than depending on a particular interpretation of “MB.” Measure the final encoded bytes, not the character count or the compressed ZIP size.

Treat a recurring series as one group

Use the master and all overrides sharing its UID as the basic grouping unit. An override's RECURRENCE-ID identifies its original occurrence slot, even when its new DTSTART moves it to another date. These relationships are defined in RFC 5545's recurrence identifier.

This complete synthetic file contains a year-end weekly series, a moved instance, and an unrelated event. Save copied ICS examples as UTF-8 with CRLF line endings.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CalendarLint//Series Split Example//EN
BEGIN:VTIMEZONE
TZID:Example/Fixed-Plus-One
BEGIN:STANDARD
DTSTART:19700101T000000
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:year-end-review@example.test
DTSTAMP:20261105T000000Z
DTSTART;TZID=Example/Fixed-Plus-One:20261228T090000
DTEND;TZID=Example/Fixed-Plus-One:20261228T093000
RRULE:FREQ=WEEKLY;COUNT=3
SUMMARY:Year-end review
END:VEVENT
BEGIN:VEVENT
UID:year-end-review@example.test
DTSTAMP:20261105T000000Z
RECURRENCE-ID;TZID=Example/Fixed-Plus-One:20270104T090000
DTSTART;TZID=Example/Fixed-Plus-One:20270105T100000
DTEND;TZID=Example/Fixed-Plus-One:20270105T103000
SUMMARY:Year-end review moved
END:VEVENT
BEGIN:VEVENT
UID:archive-check@example.test
DTSTAMP:20261105T000000Z
DTSTART;TZID=Example/Fixed-Plus-One:20270106T140000
DTEND;TZID=Example/Fixed-Plus-One:20270106T143000
SUMMARY:Archive check
END:VEVENT
END:VCALENDAR

Example/Fixed-Plus-One is a deliberately synthetic fixed-offset zone, defined inside this file. It is not a Windows or IANA identifier, and it does not model daylight saving time.

The series starts on December 28, 2026. Its January 4 occurrence moves to January 5 at 10:00; January 11 stays at 09:00. The unrelated archive event is on January 6.

A split between December and January could strand the moved occurrence. Grouping by the shared identity preserves the relationship.

Build two complete output calendars

For this example, create the outputs by copying whole components without editing their contents:

| Output | Calendar-level properties | Components to copy | | --- | --- | --- | | part-a.ics | VERSION and PRODID | The complete VTIMEZONE, master review, and moved review | | part-b.ics | VERSION and PRODID | The complete VTIMEZONE and archive check |

Each starts with BEGIN:VCALENDAR and ends with END:VCALENDAR. Copy the entire time-zone block into both because both outputs reference it.

For a real export, preserve applicable calendar-level properties as well. Keep nested VALARM components with their events. Retain other component types or flag them for separate handling; do not silently discard tasks or journals because this example contains only events.

This grouping produces two valid calendar objects from the sample. It demonstrates preservation, not compression: duplicated wrappers and shared definitions can make the combined output size larger than the original.

Verify identity and date coverage before importing

A useful check compares more than event counts:

| Check | Original | part-a.ics | part-b.ics | | --- | --- | --- | --- | | Event records | 3 | 2 | 1 | | Review master | Present | Present | Absent | | Moved review override | Present | Present | Absent | | Referenced zone definition | Present | Present | Present | | Review dates after applying the override | Dec 28, Jan 5, Jan 11 | Same | None | | Archive date | Jan 6 | None | Jan 6 |

For each real output, verify that every input event belongs to exactly one group, every time-zone reference resolves, and every nested component survived. Compare the union of output identities with the input identities. Then inspect actual occurrences around exclusions, moved instances, year boundaries, and daylight saving transitions.

Use CalendarLint to review the output files and their source. CalendarLint is an inspection step here; this workflow does not claim that it automatically splits exports.

When one series is still too large

Do not delete exceptions or shorten an unlimited recurrence rule just to meet a file-size target. Those operations change the calendar.

Return to the source application for a smaller or purpose-built export. If you intentionally materialize a bounded period into individual events, document that this creates a snapshot with different recurrence and update behavior. It needs a separate migration design.

Import each finished part into a temporary Google calendar once. Check representative dates and moved instances before using the files in your working calendar. If the response is ambiguous, follow the zero-events diagnostic checks.

Verification scope: the synthetic input and both grouping outputs were parsed locally with ical.js 2.2.1 on November 5, 2026. Group membership, time-zone references, and the listed occurrence starts were checked. Google imports and large production exports were not tested.