QR Codes for Events & Ticketing

Scanning phone screens is a different problem to scanning print

Almost every other use of a QR code involves a camera reading ink on paper. Event entry usually involves a scanner reading a code displayed on a guest’s phone screen, and screens fail in ways paper does not.

Screen brightness set low to save battery is the most common cause of a ticket that will not scan, followed by aggressive auto-dimming, a cracked screen across the pattern, and a heavy screen protector with a matte or privacy film. None of these are within your control on the night, so the design has to absorb them.

• Tell ticket holders, in the confirmation email and on the ticket itself, to turn brightness up before reaching the door.
• Render the ticket code large on screen — at least 60% of the screen width — and on a plain white background.
• Offer a wallet pass or downloadable image so entry does not depend on loading a page in a crowded venue with no signal.
• Use error correction level Q or H, which recovers a damaged pattern and buys tolerance for cracked screens and glare.

Throughput at the door is a design decision

The scanning itself takes a fraction of a second. Everything around it is what creates the queue: finding the email, waking the phone, brightness, the scanner focusing, and the confirmation coming back from a server.

The last of these is the one venues underestimate. If validation requires a round trip to a server and the venue’s connection is saturated by a few thousand phones, each scan can take seconds instead of milliseconds. Ask whether your check-in tool can validate offline against a downloaded list and reconcile afterwards, and confirm it before the night rather than discovering it at the gate.

Screenshots, sharing and why static ticket codes leak

A static QR ticket is a picture. It can be screenshotted, forwarded and posted, and every copy scans exactly as well as the original. Whether that matters depends on your event, but for anything with a real gate value it matters a great deal.

The usual defences are to bind the code to a named attendee and check identity at the door, to invalidate a code the first time it is scanned so duplicates are rejected, or to use a rotating code that regenerates on a timer so a screenshot expires within a minute. Rotating codes are the strongest and the most infrastructure to run; single-use invalidation covers most events adequately.

Printed passes and badges have the opposite profile: they cannot be forwarded electronically, but they can be lost, and they cannot be changed after printing. A dynamic code on a printed badge is a useful middle ground — the badge stays valid while the content behind it, the programme, the room changes, the sponsor offer, can be updated all week.

Badges, lanyards and wristbands

Codes on badges are scanned in two quite different ways: at a door from around 30cm, and by other attendees at conversational distance for contact exchange. Size for the longer of the two.

The practical difficulty is movement. A badge on a lanyard swings, turns edge-on and sits at an angle on a chest, so the code is rarely presented flat. Keep it large, print it in the lower half of the badge where it sits flatter, and avoid gloss lamination on the badge face. On wristbands, curvature is severe and the printable area narrow — treat a wristband code the way you would a bottle, with extra size and placement on the flattest span.