ICS vs iCal vs webcal: What's the Difference?

Three terms get used interchangeably in calendar documentation, support articles and vendor UIs: ICS, iCal, and webcal. They are not the same thing, and not even the same kind of thing. One is a file format, one is a defunct product name that stuck, and one is a URL scheme.

Vendors have been loose with the terminology for twenty years, which is where most of the confusion comes from. Here is what each one means and which to use when.

ICS vs iCal vs webcal: the short version

Term	What it really is	Example
iCalendar	The data format specification, defined by RFC 5545	The rules that say an event is a VEVENT
.ics	The file extension for a document in that format	invite.ics
iCal	Apple's old calendar app name, now just "Calendar". Colloquially used to mean iCalendar.	"Send me the iCal feed"
webcal://	A URL scheme signalling "subscribe to this", not a format	webcal://example.com/feed.ics
text/calendar	The MIME type servers use to label iCalendar data	An HTTP response header

Every one of those rows describes iCalendar data. They differ only in whether they are talking about the specification, the file, the app, the transport hint, or the content type label.

iCalendar is the specification

iCalendar is a data interchange format standardised by the IETF. It first appeared as RFC 2445 in 1998 and was superseded by RFC 5545 in 2009, which is what everything implements today.

The spec describes a plain-text structure of nested components and properties. A calendar is a VCALENDAR. Inside it sit VEVENT components for events, VTODO for tasks, VJOURNAL for notes, VFREEBUSY for availability, and VTIMEZONE for timezone definitions. Properties such as DTSTART, SUMMARY, UID and RRULE carry the actual data.

Related RFCs extend it: 5546 defines iTIP, the scheduling protocol behind invitations and replies; 6047 defines iMIP, which is iTIP delivered over email; 7986 adds properties like COLOR and REFRESH-INTERVAL. Strictly speaking, iCalendar is the correct name for the format, and almost nobody says it. For the full anatomy of a file, the complete guide to the iCalendar format walks through every component and property.

.ics is the file extension

.ics is simply the conventional filename extension for a document written in iCalendar format. It stands for iCalendar Stream or iCalendar Sync depending which source you believe, and it does not matter.

What matters is that .ics is what an operating system uses to decide which application opens a file. Double-click schedule.ics and Windows hands it to Outlook, macOS to Calendar. Rename it schedule.txt and it opens in a text editor, with identical contents.

The other extensions

You will occasionally run into variants:

• .ical and .icalendar are alternative extensions listed in the IANA registration for text/calendar. They are valid, contain exactly the same format, and are supported inconsistently. Use .ics.
• .ifb is used for free/busy data, meaning a file whose payload is a VFREEBUSY component rather than events. Same format, different content.
• .vcs is genuinely different. It is vCalendar 1.0, the pre-standard predecessor from 1996. Superficially similar, but the escaping rules, the timezone handling and several property names differ. Some old phone and PDA exports still produce it. Modern clients often accept it, but do not assume a .vcs file will parse cleanly as ICS.

If you have a file and are not sure what it actually contains, the free ICS viewer parses it and shows you the components, regardless of what the extension claims.

iCal was an Apple app

Here is where the muddle comes from. Apple shipped a calendar app called iCal in 2002 with Mac OS X Jaguar. It was one of the earliest consumer apps to implement the iCalendar standard properly, and popular enough that "iCal" became shorthand for calendar data generally.

Apple renamed the app to Calendar in OS X Mountain Lion in 2012. Nobody updated their vocabulary. Product managers still write "iCal feed" in their UIs, support docs still say "download the iCal file", and every developer knows exactly what is meant.

So when someone asks for "the iCal link", they mean one of two things and you need to work out which:

• A file, that is a downloadable .ics document containing a snapshot of the events.
• A feed, that is a URL that serves iCalendar data on request and can be subscribed to.

In practice, "iCal feed" or "iCal URL" almost always means the second. "iCal file" means the first. If the distinction matters, ask, because getting it wrong means either sending a static file that never updates or sending a subscription URL to someone who wanted a one-off event.

webcal:// is a URL scheme, not a format

webcal:// is the term that confuses people most, because it looks like a protocol and it is not one.

There is no webcal protocol. Nothing implements a network transport called webcal. When a client encounters webcal://example.com/feed.ics, it rewrites the scheme to http:// or https:// and makes an ordinary HTTP request. The bytes that come back are ordinary iCalendar data with a text/calendar content type.

What the scheme does is signal intent. A browser given an https:// link to an ICS file will download it, because that is what browsers do with files. Given a webcal:// link, the browser does not handle it at all: it passes the URL to the OS, which hands it to the registered calendar app, which interprets it as "subscribe to this feed and keep polling it".

Same data, same server, same file. Different scheme, completely different user experience. One gives you a static copy in your Downloads folder, the other gives you a calendar that stays current.

webcal:// was never standardised. It originated with Apple and was picked up by everyone else because it solved a real problem, working across Apple Calendar, Outlook and most third-party clients. Google Calendar is the exception: it handles a webcal:// link clicked in Chrome, but its "Add calendar from URL" field only accepts http and https. The deep dive on webcal URLs covers refresh intervals, security and how to build one.

text/calendar is the MIME type

The last piece. When a server sends iCalendar data over HTTP, or an email client attaches it to a message, the content is labelled with the MIME type text/calendar, registered in RFC 5545.

It takes optional parameters that carry meaning:

Content-Type: text/calendar; charset=utf-8; method=REQUEST; component=VEVENT

The method parameter mirrors the METHOD property inside the file and tells the receiving client whether this is a scheduling request needing an RSVP, or a published event to simply add. Mail clients use it to decide whether to render Accept and Decline buttons.

This header is also why the same file can behave completely differently depending on how it is served. A correctly labelled feed opens in a calendar app. The same bytes served as application/octet-stream get downloaded as an anonymous file that iOS may refuse to open at all, which is a common cause of the "nothing happens when I tap it" complaints in the iPhone and Apple Calendar guide.

ICS or iCal or webcal: which should you use?

Decide based on what you are trying to achieve, not what the other party called it.

Use a downloadable .ics file when

You have a single event that will not change and you want it to work with no infrastructure. The recipient gets a copy they own and can edit. You get no ability to update it and no visibility into who added it. Build one with the free ICS file generator.

Use a webcal:// or https:// feed when

You have an ongoing set of events that changes: a fixture list, a term calendar, a rota, a release schedule. Subscribers get updates automatically, and removing an event from the feed removes it from their calendar. This is the model described on the subscription calendars page.

The trade-off is refresh lag, which is worst on Google at roughly 24 hours, and the fact that subscribed events are read-only for the recipient.

Use an add to calendar link when

You are sending one event to many people across unknown platforms. A file forces everyone through a download step, and mobile clients handle that badly, particularly the Google Calendar mobile app, which has no import function at all. A subscription is overkill for a single event and few people will subscribe to a feed for one webinar.

A hosted link detects the platform and routes each recipient to the right destination: a Google Calendar deep link, an Outlook web link, or the native handler on iOS. That is what add to calendar links do, and it removes the whole class of "it did not work on my phone" problems.

Getting the terminology right in your own docs

A few habits save your users a lot of confusion:

• Say "ICS file" for a download and "calendar subscription URL" for a feed. Both are unambiguous.
• Avoid "iCal" unless your audience already uses it, in which case match their vocabulary.
• Never call webcal a format or a protocol. It is a link type.
• If you offer both, label them separately. "Download a copy" versus "keep this calendar up to date" tells people everything they need.

None of this changes what the bytes look like. Every option above ships the same RFC 5545 payload. What differs is whether the recipient gets a snapshot or a living calendar, and whether you can fix a mistake after you have hit send.

To see what you are actually dealing with, try the ICS viewer, or pull the events into a spreadsheet with the ICS to CSV converter. Both are free and need no account.