ICS File Generator

An ICS file generator has to hand you links as well

This is the thing that separates a calendar button that works from one that quietly fails for half your audience, and almost nobody mentions it. There are two mechanisms for getting an event into somebody's calendar, and each covers a different half of the internet.

A downloaded .ics file is the elegant one. On iPhone, on macOS Calendar and in the Outlook desktop app, opening it puts the event straight into a confirmation dialog. Then there is Google Calendar, which does not do that at all — it will not import a file you simply open. A Google Calendar user has to go into Settings, find Import, and pick the file they just downloaded, and in practice they close the tab instead.

So the fix is a pre-filled link. calendar.google.com/calendar/render?action=TEMPLATE… opens a new event with your title, times and location already filled in, one click, no file involved. Outlook Web has an equivalent. Both are produced here alongside the file, carrying exactly the same times, and you put all three on your page.

The .ics format, in brief

ICS

Full name	iCalendar
Extension	.ics, .ical, .ifb
Format type	Plain text calendar events, RFC 5545
MIME type	text/calendar

Timezones are where these files usually go wrong

Write DTSTART:20260812T140000 into a calendar file and you have specified a floating time. It means two o'clock wherever the reader happens to be — two in Stockholm, two in Denver, two in Tokyo. For a webinar that might even be what you meant. For a talk in a room it is wrong, and it is wrong in the least detectable way possible: the person who built the page lives in the right timezone, so it looks perfect to them and to everyone they ask to check it.

Here the time you type is treated as wall-clock time in the zone you select, converted to UTC, and written with a Z. Everybody's calendar then does the local conversion itself and shows the correct moment. The conversion is printed on screen as you type — 14:00 Europe/Stockholm → 12:00 UTC — because it is the one setting that can silently ruin the file, and a number you can see is a number you can check.

The detail that saves you when the event moves

Conferences reschedule. Somebody who added your keynote in March and adds it again in May should end up with one entry, updated — not two entries an hour apart. Whether that happens is decided by a single field, UID, and by whether it stayed the same between the two files.

Most generators put a fresh random identifier in every file they produce, which guarantees duplicates. This one derives the identifier from the event itself, so the same event produces the same UID every time with nothing stored anywhere. If you have changed the title or the time — the very things the identifier is built from — paste the previous UID into the field under the advanced section and raise the sequence number. That combination is the actual, specified way to say this replaces what I sent you before.

A UUID is appropriate when an application truly needs a new independent identifier, but it is the wrong default for an update that must find an existing event. The UUID generator explains that distinction and offers v4 or time-sortable v7 for the cases that actually need a fresh ID; this calendar form keeps its stable UID behavior instead.

All-day events and the off-by-one everybody hits

In iCalendar, the end of an all-day event is exclusive. A conference on the 12th runs from the 12th to the 13th, and writing the 12th in both fields produces an event that is zero days long — which different calendars then render differently, usually by not showing it. Tick the all-day box and this is handled; the point of mentioning it is that if you are hand-writing these files, this is the bug you have.

A few other specification details are handled quietly because they break real files: a comma inside a description has to be escaped or it reads as a field separator, lines have to be wrapped at 75 octets rather than characters — which matters the moment your venue is called Malmö — and the whole file needs CRLF line endings, which strict parsers enforce.

What gets published, and what does not

The file, the links and a snippet of HTML to paste on your page are all produced here in the browser. Nothing is sent anywhere, which is less about secrecy than about the fact that there is no reason for a server to be involved in writing a text file.

The one thing that does travel is a single credit line at the end of the description, pointing back to the calendar tools. It is on by default and the checkbox turns it off, and it is shown in full before you download anything — because it ends up in your visitors' calendars, and finding it there would be a poor way to learn about it. The PRODID field names this tool either way; that field is required by the specification, every calendar file has one, and no calendar application shows it to anybody.

A file is the right answer when the event is going on a page or into an email footer for anyone to take. It is the wrong one when you are inviting named people and expect replies, because a downloadable file cannot collect them — sending a calendar invite covers that case, including why an attachment from a personal address so often lands without the accept and decline buttons.