Calendar Event QR Codes: The Complete 2026 Guide to "Add to Calendar" (.ics)

Pick the destination by who is scanning. A corporate conference where every badge is a work laptop on Outlook is a different audience than a wedding where half the guests are on iPhones and half on Android. The table maps each approach to what it opens and where it fits.

The contrarian take: most guides push the Google Calendar deeplink because it is the easiest to build, but it is the worst default. Google Calendar is one app. An 'add to calendar' QR that only works in one calendar app is a QR that fails for everyone who uses a different one — and on iPhones, the default is Apple Calendar, not Google. If you are printing for a mixed public audience, start with the hosted .ics or the landing page and treat the bare Google deeplink as the corporate-Workspace special case.

The Google Calendar render deeplink builds a URL that opens Google Calendar with a new event pre-filled. The guest scans, reviews the event, and taps Save. The format is documented and stable:

https://calendar.google.com/calendar/render?action=TEMPLATE&text=EVENT+NAME&dates=20260615T180000Z/20260615T200000Z&details=DETAILS&location=LOCATION

The parameters, in order:

• `action=TEMPLATE` — always present, always this exact value. It tells Google Calendar to open the new-event template screen.
• `text=` — the event title, URL-encoded. Spaces become + or %20. Acme Product Launch becomes Acme+Product+Launch.
• `dates=` — the start and end timestamps, separated by a forward slash /. Both are in UTC in the format YYYYMMDDTHHMMSSZ — four-digit year, two-digit month, two-digit day, the letter T, two-digit hour, minute, second, then the literal Z that marks UTC. 20260615T180000Z/20260615T200000Z means 18:00 to 20:00 UTC on June 15, 2026.
• `details=` — optional. The event description body, URL-encoded. Put your agenda, a link back to the event page, parking notes.
• `location=` — optional. The venue address, URL-encoded. Google Calendar turns this into a tappable map link.

A real example for a 6pm-to-8pm UK launch on June 15, 2026 (UTC+1 in summer, so 18:00 local is 17:00 UTC):

https://calendar.google.com/calendar/render?action=TEMPLATE&text=Acme+Product+Launch&dates=20260615T170000Z/20260615T190000Z&details=Doors+at+5:30pm.+RSVP+at+acme.com/launch&location=10+King+St,+London

The honest limit, again: this URL only opens Google Calendar. An iPhone guest whose default is Apple Calendar will get bounced into a browser tab, see Google's interface, and may have to sign into a Google account they do not use. That is a worse experience than a hosted .ics. Build this deeplink when your audience is Google-first; otherwise read the next section.

A .ics file is the iCalendar standard — the plain-text format every major calendar app reads. Host one at a public URL, encode that URL as a QR, and the guest who scans it downloads a file that Apple Calendar, Microsoft Outlook, and Google Calendar all open and offer to add. This is the most universal calendar QR, and it is the one to default to for anything printed.

A minimal single-event .ics file looks like this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Acme//Event//EN
BEGIN:VEVENT
UID:[email protected]
DTSTART:20260615T170000Z
DTEND:20260615T190000Z
SUMMARY:Acme Product Launch
LOCATION:10 King St, London
DESCRIPTION:Doors at 5:30pm. RSVP at acme.com/launch
END:VEVENT
END:VCALENDAR

The fields that matter:

• `DTSTART` and `DTEND` — start and end, same UTC YYYYMMDDTHHMMSSZ format as the Google deeplink, same Z suffix marking UTC. The UTC rule is identical and the mistake is identical — get the offset wrong here and the event lands at the wrong hour in every guest's calendar.
• `SUMMARY` — the event title (no URL-encoding needed inside an .ics file).
• `LOCATION` — the venue address.
• `DESCRIPTION` — the body text.
• `UID` — a unique identifier for the event. Calendar apps use it to deduplicate, so a guest who scans twice does not get two copies. Make it unique per event.

Here is the part to be precise about: EZQR does not host your .ics file for you. You write the .ics file and host it at a public URL — your own website, an S3 or Cloudflare R2 bucket, Google Drive with public sharing, Dropbox with a direct-download link. Then you paste that URL into EZQR's calendar QR generator and EZQR encodes the link into the QR. EZQR's job is the QR and, on dynamic codes, the redirect that lets you repoint it. The file lives on your infrastructure.

One hosting detail that breaks people: the file has to download as an .ics, not render as text in the browser. Serve it with the text/calendar content type. If you host on a service that previews the file as plain text instead of downloading it, the calendar apps never get the prompt. Test the raw URL in a browser first — it should trigger a download or an 'Add to Calendar' prompt, not show you raw BEGIN:VCALENDAR text.

This is the single most common reason a calendar QR works in your test and lands wrong for your guests. Both timestamps in the dates parameter — and both in the .ics DTSTART/DTEND — are UTC, marked by the trailing Z. They are not your local time. If your event is at 6pm local and you write T180000Z, you have told the calendar the event is at 6pm UTC, which is not 6pm anywhere except the UK in winter.

Work an example. Your event is 6:00pm to 8:00pm on June 15, 2026, in New York. New York in June is on Eastern Daylight Time, UTC-4. So 18:00 local is 22:00 UTC, and 20:00 local is 00:00 the next day UTC. The correct value is:

dates=20260615T220000Z/20260616T000000Z

Note two things: the start hour shifted from 18 to 22, and the end rolled past midnight, so the date on the end timestamp became June 16. Miss the rollover and your two-hour event becomes a negative-duration event the calendar rejects.

The failure looks like this in the wild: you build the QR in New York at your desk, you scan it on your own phone, your phone is set to Eastern time, and the calendar quietly converts the UTC value back to your local zone — so it looks correct to you. Your guest in Los Angeles scans the same QR, their phone converts the same UTC value to Pacific time, and the event shows up three hours off. You never see the bug because your test phone hides it.

The fix is a discipline, not a tool. Always compute the UTC offset for the event's date — including whether daylight saving is in effect on that date in that location — and write the UTC value, not the local value. Then test on a phone set to a different time zone than the venue, or change your phone's time zone temporarily and re-scan. If the displayed time is correct on a phone in a different zone, the UTC math is right. For the full pre-print checklist, see the QR code best practices guide.

The workflow from picking a destination to handing a print-ready file to the printer:

Calendar QRs pay off wherever you are asking people to remember a date that is weeks or months away. The scan turns 'I'll add it later' into a saved event with a built-in reminder, which is the difference between a no-show and an attendee.

Conferences and trade shows. Print the QR on badges, session-room door signs, and the printed agenda. A hosted .ics per session lets attendees build their own schedule by scanning the talks they want. For the full event-surface playbook, see the event QR codes industry page.

Weddings and save-the-dates. This is the mixed-audience case that makes the hosted .ics non-negotiable — half your guests are on iPhones, half on Android. A Google-only deeplink fails for every Apple Calendar guest. Print the QR on the save-the-date card and the invitation; a static code is right because a wedding date does not change.

Webinars and online workshops. The QR goes on the registration confirmation, the email footer, the landing page. The .ics carries the join link in the DESCRIPTION so the calendar event has the Zoom or Meet URL one tap away at start time.

Recurring classes and fitness studios. A studio schedule poster with a QR per class time. Here a dynamic code earns its keep — class times shift seasonally, and you repoint the link instead of reprinting the poster.

Store events, launches, and pop-ups. Window decals, in-store signage, and flyers for a grand opening or a sale weekend. The QR drops the date into the customer's calendar with a reminder that fires the morning of. A static code works for a one-off; a dynamic code suits a venue that runs a different event every weekend.

The static-vs-dynamic call comes down to one question: can the event move? A static calendar QR encodes the destination URL directly into the pattern. There is no server in the loop, no subscription required for the printed code to keep working. The URL is the QR. For a fixed-date wedding or a conference with a locked date, that is exactly right — print it, and it works forever regardless of whether the EZQR account stays open. Static codes also survive cancellation: cancel the plan, and every printed save-the-date still resolves.

The limit is that a static QR points at one URL forever. If the event gets rescheduled, you cannot change where a static code goes — the new date means a new QR and a reprint. For 500 already-mailed save-the-dates, that is impossible.

A dynamic QR routes through an EZQR redirect that resolves to the destination URL on each scan. Because the redirect is editable, you can repoint a rescheduled event — swap the .ics URL or the Google deeplink — and every already-printed QR now sends scanners to the new date. No reprint. Dynamic codes also log each scan's timestamp, country, and device in your dashboard, which is how you see how many people actually added the event. Lite ($5/mo) gives 25 dynamic codes; Pro ($10/mo) gives 100 plus deeper analytics; Max ($20/mo) is unlimited with API access. The free plan includes 3 dynamic codes and unlimited static codes exported as PNG.

The rule of thumb: print a dynamic code for any event that could plausibly move, any recurring schedule, and anything where you want to count adds. Print a static code for a one-time, locked-date event where simplicity and permanence beat flexibility. For the full trade-off, see static vs dynamic QR codes. One thing a calendar QR never does, on either type: it cannot notify you when someone adds the event or send the guest a reminder — the calendar app's own reminder handles that, and the scan itself is silent on your end unless you are running a dynamic code that logs it.

A static calendar QR encodes the URL directly into the pattern, so the printed code keeps resolving with no subscription, no server, no active account. That permanence matters in two specific ways for events.

First, the code outlives the publisher's billing. A static QR printed on a 2026 conference badge keeps pointing at its .ics URL in 2030, whether or not the EZQR account is still paid — as long as the .ics file is still hosted at that URL. The QR's job is to carry the link; keeping the destination alive is on your hosting. If you host the .ics on your own domain and keep that domain, the static code works indefinitely.

Second, dynamic codes flip the dependency. A dynamic calendar QR's redirect runs on EZQR's server, so it needs an active subscription for the lookup to resolve. That is the trade for being able to repoint a rescheduled event. The right move for a recurring or movable event is a dynamic code on an active plan; the right move for a fixed, permanent date is a static code that needs nobody's billing to keep working.

For a calendar QR specifically, the hosting of the .ics is the load-bearing piece — the QR will scan forever, but a 404 at the destination breaks it. Use a stable URL on infrastructure you control, and confirm the .ics still downloads before any long-lived print run. Our permanent QR code generator guide walks the verification workflow for confirming a downloaded static QR keeps working after the generator's account is cancelled, and the best free QR generators roundup covers which free tools keep static codes alive versus expiring them.