What Is an ICS File? The iCalendar Format That Moves Events Between Calendars
An ICS file is plain text that carries a calendar event from one program to another. Jump to your question below, or read it through in order.
An ICS file is plain text that carries a calendar event from one program to another. Jump to your question below, or read it through in order.
An ICS file is a calendar file in the iCalendar format. It is plain text, and it carries one event or a thousand from any calendar program to any other.
Double-click one and your calendar reads it. Open the same ICS file in Notepad and you can read it yourself, which turns out to be useful more often than you would expect.
Outlook, Google Calendar and Apple Calendar store their events in completely different ways. None of them can read another one's database.
So when a meeting travels between them, it travels as an ICS file. Text in, text out. Both ends agree on what every line means.
That is why an ICS file is readable. It was designed to cross between rival programs, so it could not be anybody's private format.
.ics, also .ical and .ifbtext/calendarBEGIN:VCALENDAR.vcs, the older vCalendar formatMost arrive with a single event in them. That event brings the title, start time, end time, place, description and often a reminder.
Bigger ICS files exist. Export a year of meetings and you get one ICS file holding hundreds of events, which is exactly how people move between calendar programs.
Plain text is the feature, not a limitation. When an event lands at the wrong time or refuses to import, you can open the ICS file yourself and see the offending line. No other calendar format lets you do that.
Nearly every section below ends up back at that idea, because reading the ICS file is usually faster than guessing.
Lines of text between BEGIN:VCALENDAR and END:VCALENDAR. Inside that wrapper sits at least one component, and for most files that component is a VEVENT.
Every line follows one shape: property name, colon, value. That is the entire syntax, repeated until the ICS file runs out.
BEGIN:VCALENDAR opens and END:VCALENDAR closes. Nothing outside those two lines counts, and files missing either one will not import.VERSION says which standard, and it reads 2.0 for iCalendar. PRODID names the software that wrote the ICS file, which is handy when you are chasing a bug.BEGIN and END. VEVENT is an appointment, VTODO a task, VALARM a reminder nested inside one of those.SUMMARY is the title you see. DTSTART and DTEND are the times, LOCATION the place. UID is the identity, and section 5 explains why that one matters most.Read those four and an ICS file stops being cryptic. The rest is vocabulary, and you can look up any property name you do not recognize.
Repeating events ride on one extra line. RRULE carries the pattern, so a weekly stand-up is one VEVENT saying RRULE:FREQ=WEEKLY rather than fifty copies. Software that reads RRULE badly is why an import sometimes lands one meeting instead of the series.
Long values wrap in a way that looks like damage. The standard keeps lines to 75 octets, so long descriptions continue on the next line, which begins with a single space. That leading space is not a typo and removing it breaks the ICS file.
Real line breaks inside the description are written as a backslash and the letter n instead.
The Internet Engineering Task Force, in 1998. Not Apple. Apple named its calendar app iCal, and the nickname stuck to the format it happened to read.
Search this and half the results credit Apple. This page did until today, and it said so in a specification table where readers are least likely to doubt it.
A working group at the IETF wrote it in 1998, chaired by Anik Ganguly of Open Text. The authors were Frank Dawson of Lotus and Derik Stenerson of Microsoft.
Apple shipped an application called iCal four years later, in 2002. People shortened iCalendar to iCal, the two names collided and credit drifted to the more famous one.
“In 1998, the Internet Engineering Task Force created the iCalendar, or ICS, file format.”
Worth getting right, because it changes what you expect from the format. An open standard written by rivals behaves differently from one vendor's file.
The first specification was RFC 2445, published in 1998. RFC 5545 replaced it in September 2009 and still defines iCalendar today.
Before either one there was vCalendar, from the Internet Mail Consortium, saved as .vcs. You still meet those occasionally, and their files say VERSION:1.0.
vCard is the sibling nobody mentions. Same era, same shape, same plain-text lines, except it carries contacts rather than events. If you have ever opened a .vcf file you have read one already.
Our errors in vCard contact files cover that side, and the two formats fail in strikingly similar ways.
Six kinds of block can sit inside an ICS file. VEVENT travels everywhere. VTODO and VJOURNAL are in the standard and barely supported, so tasks and notes often vanish in transit.
RFC 5545 defines six components. Calendar programs chose one, implemented it properly and treated the others as optional.
| Component | Holds | Support in practice |
|---|---|---|
VEVENT | An appointment with a start and an end | Universal. This is what almost every ICS file carries |
VTODO | A task or assignment | Poor. Outlook ignores it entirely |
VJOURNAL | A dated note that takes no time | Rare. Few programs support it at all |
VFREEBUSY | Blocks of busy time, no detail | Server to server. You rarely see one |
VTIMEZONE | Rules for one named time zone | Good, and section 7 explains why it exists |
VALARM | A reminder, nested inside another block | Good, though the lead time often shifts |
Read the middle two rows again. They are in the standard, they are valid and sending one is close to sending nothing.
Outlook does not export its Tasks as VTODO, and it ignores VTODO items in any calendar you import. So a task list exported from Thunderbird or Apple Reminders reaches Outlook and simply is not there.
Nothing is broken and no error appears. The blocks arrive, Outlook reads past them and you are left wondering where the tasks went.
Journals fare worse. Very few programs do anything with VJOURNAL, so a dated note written in one calendar rarely reaches another.
The practical rule is short. Events travel. Everything else is a gamble. When tasks have to move between programs, move them as something other than an ICS file.
UID is how your calendar recognizes an event it has met before. Same UID and the new copy replaces the old one. Different UID and you get two entries that look identical.
This is the most common complaint about ICS files, and the cause is one line in the ICS file that nobody looks at.
Every event carries a UID, written once when the event is created. It is meant to be globally unique and to stay with that event forever.
When an ICS file arrives, your calendar looks for that UID. Finding a match, it treats the arriving copy as the newer version and overwrites what it had.
Your calendar updates in place. Move that meeting and send it again, and the old entry changes rather than a second one appearing.
Your calendar has no reason to connect them. Two entries, same title, same time and no warning that anything is odd.
So duplicates are rarely your fault. They mean the sender's software minted a fresh UID instead of reusing the original one.
SEQUENCE is the companion property. It counts revisions, starting at zero. Comparing two copies with the same UID, your calendar takes the higher SEQUENCE as the newer one.
Leave SEQUENCE out of an update and some calendars refuse to apply it, which is the other half of the same problem. DTSTAMP records when that copy was written, and STATUS says whether the event is confirmed, tentative or cancelled.
Importing the same calendar export twice produces that mess for another reason, so look for an add-new-events-only option before importing anything twice.
Meeting a numbered failure instead? Our iCalendar ICS file error fixes cover the coded ones, and iCalendar errors 0x804A0106 to 0x804A0108 are the ones people hit most.
One line decides it. METHOD:REQUEST makes the ICS file an invitation with Accept and Decline. METHOD:PUBLISH makes it a plain event the recipient adds themselves.
Send an ICS file and expect a meeting request, and half the time you get a bare event with nothing to reply to. The difference is one property.
A REQUEST needs two more things to work. An ORGANIZER saying who is asking, and at least one ATTENDEE saying who is being asked.
Leave either one out and well-behaved software falls back to treating it as an announcement, which is exactly what you did not want.
| REQUEST | PUBLISH | |
|---|---|---|
| Accept and Decline buttons | Yes | No |
| Appears without being added | Yes, as tentative | No |
| Reply reaches the sender | Yes | No |
| Needs ORGANIZER and ATTENDEE | Yes | No |
| Right for a webinar or a public date | No | Yes |
Rule of thumb. Asking one named person to commit needs REQUEST. Announcing something to a list needs PUBLISH, and sending REQUEST to a thousand people creates a thousand replies you have to read.
Worth opening the ICS file in Notepad when something sends the wrong kind. METHOD sits near the top, just under VERSION. The line tells you immediately which of the two you have.
An ICS file can write time three ways: in UTC with a trailing Z, in a named zone with TZID or floating with no zone at all. Floating times are why a meeting lands an hour out.
RFC 5545 calls a moment in time a DATE-TIME value. Calendars do not argue about what an event is called. They argue about when it happens, and iCalendar gives them three ways to disagree.
| Written as | Means | Risk |
|---|---|---|
20260714T170000Z | Five o'clock UTC. The Z is for Zulu | Safest. One moment, no argument |
TZID=Asia/Kolkata:... | Five o'clock in that named zone | Safe, if the ICS file also carries a VTIMEZONE block |
20260714T170000 | Five o'clock, nowhere in particular | Floating. Lands at five for everybody, wherever they are |
Floating times are legal and occasionally correct. A wake-up alarm should be seven in the morning whatever country you woke in.
For a meeting they are wrong, and the mistake is invisible until somebody in another city joins an hour late.
Your all-day event is not a day too long. DTEND is exclusive, which means it marks the first moment after the event rather than the last moment of it.
So an all-day event on 14 July starts on the 14th and ends on the 15th. Written any other way it would collide with whatever starts next, and software that reads the end date as inclusive is what shows you two days.
Naming a zone is not enough on its own. Daylight saving rules change, and files written in 2015 cannot assume your computer agrees with them about 2026.
So iCalendar lets the file carry its own rules in a VTIMEZONE block: when the clocks move and by how much. That block is usually the longest part of an ICS file and it is doing real work.
Checking this takes ten seconds. Open the ICS file in any text editor and find the DTSTART line. A trailing Z means UTC. A TZID means a named zone. Neither means floating, and floating is your answer.
Every major calendar reads an ICS file: Outlook, Google Calendar, Apple Calendar, Thunderbird, eM Client and the phone apps. Any text editor opens one too, which is the fastest way to see what is really in there.
This was the point of the ICS format. It exists so rival calendars can exchange events, so being widely readable is not a bonus, it is the entire design.
Three unrelated things use this extension, and only one is a calendar. If your calendar refuses an ICS file that looks fine, check which kind you actually have.
| Kind | Starts with | Comes from |
|---|---|---|
| Calendar file | BEGIN:VCALENDAR, readable text | Any calendar program |
| IronCAD 3D Scene | Binary, unreadable in a text editor | IronCAD, a CAD application |
| IC Recorder Sound File | Binary audio | Sony ICD-R100 voice recorders |
The test is the same one as everywhere else on this page. Open it in any text editor. Readable lines starting BEGIN:VCALENDAR mean you have the calendar kind, and anything else does not.
Importing copies an ICS file into your calendar once and forgets where it came from. Subscribing keeps the address and re-reads it, so later changes reach you. Different jobs entirely.
Both start from an ICS file, which is why people mix them up. What the ICS file does afterwards could hardly be more different.
| Import | Subscribe | |
|---|---|---|
| What you give it | An ICS file on your computer | A web address ending .ics |
| Later changes reach you | No. It was a copy | Yes, when it next refreshes |
| You can edit the events | Yes, they are yours now | No, the source owns them |
| Works offline | Yes | Only what it last fetched |
| Right for | One meeting, or a one-time move | Fixture lists, term dates, rotas, holidays |
Spot the difference by what you were handed. An attachment is for importing. A link, often written webcal:// instead of https://, is for subscribing.
Subscriptions refresh on their own schedule, and you rarely control it. Most calendars check somewhere between hourly and daily, so a change at the source is not instant at your end.
That gap is worth remembering before deciding a subscription is broken. Nothing has failed; it has simply not looked again yet.
A subscription that genuinely stops updating usually has a reachability problem, not calendar trouble. Our guide to a calendar that cannot be refreshed covers the common causes.
When the address is served over HTTPS with a certificate your machine distrusts, the failure arrives as cURL error 60 on calendar sync instead.
Open the ICS file in Notepad or TextEdit first. Readable lines mean the ICS file is fine and the problem is one property. Unreadable noise means it was never the calendar kind.
Calendars explain this badly, and most of them say corrupt when the ICS file has one small thing wrong. Could not be read covers a missing line, a bad date and files that were never ICS calendars, with no way to tell which.
Being plain text saves you, because an ICS file hides nothing. Almost every ICS problem is visible in thirty seconds with an editor you already have.
| What you see | What it usually means | Start with |
|---|---|---|
| Nothing happens on double-click | No calendar is registered for .ics on that machine | Open with, then choose a calendar |
| Imported, but no events appeared | The blocks were VTODO, and your calendar ignored them | Tasks, in section 4 |
| Event landed at the wrong time | A floating time, or a missing VTIMEZONE | Time zones, in section 7 |
| Everything imported twice | Fresh UIDs, or a second import of the same ICS file | Duplicates, in section 5 |
| A parse or format error | Truncated ICS file, or a line the parser cannot read | The ladder below |
BEGIN:VCALENDAR and the last reads END:VCALENDAR. A truncated download loses the closing line, and that alone stops an import.VERSION line and the PRODID line. Both are required, and hand-written files often miss one.Numbered errors have their own answers. Outlook and Apple Calendar both throw codes here, and the 0x804A0105 parse error is the one that means the file itself could not be read.
Our iCalendar error guides cover the rest of the codes in the family.
One habit avoids most of this. Send the ICS file as an attachment rather than pasting its contents into an email, because mail clients rewrap long lines and rewrapping is exactly what breaks the folding rule.
Plain UTF-8 text, lines ending CRLF, nothing longer than 75 octets before it folds. Media type text/calendar, registered with IANA and defined by RFC 5545.
You do not need this section to fix anything. It is here because two details explain ICS behavior that otherwise looks arbitrary.
| Rule | Value |
|---|---|
| Media type | text/calendar |
| Character set | UTF-8 by default |
| Line ending | CRLF, hex 0D 0A |
| Line length | 75 octets, not characters |
| Folding | Continue on the next line, starting with a space or a tab |
| Line break in a value | Written as a backslash and the letter n |
| Escaped characters | A comma, semicolon or backslash inside a value carries a backslash in front of it |
| Extensions | .ics, .ical, .icalendar and .ifb for free and busy time |
Putting a folded line back together is called unfolding, and every calendar does it before reading anything. Escaping works the same way in reverse: a comma inside a description arrives as a backslash and a comma, and the reader strips the backslash.
Octets rather than characters matters once accents or non-Latin scripts appear. One emoji can be four octets, so a line that looks short can still need folding.
Private extensions are allowed and common. Anything starting X- is somebody's addition, and files full of X-MICROSOFT- lines came out of Outlook.
One standard describes the ICS file. Others describe how it travels and what the receiving end should do with it.
.vcs. Its files say VERSION:1.0 where iCalendar says 2.0.Worth knowing that the ICS format deliberately stops short. RFC 5545 describes what an event looks like. It says nothing about what calendars should do on receiving one, which is why two programs can both be correct and still behave differently.
Two questions sort out most of what is left. Answer them in order.
Open it in any text editor. Readable lines starting BEGIN:VCALENDAR mean a real calendar file, and section 10 takes it from there.
Find the DTSTART line. No Z and no TZID means a floating time, and section 7 explains what that does to everybody in another city.
Getting a numbered error instead? Our fixes for coded iCalendar failures start with the numbered ones, from iCal error 0x804A0105 through to cURL error 60 on a calendar subscription.
Moving contacts as well as dates? vCard contact file errors covers the sibling format. Garbled vCard names from UTF-8 encoding is the encoding twin of half the ICS problems here.
Moving mail rather than a calendar? The MBOX file format is the equivalent for mail, and Thunderbird address book files cover its contacts.
New to all of this? What a file format is covers the ground underneath, and our file format guides list the rest.
Found something here that does not match your calendar? Send us the exact wording on screen and we will check it against RFC 5545.