How to Make an “Add to Calendar” QR Code

An "add to calendar" code turns an invitation into a diary entry in one tap, which is the difference between an event people meant to attend and one they did. Two things decide whether it works: the timezone, and whether you embed the event or link to it.

Embed the event, or link to it

There are two ways to build this and they behave very differently.

You can put the event itself in the code, as iCalendar text — the VEVENT block with a title, a start, an end and a location. It works offline, because nothing has to be fetched. But support is uneven: some phones recognise the payload and offer to add it, and others simply display it as a wall of plain text, which looks broken to the person holding the phone. You will not find out which you are dealing with until you test.

Or you can point the code at a hosted .ics file or an event page. This needs a connection, but it behaves consistently — the phone downloads a calendar file and offers to add it, the way every emailed invitation already works. It also means the details can be corrected after printing.

For anything going out to the public, link to it. Embed only when you control the devices, or when the venue's signal is genuinely doubtful and the tradeoff is worth it.

The timezone is where this goes wrong

An event with a start time and no timezone attached is interpreted in whatever zone the reader's phone is in. For a local party that is invisible and harmless. For a webinar, a conference, or a wedding with guests flying in, it puts the event in the wrong hour of some people's diaries and tells nobody.

Make sure the event carries an explicit timezone, and if the audience is international, put the timezone in the printed text as well. An entry that says 14:00 CET in the description survives a bad import; one that just says 14:00 does not.

Test it properly: change your own phone's timezone, scan the code, and look at what lands in the calendar. It takes two minutes and it is the only way to be sure.

What travels, and what does not

The title, start, end, location and description go into the entry. The location is worth attention — a calendar entry whose location is a full, unambiguous address becomes a tappable route on the day, which is most of the practical value of doing this at all.

Reminders do not travel reliably. An alert you set is a suggestion that most calendars override with the user's own defaults, so do not depend on it to get anyone anywhere. Nor does the entry update itself later: once it is in someone's calendar, it is their copy, and changing your source changes nothing about it.

Which is why the date should not move

That last point is the one worth dwelling on. Unlike a menu or a landing page, a calendar entry is copied, not referenced. Fix the date afterwards and the hundred people who already scanned still have the old one.

So a dynamic code helps less here than elsewhere — it protects the people who scan after the change, not the people who scanned before it. It is still worth having on anything printed early, because it lets the code point at a corrected event and tells you how many people added it. But if the time genuinely moves, you have to tell the people who already have it, by email, the ordinary way.

Where it belongs

On anything printed for a specific date: invitations and save-the-dates, conference agendas and session signage, appointment cards from a clinic or a salon, posters for a one-off. It is most valuable where the gap between reading and attending is long enough to forget — which is exactly where weddings and events live.

It is worth nothing at all on something read on a screen, where a normal "add to calendar" link does the same job with one fewer device involved.

Frequently asked questions

Does scanning add the event automatically?

No. The phone offers to add it with everything filled in and the person confirms. That confirmation is deliberate — nothing writes to a calendar without the owner agreeing, and no QR code can bypass it.

Should I embed the .ics or link to it?

Link to it for any public audience. An embedded iCalendar payload works offline but is handled inconsistently across phones, and where it is not recognised the person sees raw text instead of an invitation. A hosted file behaves the same way everywhere.

Why did the event land at the wrong time for some people?

Because the event carried no explicit timezone, so each phone applied its own. Attach a timezone to the event, and for international audiences also print the time and zone as text so a bad import is obvious rather than silent.

Can I change the date after people have scanned?

Not for them. A calendar entry is a copy made at the moment of scanning, not a live link, so it never updates. A dynamic code fixes the details for everyone scanning from that point on, but anyone who already added it has to be told directly.

Does it work on both iPhone and Android?

Yes, when you link to a hosted calendar file — both offer to add it, to Apple Calendar and Google Calendar respectively. Embedded event payloads are the unreliable case. Create one free and test it on both before printing anything.