A flyer for a workshop, a poster for a concert, a slide at the end of a talk: people see the date, mean to remember it, and don't. An "add to calendar" link or code turns that intention into an entry on their phone while they're still looking at the poster.
The catch is that there is no single add-to-calendar link. Google Calendar, Outlook and Apple Calendar each want something different, and what works on a laptop doesn't always work on a phone. This guide shows the three forms, the time zone and all-day mistakes that put events on the wrong day, and why the QR code on the poster should open a small page rather than hold the event itself.
The examples all use one event: a two-hour pruning workshop in a community garden in New York, on Saturday 20 March 2027, 10:00 to 12:00 local time.
What each calendar accepts
An .ics file: Apple Calendar, Outlook on a computer, almost everything else
The .ics file is the calendar world's common format (iCalendar, RFC 5545). Opened on an iPhone, a Mac or in desktop Outlook, it offers to add the event. Here is a complete one:
What matters in it:
- UID and DTSTAMP are required by the standard. The UID is the event's permanent name; keep it the same if you later publish a corrected file.
- Times in UTC, with a Z on the end. 10:00 in New York on 20 March 2027 is 14:00 UTC. You can write DTSTART;TZID=America/New_York:20270320T100000 instead, but the standard then requires a matching VTIMEZONE block describing the zone's rules, and leaving it out is a common reason an event shows up an hour off. UTC needs no block, and every calendar shows it in the reader's local time.
- Commas, semicolons and backslashes in text need a backslash in front (as in Garden\, 12 Mill Lane), and line breaks inside a description are written as \n.
- Lines end in CRLF, and lines longer than 75 bytes should be folded onto the next line starting with a space. Most generators do this for you; hand-written files in a text editor often don't.
- Serve the file with the content type text/calendar. Served as plain text or as a download of unknown type, phones show the text or save it to Files instead of offering to add it.
Android is the weak spot. Google Calendar on Android often won't take a downloaded .ics the way an iPhone does; Google's own help page describes importing .ics files on a computer. For Android users, the Google link below is the one that works.
Google Calendar's link
Google opens its event editor, filled in, from a link like this:
(Shown on several lines for reading; it's one line in practice, with every value URL-encoded.) dates takes a start and an end separated by a slash, and both are needed. Here the times are local and ctz names the time zone, so the link reads the same way no matter where the person opening it is. The alternative is UTC with a Z on both halves: 20270320T140000Z/20270320T160000Z. Leave out both ctz and the Z and Google reads the times in the visitor's own time zone, which is wrong for everyone who isn't in New York, including anyone who opens the poster's link from a phone that's still set to another country after a trip.
Outlook on the web: Outlook.com and Microsoft 365
Outlook's web calendar opens a filled-in event from a link of this shape:
For work and school accounts (Microsoft 365), the same link on outlook.office.com instead of outlook.live.com. Give the times in UTC with a Z: without it, Outlook reads them in the visitor's time zone. Microsoft doesn't document these links, and the path has changed over the years; the community-maintained add-event-to-calendar docs on GitHub track what currently works. Test both before printing anything, and remember that people with Outlook on a computer can always use the .ics file instead.
All-day events end the next day
For an all-day event (a fair, a festival day, a deadline), every format uses dates without times, and in every format the end date is the day after the last day. A one-day fair on 20 March 2027:
Write the end as the 20th and the event is zero days long: some calendars drop it, others show it on the wrong day. And don't make an all-day event out of 00:00 to 23:59 in UTC: for anyone east or west of UTC, that spills across two days.
The time zone trap in March and in the autumn
If your audience is spread out, as for an online talk, don't convert times in your head. The United States moves its clocks on the second Sunday in March (14 March in 2027), Europe on the last Sunday (28 March). For those two weeks, New York is four hours behind London, not the usual five, and the same thing happens in reverse between late October and early November. A link built with "New York is UTC minus five" in March puts the event an hour off. Name the zone (ctz=America/New_York) or convert with a tool that knows the date, and print the time zone on the poster: "10:00 New York time".
The QR code should open a page, not hold the event
A QR code can hold the event itself: the BEGIN:VEVENT text above, squeezed into the code. Some phone cameras offer to add it straight to the calendar. It's tempting, and we'd still advise against it for anything printed:
- Phones don't agree on it. Some cameras offer "add event", some scanner apps show a block of text, and you can't control which one your visitors use.
- The event is frozen into the print. Wrong date, moved venue, a typo in the title: the code keeps it forever, and so does every calendar that scans it.
- The code gets dense. An event with a location and a sentence of description is several times the length of a web address, so the code needs more, smaller squares and has to be printed bigger to scan from the same distance (our guide to printing QR codes has the numbers).
- There's nothing else to see. No map, no ticket link, no note that it's sold out.
A short link to a small event page fixes all four. The page shows the date, time, place and anything else people need, and has three buttons: Google Calendar, Outlook and Apple / other (.ics). People pick their own. If you'd rather not ask, put the Google link and the .ics file first: between them they cover most phones. Our add-to-calendar link builder makes all three from one form, in your browser: the Google and Outlook links, the .ics file and the HTML for the buttons, with the all-day and time zone rules below already applied.
Make the QR code from a short link you can redirect, and you can later point it at a new page without reprinting. Give each poster location or each mailing its own short link if you'd like to know which one brought people in; one short link per flyer, post and podcast explains the idea. And if you're also sending invitations by email, the same short link can go into a QR code in the email itself.
When the time changes after the poster is printed
With a page behind the code, a new time is a five-minute fix: change the page, the three links and the .ics file, and everyone who scans from now on gets the new time.
The people who already added it are the hard part. Every one of these methods puts a copy of the event into their calendar, and nothing you change later reaches that copy. You have three options, in order of how well they work:
1. Tell them directly. If people registered with an email address, send the change, with the new add-to-calendar links. This is the only method that reaches everyone.
2. Publish an updated .ics file with the same UID, a higher SEQUENCE number (1, then 2) and the new times. Opened in Apple Calendar or Outlook, it often updates the existing entry instead of adding a second one. Google's link has no such link to the earlier entry; it always makes a new event.
3. For a series, offer a subscription. A club with a season of events can publish one calendar feed (a .ics address that people subscribe to rather than import). Subscribed calendars do pick up changes, but on the calendar's schedule, not yours: Google Calendar refreshes subscribed feeds roughly once or twice a day and offers no refresh button. Fine for next month's meeting; too slow for "we start an hour later today".
And put a line on the page itself, near the top, when something changed: "Moved to 11:00 (changed 2 March)". People who come back to check will see it at once.
Before you print
- The QR code opens your event page through a short link you can redirect.
- The page has the Google link, an Outlook link and an .ics file served as text/calendar.
- Times are in UTC with Z, or carry a named time zone; the time zone is printed on the poster.
- All-day events end the following day.
- You tried each button on an iPhone, an Android phone and a computer, and the event landed at the right hour.
- You know how you'd tell people if the time changed.
Sources: IETF, RFC 5545 (iCalendar) (required UID and DTSTAMP, VTIMEZONE for each TZID, DATE values, SEQUENCE, line folding, text escaping); Interaction Design Foundation, add-event-to-calendar-docs: Google and Outlook web (link parameters, all-day, time zone behaviour; Microsoft documents neither); Microsoft Tech Community, deeplink compose fails to load (path changes); Google Calendar Help, Import events to Google Calendar; Carly, Google Calendar ICS refresh rate (subscribed feeds every 12 to 24 hours, a community estimate; Google publishes no figure).
Fill in the event once and get the Google, Outlook and .ics versions, then give its page a short link and QR code you can repoint if the event moves.
Build calendar links
