How to make QR code name badges for an event

The five-minute version

1. Export the registration list as CSV. You need two columns: a unique ID per attendee and the name that prints on the badge.
2. Encode the ID, not the person. Plain text REG-0417, or a URL on your own domain ending in the ID. Never the attendee’s email or phone.
3. Generate the batch with a static bulk generator and use the name column as the caption, so each file is identifiable before it reaches the badge template.
4. Print one badge on the real stock, scan it under the venue’s lighting, then print the run. Bring a paper copy of the list.

Encode the ID, never the person

This is the one rule that matters more at an event than anywhere else. A QR code is not private: it is a public encoding that any phone in the room can read in a second. A badge hangs at chest height for eight hours and ends up in other people’s photographs.

• Registration ID (REG-0417). The smallest possible code, and it means nothing to a stranger who scans it. Your check-in app resolves it against the list you already hold.
• URL on your own domain (https://yourevent.com/c/0417). Useful if staff check people in with a plain phone camera rather than a scanner app. Slightly larger code, and it needs a working connection.
• vCard with the attendee’s contact details. Do not — not on the badge itself. It is tempting for networking, but it hands every passer-by a phone number and an email address. If you want scan-to-connect, encode an ID that resolves to a profile the attendee controls and can turn off.

The same logic applies to the business-card guide, but with the opposite conclusion: a card is something you hand to a chosen person, so a vCard in the code is exactly right. A badge is something you wear in front of everyone. The medium decides what belongs in the pattern.

Why badge codes should be static

A dynamic code is a link to a redirect service that then points at your destination. For a badge that buys you nothing and costs you the two things an event cannot spare.

• Nothing needs editing. Badges are printed days ahead and thrown away that evening. The whole selling point of a dynamic code — change the destination after printing — has no use inside a one-day lifespan.
• Venue wifi will fail. A static ID scans off the paper into a scanner app that holds a local copy of the list, so check-in keeps moving through a dead network. A dynamic code must reach someone else’s server before it resolves to anything at all.
• Volume is where dynamic gets expensive. Three hundred attendees is three hundred hosted redirects, which is exactly why bulk free tiers meter at 50 or 100. The static-vs-dynamic guide works through the trade in general.

One boundary worth naming: a badge identifies — it says which registered person this is. It does not admit. If entry itself is paid or limited and a copied code would cost a seat, that is a ticket, a single-use bearer code with its own rules — random IDs and a first-scan-wins door list — covered in the event-tickets guide. Many events need both: the ticket gets you through the door once, the badge identifies you all day.

Badge layout and code size

A standard badge insert is 4x3 inches (about 102x76 mm), and the QR code is not the main event on it — the human name is. Someone across a table reads the name; only the scanner reads the code.

• Name first, big. First name at 40-60 pt, readable from two metres. Organisation underneath, smaller. The badge fails if a human has to squint, no matter how well it scans.
• Code around 20 mm square for a short ID at arm’s length. A full URL becomes a denser code and wants 25 mm for the same reliability, which is a real argument for encoding the bare ID. The print-size guide has the distance and density tables.
• Bottom corner, with its quiet zone intact. Four modules of white on every side. The classic badge failure is a code printed flush to the edge of the insert, where the plastic holder’s lip covers two modules and nothing scans.
• Matte stock, and mind the holder. Glossy inserts behind glossy plastic under venue spotlights produce glare, the single most common cause of a code that scans at your desk and fails at the door — see the not-scanning guide.

From registration export to printed badges

Every registration platform exports CSV, and that export is already the badge run. Keep the ID column authoritative: build any URL column from it with a formula (="https://yourevent.com/c/"&A2) so the code content can never drift from the identity it encodes.

• ZIP of PNGs for a badge template. One image per attendee, named by ID, so a Word or InDesign mail merge picks up REG-0417.png next to the row for REG-0417 without anyone renaming files at midnight.
• Print sheet PDF when badges are being printed onto plain perforated stock and slipped into holders. Choose the column count so each cell matches the insert size.

The bulk-from-spreadsheet guide covers the CSV column mapping in detail. Because the codes are static, a walk-up registrant on the day is one more row and one more code generated on the spot — no plan, no quota, no account.

Before you print 300 badges

• Print one badge on the real stock, put it in the real holder, and scan it under the venue’s lighting — not your office’s.
• Scan it with the actual check-in app on the actual staff device, and confirm the ID it returns matches the name printed above it.
• Check for duplicate IDs in the CSV before generating. Two people with one ID is a check-in desk argument you cannot resolve on the day.
• Bring a printed copy of the attendee list. Static codes survive a network outage; a laptop with a dead battery does not.