Calendar event QR codes — get an event into a phone fast

You print a QR code on a flyer. Someone scans it. The next thing they see isn't a website — it's their phone asking "Add event to Calendar?" with the date, time, and location already filled in. They tap Yes. Done. The event lives in their calendar. They'll get the reminder. They might actually show up.

That's a calendar event QR code, and it's wildly underused for an idea this simple. Most events still funnel through a registration page, then a confirmation email, then a separate "Add to calendar" link buried in the footer that opens a fresh tab and another consent dialog. Three steps. Each one drops a fraction of the people who started.

The single-tap version skips all of that. It works because phone calendar apps recognise a specific text format the moment they see it — the iCalendar format, defined in RFC 5545 and shipped with every major operating system. Encode that format inside a QR code, and a scan opens the calendar with the event pre-staged. No website, no form, no confirmation email.

This post covers the format itself, the quirks between iOS and Android parsers, when calendar QR codes beat a registration link (and when they don't), and the mistakes that turn "add this event" into a silent failure.

The iCalendar format — VEVENT in plain English#

A calendar event QR code encodes an iCalendar payload — the same format .ics files use to send events around. The skeleton is dead simple: a VCALENDAR envelope with one VEVENT block inside it.

The wrapping BEGIN:VCALENDAR ... END:VCALENDAR is mandatory — without it, parsers either ignore the QR or pop up an error. The VEVENT block is where everything you actually care about lives:

• UID — a unique identifier for the event, usually eventname-date@yourdomain. If the same UID shows up twice in someone's calendar, the second import overwrites the first. Useful when you're updating an event after sharing the QR.
• DTSTAMP — the timestamp this VEVENT was first created. Apple Calendar shrugs without it; Google Calendar on Android refuses to import.
• DTSTART — start time, in ISO 8601 with no separators. 20260915T180000Z means 18:00 UTC on September 15, 2026. The trailing Z makes it UTC; drop the Z and add ;TZID=Europe/Amsterdam:20260915T200000 if you want a specific timezone.
• DTEND — end time, same format. Mandatory in practice — Google Calendar prompts the user to pick one if it's missing.
• SUMMARY — the event title. Shows in the calendar's day view.
• LOCATION — venue. iOS auto-links it to Maps; Android auto-links to Google Maps.
• DESCRIPTION — body text. Phone numbers and URLs in here become tappable on iOS.

A complete payload runs about 250 characters. Comfortable to fit in a QR code that scans cleanly at A4 print size.

Why this beats a registration link sometimes#

Registration pages have a job: collect email addresses, get consent, qualify attendees. If the event is small, free, drop-in, or already public — none of those jobs apply. A calendar QR is faster, has zero dependencies, and never breaks because your form provider went down on the morning of the event.

When the event is the product, skip the form. The friction of "scan a code, tap Add, done" is half the friction of "scan a code, type your email, click the verification link, then add to calendar."The Linked.Codes editorial team

Three places this works particularly well:

Pop-up events. Saturday market, gallery opening, supper club, art crawl. Print one QR on the flyer; a passer-by who's curious adds it to their phone in one motion. No download, no funnel.

Recurring sessions where you already know the audience. Yoga studio's Tuesday class, weekly meetup, monthly book club. Members who scan get the event reminders without you maintaining a mailing list.

Conferences with public sessions. A keynote, an outdoor screening, a fireside chat. Attendees who already paid don't need to register a second time — the QR just gets the slot into their calendar so they don't miss it.

Compare that to the standard funnel: lander → email and name fields → terms checkbox → submit → "check your inbox" → spam folder check → "add to calendar" link → calendar app. A calendar QR collapses all of it into one tap.

The iOS vs Android quirks#

iPhones handle calendar QR codes through the built-in Camera app. Scan, tap the prompt at the top of the screen, the calendar opens with "Add Event" and the fields populated. iOS is generally forgiving — most field omissions are tolerated, and the calendar fills in defaults.

Android is a different animal. Google's calendar parser is stricter:

• Always include DTSTAMP. This is a "when was this VEVENT first created" timestamp, separate from DTSTART. Apple Calendar shrugs without it; Google Calendar on Android refuses to import.
• Always include DTEND. A missing end time prompts Google to ask the user to pick one before saving — an extra tap that defeats the whole point.
• Use UTC or include a TZID. Floating times (no Z, no TZID) become 00:00 in some Android builds. Specify the timezone explicitly.

Google's Calendar app on Android also handles the mailto: portion of the iCalendar ATTENDEE field cleanly — useful if you want the event to suggest an email reply to a host. iOS opens Maps for LOCATION: if it can geocode the string.

Building one — the dynamic vs static choice#

You have two ways to ship a calendar QR:

Static. Encode the entire iCalendar payload inside the QR itself. The QR's pixel grid IS the event. Anyone who scans it gets the event without anything calling home. This is the lowest-dependency option — works offline, works after your domain expires, works in five years.

Dynamic. The QR encodes a short URL like linkedco.de/april-meetup. Scanning hits your server, which serves an .ics file. Same end result for the user — calendar app opens with the event — but you can change the date if it moves, or the location if the venue cancels, without reprinting the flyer.

Dynamic wins for any event that might shift. Static wins for events you're confident won't move and where your domain might not be live forever (charity events, one-off pop-ups, time capsules). Linked.Codes ships the dynamic variant via the Calendar destination type — fill in title, date, time, location and the slug serves the right .ics file every time.

The widget below builds a static iCalendar payload from your inputs. Copy it into any QR generator that accepts arbitrary text, or paste it into the Linked.Codes QR designer on a Calendar-type link.

Common mistakes (and how to spot them)#

A calendar QR that doesn't scan into a calendar fails silently — the user assumes the QR is broken or the event isn't important. You won't get bug reports; you'll just lose attendance. Five mistakes to check before you print.

Skipping DTSTAMP. Google Calendar treats this as a malformed event and refuses the import. Apple Calendar accepts it. If your event "doesn't add" on Android phones but works on iPhone, this is the first thing to look at.

Using local time without a timezone. DTSTART:20260915T180000 (no Z, no TZID) is "floating time" — not allowed for events with a fixed location. Some parsers default to UTC; others to local; some refuse. Always specify.

Reusing the same UID across events. Every event needs a unique UID. If you copy a working .ics and just change the title and date but leave the UID, the second event silently overwrites the first in anyone's calendar who has both.

Wrapping lines past 75 characters. RFC 5545 says lines longer than 75 octets must be folded with a CRLF + space continuation. Most parsers tolerate long lines, but some Android Calendar builds choke. If your DESCRIPTION is a paragraph, fold it.

Including HTML in DESCRIPTION. Calendar apps render this as literal text. <br> shows up as the four characters <br>. Use \n (escaped newline) for line breaks; use plain text for emphasis.

When NOT to use a calendar QR#

Calendar QRs are a precision tool, not a default. Don't use one when:

You actually need attendee data. RSVPs, dietary requirements, name on the door, T-shirt size, capped capacity. The form is the point; replacing it with a calendar QR means you've lost the data.

The event is fundamentally a webinar or stream. Add the join URL into the DESCRIPTION, sure — but most virtual events benefit from the registration page anyway because that's where you deliver the link, the calendar invite, and the reminder email. The calendar QR is the bonus, not the main route.

Capacity matters. A small studio class, a private dinner, a venue with a fire-marshal limit. Friction is a feature here — the form is what counts heads. A frictionless add-to-calendar gives you no idea who's coming.

The event might fundamentally change. A static QR encoding the entire payload can't be edited after print. If "we might move this" is even a 10% possibility, ship the dynamic version through a short link so the QR you printed last week can serve next week's revised event.

Related reading#

If you're working with structured-payload QR codes generally, the principles transfer:

• WiFi QR codes — same pattern, different format. Encode credentials in a known string, phone parses it natively.
• vCard QR codes — sister "structured data in a QR" format. Same RFC-era approach.
• Static vs dynamic QR codes — the editing trade-off in more depth.
• URL vs short-link QR codes — when to encode the destination directly versus going through a redirect.