Generate a code for a ticket or pass so staff on the door can read its details with a phone instead of squinting at a printout.
A printed ticket code is copyable by design, and a photograph of it works as well as the paper does. If entry has to be controlled, the reference in the code needs checking against a list your staff hold. A spreadsheet on a tablet is enough for a few hundred people.
Enter content to generate QR code
The code carries labeled text (ticket reference, event name, date, venue and seat) and nothing else. Scanning shows those lines on screen. There is no check-in, no database and no way for the code to know it has been used before, so this type produces a readable ticket, not a validated one.
Reference, event, date, venue and seat, and the code holds:
TICKET:TKT-12345
EVENT:Spring Recital
DATE:2026-05-09
VENUE:Old Town Hall
SEAT:A12Labeled lines a person can read off the screen. Nothing in it is a link or a lookup, which is why the door still needs a list to check the reference against.
Anyone can photograph a ticket and show the photo, and the code cannot tell the tenth scan from the first. For a door that has to be controlled, the reference in the code needs to be checked against a list your staff hold — a spreadsheet on a tablet is enough for a hundred people. Anything larger belongs in a ticketing system that issues and validates its own codes.
Everything in the code is readable by anyone holding the ticket, including whoever finds it on the floor afterwards. Encode a booking reference and the event details; leave names, phone numbers, email addresses and payment references out. If the door staff need to match a name, they should look the reference up, not read it off the ticket.
Each ticket needs its own reference, so a run of unique tickets is really a run of unique codes. Generate them from your booking data rather than by hand: one code per row. Keep the same field order on every ticket so door staff read them at a glance.
Most people will present the ticket on a phone. Screen brightness is the variable that decides whether that works: ask guests to turn it up, and avoid dark ticket designs, which lose contrast when a screen dims automatically. A printed copy is worth keeping available for anyone whose phone dies in line.
Each code has to be generated from its own reference, so a batch means generating one code per booking. That is best driven from your ticketing data rather than typed by hand.
A reference your door staff can look up, plus the event, date and venue for context. Never personal data — anyone who picks the ticket up can read every character of it.
No. It carries text and has no memory. Preventing duplicate entry means checking the reference against a list, or using a ticketing platform that issues validated codes.
Yes, provided the brightness is up. Keep the design high-contrast — dark ticket artwork loses readability the moment a screen dims itself.
A QR code if a phone camera will read it, since phones read QR natively and it holds more text. A linear barcode if you are scanning with handheld hardware already deployed at the door.
No, and it would defeat the purpose. Each code carries its own ticket reference; a dynamic code would give every ticket in the run the same short link, so the door could no longer tell one from another. Uniqueness per ticket is the whole point.