QR codes for conference badges and handouts
QR codes for conference badges and handouts
- Open source
- No sign-up
- No watermark
- Free API + MCP
- In the MCP registry
A badge and a handout are not the same code
| Object | Who scans it | What it should open | Static or dynamic |
|---|---|---|---|
| Delegate badge | Anyone the wearer talks to | A digital business card or short bio for that one person | Dynamic if you'll update it after printing, static if the details are final |
| Speaker badge or lanyard insert | Attendees after a talk | The speaker's bio, and their session's materials once posted | Dynamic; this is exactly the case where the destination changes on the day |
| Session handout / programme entry | Attendees in or after that session | That session's slides or resource page | Dynamic; created before the day, repointed once the real materials exist |
The timing problem: the code exists before the destination does
A printed programme has to go to press before the final slide decks exist, sometimes weeks before. The fix is to generate the dynamic code early and point it at a plain holding page, something as simple as "materials will be posted here after the talk", then repoint it to the real resource the moment the speaker hands their deck over, ideally before they've even left the stage. The printed programme never has to change; only the destination behind each code does.
A repoint can happen mid-conference, not just after it
Repointing each session's code the moment its materials land turns a QR code from "nothing here yet" into genuinely useful in real time, while the printed handout itself never has to be reprinted or corrected.
What a badge scan should open
A delegate badge scan should feel like exchanging a business card, not being redirected to the conference's own marketing site. A personal contact or bio page, resolvable to a vCard, does that; a generic "welcome to the conference" page doesn't, and it's the same mistake as pointing every museum exhibit label at the collections homepage: a code that always leads somewhere generic teaches people to stop scanning it.
Running the codes for a multi-session conference:
- 1
List every speaker and every session that needs its own code
Badges and handouts are separate lists; a speaker often needs both.
- 2
Generate the full set as dynamic codes before the programme goes to print
Point each one at a placeholder holding page rather than waiting for the real content to exist.
- 3
Print badges and handouts with the codes already fixed
Nothing about the printed object needs to change all day, however the schedule shifts.
- 4
Repoint each session's code as soon as the talk finishes
To the real slide deck or resource page, ideally within minutes of the speaker handing it over.
- 5
Compare per-session scan counts afterwards
To see which talks people actually wanted the materials from, useful evidence for next year's programme.
A conference with twenty sessions plus a handful of speaker badges clears the free allowance of three during the first afternoon of planning, well before the event itself. That's a Pro (£9/month) decision to make while building the programme, not a surprise discovered on the day.
Most conferences fix their printed programme days or weeks ahead, so build the full code set as soon as the running order is locked rather than the night before. Treat a last-minute room or speaker change as a repoint, not a reprint. A minority of events print badges on-site at check-in from a kiosk, which offers more flexibility on the day but isn't available everywhere and is worth confirming with the venue before relying on it.