Split ICS

Entries per part

Calendar name prefix

Importers differ in how much they accept at once. Start at 250; go smaller if an import still fails.

Parts

Paste the calendar text here, or upload a .ics file..

How to Split an ICS File Online

Upload the .ics file or paste its text

The page counts the entries and the time zone definitions it holds.
Pick how many entries each part may hold

250 is the default; use a preset or type your own. Importers differ, and no limit is assumed.
Name the parts if you like

With a prefix, each part is titled Name (part 1 of 3) so the imports are easy to tell apart.
Download the ZIP and import the parts one at a time

When the calendar fits in one part, the page offers the single .ics instead of a ZIP with one file.

Common Use Cases

Import failures

a Google Calendar import that hangs or stops partway accepts the same events in smaller parts.

Old archives

a decade of events exported from a desktop app, imported in yearly-sized pieces.

Shared calendars

a team calendar that is too large for a colleague's import limit.

Migration

move a large calendar between services without one all-or-nothing import.

Testing

cut a real export down to a few hundred entries to try an import before committing to the whole file.

Why Split an ICS File in the Browser?

A big calendar export is the one that fails to import. A calendar app times out, rejects the file, or imports a fraction of it and says nothing, and the usual advice is to split the file into smaller ones. Doing that by hand means cutting VEVENT blocks out of a text file, keeping every part a valid calendar with its header and its time zone definitions, and never cutting a recurring series in half. This page does the cut for you: pick how many entries each part may hold, and download a ZIP of complete .ics files to import one at a time. The calendar never leaves your browser.

An iCalendar file is one VCALENDAR with a header, optional VTIMEZONE definitions, and the entries: VEVENT, VTODO and VJOURNAL components. Splitting it well means each part must be a valid calendar on its own. This page copies the source header into every part (adding VERSION and PRODID if the source lacks them), keeps the entries in file order, and cuts them into parts of at most the chunk size you choose. Entries that share a UID, which is how a recurring master and its modified occurrences are linked, are treated as one unit and are never separated; when a unit does not fit in the current part, it starts the next one.

Time zones are handled per part. Each part carries only the VTIMEZONE definitions that its own entries reference through a TZID parameter, so a part whose events are all in UTC carries none, and a part with events in two zones carries both. The times are copied as stated and never converted.

The output is a ZIP of part-001.ics, part-002.ics and so on, named after the uploaded file, with a table showing the events in each part and its size. If you give a name prefix, each part is titled with it and its position, such as Work (part 2 of 5), so the imports are easy to tell apart. When the whole calendar fits in one part, the page offers a single .ics download instead. Recurrence rules are never expanded, no limit of any importer is assumed, and the file never leaves the browser.

How it compares

Splitting a calendar in a text editor is possible and slow: every part needs the header, the right VTIMEZONE blocks, and unbroken folded lines, and a recurring series cut across two files imports as two broken ones. Online splitters that upload the calendar do the same job on a server. This page reads the standard format, keeps every part valid, keeps series whole, and keeps the calendar in the tab.

Splitting Tips

Every part is a complete calendar: the source header, only the VTIMEZONE blocks its own entries reference, and the entries themselves, written exactly as they were read.
A recurring series is never split. The master event and any modified occurrences share a UID and always land in the same part, which can make a part slightly smaller than the chunk size.
Entries are cut in file order, and file order is kept inside each part. Nothing is sorted.
The chunk size counts entries: events, to-dos and journal entries alike. The parts table shows the events in each part.
Part files are named part-001.ics, part-002.ics and so on, and the ZIP is named after the uploaded file.

Frequently Asked Questions

Why does my calendar app refuse to import a large .ics file?

Calendar apps and web importers differ in how much they accept in one request, and most do not publish the limit; an import can time out, be rejected, or stop partway with no message. The practical fix is smaller files. This page cuts the calendar into parts of a size you choose, and if a part still fails, pick a smaller chunk and try again. No specific limit is claimed here, because none is guaranteed.

What chunk size should I choose?

Start with the default of 250 entries per part. If an import still fails, halve it. If every part imports easily and there are many of them, double it. The chunk size counts entries of every kind: events, to-dos and journal entries. The table under the input shows how many events each part holds and how large each part is, so you can judge before downloading.

Is each part a valid calendar on its own?

Yes. Each part starts with BEGIN:VCALENDAR and ends with END:VCALENDAR, carries the source header properties (VERSION, PRODID, CALSCALE, METHOD and the X-WR- hints), holds only the VTIMEZONE definitions its own entries reference, and then the entries themselves, written exactly as they were read. A part imports on its own, in any order. To take titles, links and attendees out of the parts before sharing them, drop them all on ICS Privacy Scrub, which applies the same rules to every file.

What happens to recurring events?

A recurring series stays in one part. The master event and any modified occurrences share a UID, and entries with the same UID are moved as one unit; when the unit does not fit in the part being filled, it starts the next one. That is why a part can hold slightly fewer entries than the chunk size. Recurrence rules are copied as text and never expanded into occurrences.

How are time zones handled?

Each part carries only the VTIMEZONE blocks that its own entries reference through a TZID parameter. A part whose events are all in UTC carries none; a part with events in Europe/Istanbul and America/New_York carries both definitions. Times are copied as stated, with their TZID or trailing Z, and are never converted between zones; to restate them in another zone, use ICS Timezone Convert.

What are the parts named?

Inside the ZIP the files are part-001.ics, part-002.ics and so on, and the ZIP is named after the uploaded file with -split added. If you type a calendar name prefix, each part's X-WR-CALNAME becomes the prefix and its position, such as Work (part 2 of 5), which some calendar apps show as the calendar title on import. Without a prefix, the source calendar's own name is copied into every part.

Why do I get a single file instead of a ZIP?

Because the whole calendar fits in one part at the chunk size you chose, so there is nothing to split. The page then offers the single .ics rather than a ZIP holding one file. Pick a smaller chunk size to get several parts.

Does splitting change the order of my events?

No. Entries are cut in file order and keep that order inside each part. Nothing is sorted by date, so the first part holds the first entries of the file, whatever their dates. Sorting a calendar before splitting it is a different job; the ICS to CSV tool can show you the dates in order first.

Is my calendar uploaded anywhere?

Not on this page. The file is read, split and packed into the ZIP in your browser, and no request carries the calendar text. You can confirm that in the browser's network panel while splitting. The API is a separate path: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

Can I split calendars from a script?

Yes. The same code runs on the FindUtils API and MCP server as the split_ics tool. Send the .ics text as input with chunk_size and an optional name_prefix, and read the parts array, which holds one complete .ics text per part, along with the per-part event counts.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/split-ics/execute \
  -d '{"input":"BEGIN:VCALENDAR\nVERSION:2.0\nBEGIN:VEVENT\nUID:[email protected]\nDTSTART:20260903T093000Z\nSUMMARY:Standup\nEND:VEVENT\nBEGIN:VEVENT\nUID:[email protected]…'

$ claude mcp add findutils \
  --transport http https://mcp.findutils.com/
# then call findutils:split_ics

The REST API and the MCP tool are a separate path from this page: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

API reference Add to Claude