What is an ICS file?

ICS is a plain-text format you can open in any editor. It is used for moving data between programs.

The extension is .ics, and the full name is iCalendar. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1998. The specification is RFC 5545.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

ICS stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

Google Calendar, Apple Calendar and Microsoft Outlook read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

ICS is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

An ICS file is either an event you were sent or a calendar you subscribe to, and almost every problem with the format starts by mixing them up.

The first is the invitation attached to an email. It describes one appointment — or a small series — and it is meant to be opened once and imported. The second is a feed at a web address that a calendar application fetches repeatedly: a timetable, a fixture list, a rota, a public-holiday calendar. It is the same file structure both times, and the difference in how it is used is total. A subscription that is downloaded and imported instead becomes a frozen copy that never updates again, which is the single most common mistake.

Plain text, in a structure old enough to look like it: one property per line, all capitals, wrapped at 75 characters with a continuation convention that puts a single space at the start of the next line. Each event sits between BEGIN and END markers with a start, an end, a summary, usually a description and a location, and a unique identifier.

That identifier is the part that behaves in a way people do not expect. It is how a calendar recognises an update as belonging to an existing appointment rather than a new one, so re-sending an invitation with the same identifier moves the original rather than creating a duplicate. Send it with a fresh identifier and everybody now has two meetings.

An event can record its time in three ways, and they behave differently. A local time with no zone means "ten o’clock wherever you are", which is right for a birthday and wrong for a meeting. A time in UTC, marked with a trailing Z, is a fixed moment that every calendar converts to the reader’s own zone. A time with a named zone carries a whole timezone definition inside the file so that the conversion holds even across a daylight-saving change.

An appointment that lands an hour out for some attendees and not others is almost always this: an event written as local time by a system that assumed everyone was in one country. An appointment that was right until the clocks changed is the same fault a level deeper — a fixed offset was recorded where a named zone belonged.

Repetition is described by a rule rather than by writing out every occurrence: every second Tuesday, the last Friday of the month, every weekday until a date. It is compact and it is exact, and it is the reason a year of standup meetings is a few hundred bytes.

What makes it complicated is exceptions. A cancelled occurrence and a single meeting moved to a different day are both stored as amendments to the series, and applications differ in how completely they implement that. This is why moving one instance of a recurring meeting sometimes moves all of them in somebody else’s calendar — the rule survived the journey and the exception did not.

For a one-off file, all three do the same thing: an import that copies the events in once. In Google Calendar it is under Settings, Import and export; in Outlook it is File, Open and Export; on a Mac it is File, Import. Choose which calendar receives the events before confirming, because separating them out afterwards is tedious.

For a feed, use the subscribe option instead and give it the address rather than a downloaded file. Google calls it "From URL", Apple calls it a calendar subscription, Outlook calls it "Subscribe from web". The calendar then re-fetches on its own schedule, which Google and Outlook measure in hours and do not let you set; Apple exposes an auto-refresh menu on the subscription that goes down to five minutes. A change at the source is not visible immediately, and that is normal rather than broken.

Any system that books something — a ticketing platform, a booking form, a course registration — eventually needs to attach an ICS so the customer can put it in their calendar. Three details separate one that works from one that generates support tickets.

Use a named time zone rather than a bare local time, or a UTC instant if the event has a single fixed moment. Keep the unique identifier stable across the confirmation, the reminder and the change notice, so updates land on the existing appointment. And attach the file with the correct media type — sent as a generic binary attachment, mail clients show it as a file to download rather than an invitation to accept.

It is text, so any editor opens it, and for a single event that is often the fastest way to see what a calendar is actually being told. The line-wrapping convention is the one thing to respect: a continued line starts with a single space, and removing that space silently changes the property.

Editing is reasonable for a quick fix — a wrong date, a typo in the title, a summary that has to be anonymised before the file is shared. For anything structural, and especially for recurrence rules, let a calendar application write it. The rule syntax is precise, the failure mode is an event that appears on the wrong days for a year, and nobody notices until somebody misses a meeting.