English ▾
Free, Fast & Secure Online Tools
An ICS file is a calendar event written as plain text. It arrives as an email attachment, sits behind every “add to calendar” button, and is the reason a meeting invitation can appear in your calendar at all when the sender uses completely different software from you.
Rename one to .txt and open it — the contents are readable, and almost every calendar problem people run into is visible in there.
BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
DTSTART;TZID=Asia/Taipei:20261110T140000
DTEND;TZID=Asia/Taipei:20261110T150000
SUMMARY:Project review
LOCATION:Room 3
END:VEVENT
END:VCALENDAR
A container, an event, a start, an end, a title. Four of the lines above do more work than they appear to, and each explains a familiar failure.
Every event carries a UID — a unique identifier that stays the same for the life of that event.
When a meeting moves, the organiser’s software sends a new ICS file with the same UID and a later sequence number. Your calendar recognises it as the same event and updates the existing entry rather than adding another one.
This is exactly why duplicate events appear. If a tool generates a fresh UID each time it exports — some booking systems and newsletter “add to calendar” links do — then every update arrives as a brand-new event, and you end up with three copies of one meeting. The duplicates are not a bug in your calendar; it was told they were different events.
The METHOD line tells your calendar what kind of file this is:
So when an invite arrives as a plain attachment with no response buttons, it is usually a PUBLISH file, or a REQUEST that was forwarded in a way that lost its invitation status. Accepting it adds the event to your calendar but tells the organiser nothing — which is how people end up marked as not having replied to a meeting they are planning to attend.
A time in an ICS file can be written three different ways, and the difference matters enormously.
DTSTART;TZID=Asia/Taipei:20261110T140000 — two o’clock in Taipei, correctly converted for everyone else. This is what you want.DTSTART:20261110T060000Z — the trailing Z means UTC, and every calendar converts it to local time correctly. Also fine.DTSTART:20261110T140000 — two o’clock wherever the reader is. For a personal reminder that is right. For a meeting between cities it is a disaster: everyone sees 2 p.m. in their own zone and nobody meets.When a meeting lands in the calendar several hours out, this is nearly always why. The second common variant is an event exported from a system whose own time-zone setting was wrong, in which case the file is internally consistent and uniformly incorrect.
All-day events have their own version of this. A proper all-day event is written as a date with no time at all (DTSTART;VALUE=DATE:20261110). Written as a time instead — midnight in some zone — it shifts to the previous or following day for anyone far enough east or west. That is why a birthday sometimes lands on the wrong date.
A weekly meeting is not stored as fifty-two events. It is one event plus a rule:
RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=52
The calendar generates the occurrences from that rule. Two further lines handle the exceptions that real schedules always produce: EXDATE deletes one occurrence, and a separate event carrying RECURRENCE-ID overrides one occurrence — the mechanism behind “this week’s meeting moved to Tuesday” without disturbing the rest of the series.
Support for these exceptions varies between calendar programs, which is why a modified occurrence sometimes reverts, or appears twice, when a series crosses between systems.
This is the single most useful thing to understand about calendar files, and the two options look almost identical when you choose them.
Importing an ICS file copies the events into your calendar once. They become yours, you can edit them, and they are frozen. If the source changes, nothing happens — your copy stays as it was.
Subscribing to an ICS URL keeps a link. Your calendar re-fetches the file periodically, and changes at the source appear. You cannot edit the events because they are not really yours.
Almost everyone gets caught by this at least once: a class timetable, a sports fixture list or a shared team schedule is imported, the organisation then changes several dates, and the calendar quietly keeps showing the old ones. Nothing warns you, because from the calendar’s point of view nothing went wrong.
The rule is simple. If the source will keep changing, subscribe. If it is a one-off event, import. Subscription links usually appear as a URL ending in .ics, sometimes beginning with webcal://, which is the same thing addressed to a calendar app.
One caveat worth knowing: subscribed calendars refresh on the application’s own schedule, which can be several hours or even a day. A change made this morning may not appear until tomorrow.