Event QR Code Generator

An event code carries a calendar file, not a link#

Scanning an event QR code hands the phone a VEVENT record — the same iCalendar structure (RFC 5545) that powers every .ics attachment you have ever received. The phone recognises the format, shows an "Add to Calendar" preview, and waits for confirmation.

BEGIN:VEVENT
SUMMARY:Quarterly Design Review
DTSTART:20260914T130000Z
DTEND:20260914T153000Z
LOCATION:Studio 4, 118 Mill Street, Bristol
DESCRIPTION:Bring printed boards. Coffee from 12:30.
END:VEVENT

Because the data is embedded, this works with no internet connection — useful at venues with poor signal, which is a great many venues. The trade-off is the usual one: if the date moves, every printed code is wrong and there is nothing you can do about it.

Timestamps are where these go wrong#

Almost every failed event QR code fails on time zones. There are three ways to write a timestamp and they behave very differently.

UTC (recommended). A trailing Z means the time is in UTC and the phone converts it to whatever the user's device is set to:

DTSTART:20260914T130000Z

An attendee in Bristol sees 2:00 pm BST. One in Berlin sees 3:00 pm CEST. Both are correct, and both arrive at the right moment.

Floating local time. No Z, no time zone reference:

DTSTART:20260914T140000

This means "2:00 pm wherever the user happens to be," which is right for a purely local event and disastrous for anything with remote attendees — a viewer in New York sees 2:00 pm Eastern, five hours adrift.

All-day events use a date with no time and require the VALUE=DATE marker:

DTSTART;VALUE=DATE:20260914
DTEND;VALUE=DATE:20260915

Note that DTEND for an all-day event is exclusive — a one-day event on the 14th ends on the 15th. Set both to the 14th and some calendars will show a zero-length event or drop it entirely.

Use UTC unless you have a specific reason not to. Convert carefully: British Summer Time is UTC+1, so a 2:00 pm September event in the UK is 130000Z, not 140000Z. Getting this wrong by an hour is the single most common defect in event codes and it is invisible until someone arrives late.

Field by field#

Keep LOCATION in a form a mapping app can resolve — a full postal address, not "the usual place." Most calendar apps pass this string straight to Maps when the user taps it.

Density: this is a heavy payload#

Event records are among the largest common QR payloads. The field names alone are verbose before you write any content.

The DESCRIPTION field is where codes get out of hand. Two sentences of prose can double the payload. If you need to say more than a line, put a URL in the code instead and let the page carry the detail.

Line folding, and why a hand-built file may fail#

The iCalendar specification limits lines to 75 octets and requires longer values to be folded — split across lines with each continuation starting with a single space. A long DESCRIPTION written as one unbroken line violates the spec, and while many parsers tolerate it, some reject the whole record.

You also need to escape certain characters inside field values: commas as \,, semicolons as \;, and newlines as \n. An address containing an unescaped comma can truncate the location or corrupt the fields that follow.

The generator above handles folding and escaping. It is worth knowing about if you have ever pasted a VEVENT into a QR tool and had it silently produce an event with no location.

Platform behaviour#

iOS recognises VEVENT data from the Camera app and offers to add it to the default calendar. The user sees a preview with the title, time and location before confirming.

Android handling depends on the scanner. Google Lens and most dedicated scanner apps parse VEVENT and hand it to the calendar. Some manufacturer camera apps show the raw text instead — a real gap that argues for testing on a couple of Android devices before printing.

Recurring events using RRULE are supported by the specification and inconsistently supported by scanners. If you need recurrence, host an .ics file and encode its URL instead; a subscribed calendar feed also lets you change the schedule later, which an embedded VEVENT never will.

When to encode a URL instead#

Embed the VEVENT when the details are fixed and the venue may have poor signal — a wedding invitation, a conference session card, a one-off workshop.

Encode a URL to an .ics file or a ticketing page when:

• The date, time or venue could still change
• The event recurs
• You want to know how many people added it
• You need to send updates or cancellations to people who already added it
• The description runs to more than a line

The hosted route also lets you offer platform-specific "Add to Google Calendar" and "Add to Outlook" buttons, which convert better than a raw .ics download for less technical audiences.

Testing#

1. Scan with an iPhone and check the time displayed matches the intended local time.
2. Scan with an Android device — ideally one using the stock camera and one using Google Lens.
3. Change your phone's time zone temporarily and rescan. If the event shifts correctly, your UTC handling is right; if it does not move at all, you encoded floating time.
4. Tap the location in the calendar entry and confirm it resolves to the right place on a map.
5. For all-day events, confirm the event appears on the correct day and not spanning two.

Frequently asked questions#