QR codes for events: tickets, check-in, signage and wifi

Doors open in ten minutes, there are two hundred people in a queue, and the check-in app is spinning because the venue wifi has just been saturated by the same two hundred people. QR codes at events fail on operational details, not on encoding.

Three jobs, three different codes

The word “event QR code” covers three things that share nothing except the symbology.

Designing them as one thing is the root of most event QR problems. A ticket needs to be unique, private and verifiable offline. Signage needs to be readable from across a hall by a hundred people at once. A wifi card needs to be convenient and is, by design, not a secret at all.

What a ticket code must encode

A ticket identifies one attendee, which makes it the only one of the three with a security model.

Never encode the attendee’s details. A code containing a name, an email address or an order reference is readable by anyone who photographs the ticket or glances at the screen in a queue. It is also forgeable: if ORDER-10432 is a valid ticket, so is ORDER-10433.

Encode one of two things instead.

An opaque random identifier, which means nothing without your database:

https://ev.example/t/9f2a7c14b8e3

Or a signed token, which the scanner can verify without any database at all:

https://ev.example/t/K7dQ2p.9xR3vLmQ0aZbT4nH8sYcUg

The second form — an ID plus a truncated HMAC over it, using a key only your scanners hold — is what makes genuine offline validation possible. Nobody can mint a valid ticket without the key, and no lookup is needed to reject a forgery.

The cost is module count, and it is worth knowing before you design the badge. That opaque identifier is a version 3 symbol at level M: 29 modules, 37 across with the quiet zone. The signed token is 50 characters and pushes it to version 4 at M — 33 modules, 41 across. At the 0.4 mm module that a decent printed ticket supports, that is 14.8 mm versus 16.4 mm. Neither is a problem on a sheet of A4; both matter on a wristband.

Two more rules. Make the URL a real page you control, so a scan by a member of the public with an ordinary camera app lands somewhere sensible rather than on a raw string. And use HTTPS on a domain the attendee recognises — event weeks are prime season for the sticker-and-lookalike-domain attacks described in the QR code security article.

Offline check-in is the default assumption

Venue wifi is a hostile environment. Several hundred phones associating at once, a router provisioned for the bar rather than the door, and a cellular cell that was fine yesterday and is now shared with a full hall.

Build check-in so the network is optional:

• Pre-load the guest list onto every scanning device before doors, and refresh it at a known moment rather than continuously.
• Validate locally. With signed tokens the scanner needs only the key; with opaque IDs it needs the downloaded list. Either way, the decision to admit should not involve a request.
• Queue the scan records on the device and sync opportunistically. A failed sync must never block the next scan.
• Reconcile between devices on whatever schedule the network allows, and accept that between reconciliations two gates can each accept the same ticket.
• Have a printed guest list for the moment everything else has failed.

Test all of this in the venue, at the time of day the event runs, with the devices you will use. A check-in flow that works in the office is untested.

Duplicate scans

The code carries no state. Whether a ticket can be used twice is entirely a decision in your system, and the useful design is not a hard block.

Record the first successful scan with its time and gate. On a repeat, show the staff member the original scan details and let them decide: a family sharing one phone, a re-entry after a smoking break and a genuine duplicate look identical to software and completely different to a person on the door. A silent rejection produces an argument at the gate; an informative warning produces a judgement.

Log every scan, including rejections. After the event, repeated rejections clustered at one gate usually mean a lighting or screen-brightness problem rather than fraud.

Sizing: from a lanyard badge to a hall banner

The 10:1 rule from what size a printed QR code should be applies directly, and events span an unusually wide range of it.

Two event-specific notes. On a badge, put the code on the lower half so a lanyard clip cannot cover it, and skip the glossy laminate pouch if you have the choice — the testing procedure will show you why in about thirty seconds under a spotlight.

On large signage, the constraint is rarely the code and usually the light. A banner lit from above with a spot produces a bright band across the symbol; a banner in a dark hall gives phones nothing to focus on. Size up, and keep the destination URL short so the module count stays low and each module stays large.

When the ticket is on a phone screen

Most tickets arrive as pixels, not paper, and screens introduce their own failure modes.

Brightness. Phones dim automatically to save battery, and a dimmed screen under strong door lighting has almost no contrast left. Tell attendees to turn brightness up in the confirmation email, and if you control the ticket app, force maximum brightness on the ticket screen.

Dark mode. A ticket rendered white-on-black is an inverted code. Many decoders handle inversion; not all do, and the ones on the door often will not. Render the ticket with dark modules on a light background regardless of the system theme.

Auto-lock. A phone that locks while its owner is fishing it out of a pocket means a second attempt. A ticket page that requests a wake lock, or simply a sign asking people to have the ticket open, removes a surprising amount of queue time.

Physical screens. Cracked glass, a matte protector and a fingerprint-covered display all cost contrast. This is the case where a scanner app on the door device beats a camera app: it will keep trying where the camera gives up. Wallet passes sidestep most of this — they handle brightness, they work offline and they are already on the lock screen.

The wifi card on the table

The third code is the easy one, and the one people over-think. A WIFI: string encodes the network name, the security type and the password in cleartext — anyone who can scan it or photograph it can read the password. That is the design, not a flaw. It is a convenience for a credential you were going to print on a card anyway.

For an event that means: put it on the guest network, never the network the AV desk and the payment terminals are on, and rotate the password after the event. The exact syntax, the five characters that need escaping and the differences between iOS and Android are in the WIFI: string reference, and /wifi-qr-code/ will build the code for you.

While you are printing table cards, a vCard code on the back of a speaker’s badge or a stand panel is the other genuinely useful non-ticket code at an event — a scan drops the contact straight into a phone, which is faster than anything involving a form.

Run of show

Two weeks out. Ticket format decided and codes generated. Signage artwork proofed at final size on final stock and scanned on three phones. Destination pages live and tested on mobile data with wifi off.

One week out. Scanning devices configured, guest list sync tested, offline mode tested with aeroplane mode on. Wifi guest network created with its event-specific password, and the card proofed.

Day before. Walk the venue with a phone. Scan every piece of signage from where people will actually stand, in the lighting that will be on. Charge and label every scanning device.

Doors. Guest list refreshed on every device at a known time. Printed fallback list at the master desk. One person who knows how to look up a ticket manually. Brightness reminder on the door signage.

After. Export the scan log, look at rejection clusters by gate and by time, and note which signage actually got scanned. That last number is the one that tells you what to print next year.

Codes for all of it — tickets, signage, wifi, vCard — come out of the generator, and if your own system mints the tickets, the image API will produce them one URL at a time.