Use Cases
QR Codes for Event Check-In & Ticketing
Ticketing is the most technically demanding thing on this list, because the requirements go well beyond "does it scan." Each ticket needs to be unique, single-use, hard to forge, and readable in about a second by a volunteer in bad light while a queue builds. That's a different problem from putting a menu behind a code, and it needs a system rather than a generator.
The short version
- Ticket codes are not marketing codes. One unique code per attendee, issued by a ticketing system.
- Never encode personal data in the ticket. Encode an opaque identifier and look it up.
- Plan for the venue Wi-Fi failing — it will, at exactly the wrong moment.
- Decide your duplicate-scan policy before the door opens, and tell the volunteers.
- Screens beat paper at the door, but accept both — batteries die.
- Test scanning under the actual door lighting, which is usually worse than you expect.
Ticket codes vs. marketing codes
Every other use case in this section uses one code that many people scan. Ticketing inverts that: many codes, each scanned once. That single difference drives everything else.
It means a QR generator is the wrong tool. You need something that issues a unique code per ticket, records which have been used, and can answer "is this valid, right now, at this door?" in under a second. That's a ticketing platform or a purpose-built check-in system — the code itself is the least interesting part.
Where a plain generator is right for an event: the registration link on the poster, the schedule code in the programme, the feedback form at the end, the Wi-Fi code on the table. Those are ordinary one-to-many codes and belong in the rest of this guide.
What to put in the ticket code
The rule: encode an opaque identifier, not information.
A ticket code should contain something like a long random token, which the check-in system looks up. It should not contain the attendee's name, email, ticket type or seat — for three reasons:
- Privacy. Anyone who photographs a ticket over someone's shoulder can read whatever is in it. Names and emails in a scannable code are a data leak with extra steps.
- Forgery. If the code contains readable structure, it can be edited. A random token can only be checked against a list.
- Density. Encoded personal data makes the code larger and slower to scan, which matters when there's a queue.
Generating tickets by encoding "Name — Ticket Type — Order Number" into a QR code is common at small events and is both a privacy problem and trivially forgeable: anyone can generate the same string. If your tickets can be recreated from information printed on the ticket, they are not tickets, they are decoration.
Duplicate entry, and deciding the policy first
QR tickets are copyable by nature — a screenshot forwarded to a friend scans exactly like the original. The defence is not the code; it's the check-in system marking each one used.
Decide in advance what happens on the second scan, because the volunteer on the door will need an answer immediately:
- Hard reject. Right for paid events with capacity limits. Loud, unambiguous feedback on the scanner.
- Warn and allow, with a log. Right for free community events where a false rejection is worse than a duplicate.
- Re-entry allowed. Festivals and multi-day events — the system should count scans rather than blocking them.
Whatever you pick, brief the people on the door and give them a fallback: a named person who can override, and a way to check someone in manually. A queue stopped by a policy question is worse than either policy.
Scanning at the door
This is where events actually go wrong, and almost none of it is about QR codes.
- Assume the venue Wi-Fi will fail. It's the single most reliable prediction in events. Use a check-in app that caches the attendee list locally and syncs later, and test that mode deliberately by putting the device in airplane mode.
- Use mobile data as the primary connection where you can, with Wi-Fi as backup rather than the other way round.
- More scanning devices than you think. Check-in is bursty — most people arrive in a fifteen-minute window, not spread over an hour.
- Charge everything, and bring battery packs. Continuous camera use drains a phone in a couple of hours.
- Light the scanning position. Doors are often dim, and a phone screen held out by an attendee in bright sun is also hard to read. Both are solvable with where you stand.
- Have a manual fallback. A printed alphabetical list, or search-by-name in the app. Something will go wrong for someone.
The most common door delay isn't a bad code — it's a phone at 20% brightness in auto-dim, held at an angle, reflecting the ceiling lights. One line in the reminder email ("turn your screen brightness up before you reach the door") measurably speeds up a queue.
Delivering tickets
| Format | Strengths | Watch out for |
|---|---|---|
| Email with the code inline | Universal, easy to find again | Images blocked by default in some clients |
| Wallet pass (Apple/Google) | Best experience — brightens automatically | More setup; not everyone will add it |
| PDF attachment | Printable, works offline | Awkward to open on a phone at a door |
| Printed at home | No battery, no signal | Folds — keep the code clear of the crease |
| Printed and posted | Feels premium; good for gala events | Lead time; no way to fix an error |
Wallet passes are the best door experience by a distance — they're findable on a lock screen and most implementations brighten the screen automatically. But send an email with the code inline too, because a meaningful share of attendees won't add the pass.
For printed tickets, keep the code at least 3 cm and well clear of any fold. A crease across a corner finder pattern is unrecoverable — see scanning failures for why corners specifically can't be repaired by error correction.
The other event codes
Beyond tickets, ordinary codes do useful work at events, and these are a job for a generator:
- Registration on posters and social graphics — dynamic, so it can be repointed to the waitlist once you sell out.
- Schedule in the printed programme, repointed as the schedule changes.
- Wi-Fi on table cards — one scan to join, which removes an enormous number of questions from your staff.
- Feedback on the closing slide and on the way out, while the event is still fresh.
- Speaker slides or resources, which saves collecting email addresses to send them later.
- Sponsor links on stand signage, with a unique code per sponsor so you can report scan numbers back to them — a genuinely saleable benefit.
Frequently asked questions
How do QR code tickets work?
The ticketing system issues a unique, random identifier per ticket and encodes it into a QR code. At the door, a scanner reads the code, looks the identifier up, checks it's valid and unused, and marks it used. The code itself contains no information about the ticket or the attendee — it's just a token. That lookup step is what makes the ticket single-use, which is the whole point.
Can someone copy or screenshot a QR ticket?
Yes, trivially — a screenshot scans identically to the original. That's why the security lives in the check-in system rather than the code: the first scan marks the ticket used, and the copy fails. Decide before doors open what happens on a duplicate scan (hard reject, warn-and-allow, or allow re-entry) and brief the people scanning, because they'll need an answer instantly with a queue behind them.
What happens if the venue Wi-Fi fails during check-in?
It will, so plan for it. Use a check-in app that caches the attendee list on the device and syncs afterwards, and test that offline mode deliberately by putting a phone in airplane mode before the event. Prefer mobile data as the primary connection with Wi-Fi as backup, and keep a printed alphabetical list as a last resort. A queue that stops moving is the failure everyone remembers.
Should I put attendee names in the QR code?
No. Anyone who photographs a ticket can read whatever is encoded in it, so names and email addresses in a scannable code are a data leak. It also makes tickets forgeable — if the code contains readable structure, someone can generate their own. Encode an opaque random token and let the check-in system resolve it to a person.
Do I need a ticketing platform, or can I generate the codes myself?
For real ticketing, you need a system that issues unique codes and tracks which have been used — that's what makes a ticket single-use, and a QR generator can't do it. A generator is the right tool for the event's other codes: the registration link on the poster, the schedule in the programme, Wi-Fi on the tables, the feedback form at the end. Those are ordinary one-to-many codes.