Event QR Codes: Tickets, Check-In and the Day Itself

You are printing invitations, or a lanyard, or a sign for the entrance, and there is a square to fill. The question is not whether to put a QR code on it. It is what should happen when someone scans it.

Get that wrong and you have printed a code that opens a page nobody needed. Get it right and you save every guest the job of typing an address into a calendar at a traffic light.

Decide what the code is for, before you make it

An event code does one of three jobs. Pick one before you design anything.

• Save the date. The scan puts the event in the guest's calendar, with the right time, the right venue, and a reminder. This is the job most invitations actually need.
• Answer questions. The scan opens a page with the schedule, the dress code, parking, the WiFi password, who is speaking and when. This is the job most conferences need.
• Take an action. The scan opens an RSVP form, a ticket purchase, or a registration page you already run somewhere else. The code is just a shortcut to a link.

A single code can cover the first two together. The third usually belongs to whatever system is already handling your tickets, and the code's only job is to get people there without typing.

A calendar entry, or a page?

This is the real fork, and most event-code guides skip it.

A plain calendar entry

A QR code can hold a calendar event directly. Scan it and the phone offers to add the event. Nothing is hosted anywhere, nothing can be switched off, and it works for as long as phones read QR codes.

The limit is that it is frozen. The venue, the time, and the title are inside the pattern. Move the start time by half an hour and every printed code is now wrong, and there is no way to correct it except reprinting.

A page about the event

The other option is a hosted page: the code points at a short address you control, and the page holds everything. That is what an event QR code builds here. The page shows the date, the venue, a countdown, directions, an agenda, and a button to add the event to a calendar.

Because the page is the destination rather than the data, you can fix a typo in the venue name at 9pm the night before and every card already in the post is correct again. The pattern does not change.

That is the same trade-off that decides every printed code, covered at length in dynamic vs static QR codes. For an event, the hosted page nearly always wins, because event details change and invitations get printed early.

The time is the part people get wrong

An event at 6:30pm happens at 6:30pm at the venue. Not 6:30pm wherever the guest happens to be standing when they scan.

That sounds obvious and it is where most calendar links break. A conference listed as 9am for a guest flying in from another country turns into 5am in their own calendar, and they only notice the morning of. Our event pages store the time as the venue's own clock plus the venue's timezone, so the time on the page is the time at the door. Visitors abroad see a short zone label next to it, like GMT+4, so there is no guessing about whose clock they are looking at.

Three more details worth setting deliberately:

• An end time. Leave it out and the calendar entry gets a one-hour default, which is what a guest will plan the rest of their evening around. For a four-hour wedding reception, that is a problem you can avoid by typing one field.
• All day, when it is all day. A festival or an open house belongs in the calendar as a whole day rather than a 9am appointment that the guest then has to widen by hand.
• Multi-day runs. A conference across three dates should be one entry spanning three dates, not three codes.

For a calendar button, the provider matters more than it should. A plain calendar file is the right answer on an iPhone or in Outlook and a dead end in Chrome on Android, where it downloads and sits there. Our event pages ask which calendar instead, and offer Google Calendar, Apple Calendar, and Outlook, which is one extra tap and far fewer guests who never managed it.

Check-in at the door, honestly

This is the part worth being straight about, because "QR code check-in" is sold hard and means something specific.

A single QR code on a sign or an invitation cannot check anyone in. Check-in means knowing that this particular person has arrived, which needs two things: a code that is unique to each guest, and something at the door that reads it against a guest list and marks them off. One code shared by 200 people cannot tell you who scanned it, and a code that just opens a web page has nothing to mark off.

So if real attendance tracking is the requirement, use a ticketing system that issues a unique code per attendee and gives the door staff a scanner app. That is what those platforms are for, and an event page is not a substitute for one.

What a code at the entrance does do well is answer the questions people ask while standing in a queue. Where is the hall. What time does the keynote start. Which floor is the cloakroom. What is the WiFi password. A sign by the door with one code, and nobody asking you any of it, is a genuinely good use of five minutes of setup.

One honest note on numbers: a hosted code counts scans, and scans are not arrivals. One guest scanning three times is three scans, and the forty people who walked in behind a colleague are none. Use the number to compare signs against each other, not as a headcount.

Printing it: invitations, lanyards, and signage

The code that fails on the day is almost always a code that was printed too small or trimmed too close.

• On an invitation held in the hand, 2 cm square is enough, and 2.5 cm is comfortable.
• On a lanyard or a badge, keep it at least 2 cm and leave the margin around it clear. A badge code is scanned at arm's length by someone else, often in bad light.
• On a sign people scan from two or three metres away, the code needs to be about a tenth of that distance across: 20 cm to 30 cm square for a corridor, larger for a hall.
• Leave the quiet zone alone. The clear margin around the pattern is part of the code, and a designer tightening the layout is the most common way it disappears.
• Print a proof and scan the proof, not the file on your screen.

If a test code refuses to read, the cause is usually one of a short list, and why your QR code won't scan works through them in order of likelihood.

Two placement notes that only matter at events. Do not laminate a code that will sit under a spotlight, because the glare turns it into a white rectangle from exactly the angle people stand at. And do not put the only code at the registration desk, where it is unreachable the moment a queue forms.

The week after

The event ends and the code stays out there, on cards in wallets and photos on phones. A hosted page gives you something to do with that.

Replace the page content with what is useful now: the slide decks, the photo album, a feedback form, the date of the next one. Our event pages carry a countdown that turns into "Happening now" when the event starts and "This event has ended" after it finishes, so a guest scanning late is never misled about whether they have missed it.

This is the quiet advantage of pointing a code at a page rather than baking the details into the pattern. The card in someone's drawer from last November becomes the invitation to this November, with no reprint.

What it costs

Plain codes are free to make and need no account. A hosted event page keeps its content and its scan records on the platform side, which is free to start, and saving one means signing in so the page has an owner who can edit it later.

On the records themselves, worth being precise where most providers are vague: a scan stores a timestamp, roughly where the scan came from, and what referred it. The visitor's address is kept only as a salted hash, so the address itself is never stored. It tells you which sign worked. It does not tell you who was standing there.

Decide what the scan should do, keep the time in the venue's own clock, and be honest about the door. The rest is printing it big enough.