QR codes for event badges and name tags
Badge production has a hard deadline and no room for a second attempt. The QR code part is straightforward — one code per attendee, generated from your registration export — but it has to slot into a mail merge cleanly, and it has to scan on a lanyard in a badly lit foyer. This guide covers both.
Decide what each code does
Check-in and lead capture
The most common setup: each code identifies the attendee to your own system.
https://event.example.com/checkin/A4471Scanning at the door pulls up the registration; scanning at a sponsor stand captures a lead. Because the identifier is in the URL, whatever scans it needs no special app — a phone camera works.
A personal agenda or profile
A link to the attendee's own schedule, session bookings or networking profile. Same shape, different destination.
Contact details (vCard)
You will see advice to encode a full vCard so people can scan each other's badges into their phone contacts. It works, but be aware of the trade-off: a vCard is a lot of data, which produces a dense pattern that needs a physically larger code to stay scannable, and the details are frozen at print time. A URL to a profile page is smaller, editable, and can be revoked after the event.
Think about what the code exposes. Anyone can
photograph a badge across a table. Encode an opaque identifier
(A4471) rather than an email address, and let your system
decide who is allowed to resolve it. A badge is a public object.
Export the registration list
Eventbrite, Hopin, Cvent, Google Forms and most registration platforms export a CSV. You need two columns: something to build the URL from, and something to name the files with.
url,attendee_id,full_name
https://event.example.com/checkin/A4471,A4471,Ada Lovelace
https://event.example.com/checkin/A4472,A4472,Alan Turing
https://event.example.com/checkin/A4473,A4473,Grace Hopper
If the export only has IDs, build the URL column with a formula:
="https://event.example.com/checkin/"&B2.
Name the files to match your badge template
This is the step that makes the difference between a merge that runs itself and an evening of manual image placement.
In the generator, choose your URL column, then set the
filename column to whatever your badge template will merge on — almost
always the attendee ID. Then clear the prefix field. You
want A4471.png, not qr_A4471.png, because the
merge field builds the image path from the ID directly.
Keep codes per image at 1. Badge software places one image per badge; a grid is no use here.
The result is a folder of PNGs whose names are exactly the IDs in your
badge data file. In Word, that is an INCLUDEPICTURE field
pointing at C:\badges\{MERGEFIELD attendee_id}.png. In
InDesign, it is a data merge with an image column holding
@/badges/A4471.png. Either way, no manual placement.
If you must name by person's name
Naming after full_name works, with two caveats. Spaces and
punctuation become underscores, so Ada Lovelace arrives as
Ada_Lovelace.png — your merge path has to account for that.
And names are not unique: two attendees called John Smith produce
John_Smith.png and John_Smith_2.png, and
nothing tells you which is which. Use the ID.
Sizing and placement
A badge QR code should be at least 2.5 cm (1 in) square. Smaller than that and check-in slows down measurably as people fumble to get the camera to focus at close range — which matters enormously when four hundred people arrive in twenty minutes.
- Put it low on the badge. Lanyards flip, and the bottom half is what remains visible and flat when a badge curls.
- Keep the quiet zone. Do not butt text or a border up against the pattern; scanners need the white margin, which the generated PNGs already include.
- Print the ID as text underneath. When a code will not scan at the door — a crease, a smudge, a dead phone — a staff member can type the number. This single line of text prevents most check-in queues.
- Avoid glossy lamination in a room with spotlights. Matte stock scans far more reliably under event lighting.
- Do not print on coloured card without testing. QR contrast requirements are real; dark backgrounds in particular defeat scanners.
Test the whole chain before the print run
Print three real badges — the first, the last, and one from the middle of the file — on the actual stock. Then:
- Scan each with the device check-in staff will actually use, not just your own phone.
- Confirm each resolves to the correct attendee. A misaligned merge that shifts images by one row is the nightmare scenario, and it is invisible unless you check names against codes.
- Test under the venue's lighting if you can get in beforehand.
Walk-ups and reprints
Some proportion of attendees will register on the day or need a replacement badge. Two ways to handle it:
- Pre-generate spares. Create a block of unassigned IDs in advance, print them as blank badges, and assign them at the desk.
- Generate on the spot. The manual entry tab handles one person in about fifteen seconds, and it works without a network connection once the page is loaded — which is worth knowing, because venue wifi is unreliable at exactly the moment you need it.
Bring the source CSV and the generated ZIP on a laptop at the event. Since the files are named by attendee ID, reprinting one badge means finding one file.
Keeping the attendee list private
A registration export is personal data — names, and often emails and employers. Uploading it to an unfamiliar web service is a genuine problem, and depending on where your attendees live, possibly a regulatory one.
Generation here happens entirely inside your browser. The CSV is read locally, the codes are drawn locally, and the ZIP is assembled locally — the file never travels anywhere. See the Privacy Policy for specifics, and the CSV formatting guide for getting the export itself right.