QR codes for events — RSVPs, check-ins, sponsors
How QR codes for events handle the whole arc — registration, day-of check-in, schedule changes that hit live, sponsor attribution, and post-event follow-up.
QR codes for events are the cheapest piece of infrastructure you can put on the floor and the one most teams treat as an afterthought. A conference for 600 people will spend $80,000 on venue, $40,000 on catering, $25,000 on AV — and print one QR on the back of the badge pointing at a homepage that has nothing to do with the schedule the attendee is holding. The week ends, the badge scanner export lands in someone's inbox as a 600-row CSV with no rep, no session, no sponsor attribution, and the post-event report says "engagement was strong."
This is the version of the post that goes through what those codes should actually do across the arc of an event — the RSVP QR before doors open, the per-attendee badge QR on the day, the schedule code that updates when a speaker swaps slots, the sponsor-attribution codes that earn renewals, and the follow-up code that closes the loop on Monday morning. None of it is hard. All of it gets skipped because the team is busy printing things instead of wiring them.
QR codes for events do five different jobs
Events are not one moment. They're a pre-event registration funnel, a day-of operations layer, a sponsor-attribution layer, and a post-event follow-up window. Each one wants a different code, with a different destination, a different audience, and a different failure mode. Treating them as interchangeable is why most event QR setups produce a single scan-count number and not the report the marketing director actually needed.
The architecture you want is one short-link platform with five slug families on it — /rsvp/, /in/, /sched/, /sp/, /fb/ — every code printed on something physical points through that platform, and every scan lands as a row with the family, the slug, the timestamp, and (where it matters) the attendee. The single-vendor layer is what makes the after-event report possible. Without it you're hand-reconciling a badge scanner export, a Google Forms RSVP, a Typeform feedback survey, and a stack of sponsor-supplied URLs that no two used the same way.
The RSVP / ticket QR — done before the doors
The pre-event QR is the easiest one and the most under-built. Most teams put a QR on the invitation that goes to the event homepage, the homepage has a registration button, the button opens a third-party ticketing form. Three steps when one would do.
A working RSVP QR points directly at the ticket page with the campaign segment already in the URL — events.yourdomain.com/r/spring-conf redirects to tickets.thirdparty.com/spring-conf-2026?utm_source=invite&utm_medium=qr&utm_content=mailed-card. The redirect carries the source through to the ticket purchase. Three weeks before the event you can split the report by source: how many tickets came from the mailed card, how many from the LinkedIn post, how many from the email blast. None of that is visible if the QR is hard-coded to a homepage.
For drop-in events or smaller meetups, the calendar event QR pattern skips the registration step entirely — scan, tap once, the event is in the phone. The calendar event QR builder emits the iCalendar payload directly and is the right tool when "we want them to remember the date" is the whole job. For paid or capped events, route through the ticket page; capacity is a feature when the venue has a fire marshal.
Per-attendee check-in QR — fast, lightweight, no app
The badge QR is the one that does the most work on the day. The job is to scan attendees through the door in under five seconds, without an app, without a custom kiosk, without a vendor's $4,000-per-event licensing fee.
The cheap version of this works like a short link. Each attendee's badge carries a unique QR encoding a URL like events.yourdomain.com/in/8f1jq2. The slug is the ticket ID, generated at registration. At the door, the check-in volunteer scans the badge with a phone's regular camera. The URL opens a single page on a laptop the volunteer is logged into — it shows the attendee's name, photo if you have one, ticket tier, dietary preferences, plus a single big button: "Mark checked in". One tap, the row is logged with the timestamp, the next attendee steps up.
What you do not need: a custom mobile app, a hardware scanner, a $200-per-day kiosk rental, a vendor's white-label check-in product. What you do need: a phone, a laptop, the right URL on the badge, and a check-in page that loads in under two seconds on the venue WiFi.
Three things to get right:
The slug is short and unguessable. Six characters from a base-36 alphabet gives you 2.2 billion possibilities — plenty for any event, hard enough to guess that no one walks in with a forged badge that happens to match a real ticket. Don't use the ticket-purchase email or the seat number; both leak personal data into the URL.
The badge prints the slug as a QR plus a short human-readable version. When a phone camera fails (it will, twice an hour, on cheap badges in low light), the volunteer can type 8f1jq2 into the search box on the same page. The fallback is the difference between a five-second check-in and a two-minute argument.
The check-in page works offline-ish. Venue WiFi will fail. The check-in page should cache the full attendee manifest at load time and queue check-ins locally if the network drops, then flush them when the network returns. Most off-the-shelf event tools handle this; if you're rolling your own, build the queue before the doors open, not when the queue is forming.
The same per-attendee slug pattern shows up at tradeshow booths where the goal is per-rep attribution, and at weddings where the goal is per-household RSVP pre-fill. The pattern transfers because the underlying mechanic — slug carries identity, server holds the row — is the same in every case.
The schedule QR that updates without reprinting
Conference schedules change. The 10am keynote moves to 11am because the speaker's flight is delayed. The breakout in Room 3 swaps with the one in Room 7 because Room 3's projector dies an hour before the session. A printed paper programme is wrong by lunchtime on day one. Most events solve this by printing a sign that says "schedule changes — see app" and then watch attendees walk into the wrong room because nobody downloaded the app.
A dynamic schedule QR fixes this with a slug you control. Every printed surface — programme, lanyard back, lobby signage, the back of each room's door — carries the same QR pointing at events.yourdomain.com/sched. The destination is a page on your site (or the event's content management tool) that you edit live during the show. Speaker swaps, time changes, room changes — one edit, every printed QR resolves to the new version. The decision to put a redirect server between your printed pixels and the schedule page is the difference between "we printed updates on Friday" and "we made the change and it was visible across the floor in 30 seconds."
This is the use case where static vs dynamic QR codes stops being a theoretical discussion and becomes a live operational decision. Static is fine for the calendar QR on the save-the-date — the date doesn't move. Dynamic is the only sensible default for anything you'll need to edit between print and the event. The QR code generator handles either, but the schedule QR is firmly in the dynamic-only category. The supporting events docs walk through the slug structure for a multi-day, multi-track show.
A printed schedule is wrong the moment the first speaker emails to say they're running late. A QR pointing at a page you control is wrong only as long as it takes you to type the new time.
The schedule page itself wants to be unfussy: large type, a "current session" highlight pinned at the top, room-by-room columns underneath, and a single "last updated" timestamp in the header so attendees know whether what they're reading is fresh. The page does not want to be an app download. It does not want to be a marketing landing. It is a piece of operational signage rendered in HTML.
Sponsor attribution — the only number sponsors actually care about
Sponsors pay for events because they want leads. The sponsorship deck promises "exposure to 600 senior decision-makers"; the contract specifies "branding on signage, programme inclusion, mailing-list inclusion"; the actual sponsor evaluating renewal next year wants to know one thing — how many of those 600 attendees ended up in our pipeline?
If the sponsorship layer doesn't measurably answer that question, renewal is a coin flip. If it does, renewal is a quiet sentence in a March email saying "we want the same package next year, plus the lounge upgrade."
The QR layer that answers the question is per-sponsor slugs on every printed asset that mentions the sponsor:
- A QR on the lanyard back-card with the sponsor's logo and
/sp/acme-lanyard. - A QR on the booth signage with
/sp/acme-booth. - A QR on the welcome bag insert with
/sp/acme-insert. - A QR on the conference programme's sponsor page with
/sp/acme-programme.
Each slug redirects to the sponsor's chosen destination — usually a co-branded landing page on the sponsor's site with the event referenced in the header. The destination is the sponsor's; the slug and the analytics are yours. Three weeks after the event, the sponsor gets a small report: 142 scans across four placements, broken down by placement, with timestamps. The booth QR did most of the work; the welcome-bag insert did almost nothing. The lounge upgrade looks like a good idea for next year.
That report is what gets the renewal signed. The cost of producing it is one extra hour of slug setup before the event opens. The QR code analytics primer covers what a scan tells you and what it doesn't — for sponsor attribution, the per-slug placement is what matters, not the device family or the country of origin.
Feedback and follow-up — the 48-hour window
Attendee feedback is the cheapest data you'll ever collect and the hardest to actually get. The standard pattern — email survey three days after the event — sees response rates in the 6-12% range, and the responses skew heavily to the people who hated something. Two changes move that number sharply: QR codes per room on the way out, and a 48-hour follow-up window with the session pre-filled.
The per-room feedback QR is a card on the back of each session room's door. The slug carries the session ID — /fb/keynote-day-1, /fb/breakout-3a-day-2 — and the page opens a five-question form with the session title already in the header. Attendees who liked the talk fill it in on the way to the next session. Response rates double or triple, and the responses cover the sessions you actually care about — not just whichever session got someone angry enough to fill in a generic survey.
The 48-hour follow-up code is a single QR on the printed programme labelled "Follow up next week" pointing at /fb/general. Attendees who want to keep talking — about the conference, a vendor, a partner — scan it on the train home. The destination is whatever you want it to be: a Calendly for sales conversations, a Notion form for partnership enquiries, a "join our community" page for the longer-term funnel.
Need every event QR on one domain with one analytics view? Slug families on Linked.Codes carry the segment without a developer in the room — RSVP, check-in, schedule, sponsor, feedback, all under your event domain.
Try it free →An event QR planner — score your coverage
The eight QR placements below are the ones most events under-build. Tap through what you have planned. The verdict at the bottom is the tier you're shipping at — bare minimum, solid, or best-in-class.
Event QR coverage planner
Tick what you're shipping. Score at the bottom maps to a tier so you know whether the setup will produce a usable after-event report.
The score is opinionated on purpose. Three of the eight placements (check-in, schedule, sponsor attribution) carry most of the after-event reporting weight. The other five are operational quality-of-life. An event that ships all eight produces a report next quarter that pays for itself in renewed sponsorships and a tighter print budget the year after.
Print and operational details that quietly break event QRs
Most event QR failures aren't software failures — they're print and operations failures the design tool can't see. Five worth pre-flighting before the truck leaves for the venue:
Badge QR size. A QR on a credit-card-sized badge at 2cm scans fine at hand-held distance. At 1cm — common when the badge designer prioritises the logo — the same code at level Q starts failing in dim lighting. Specify 2cm minimum to the badge printer and check a sample under the venue's actual lighting before the full run prints.
Quiet zone. Every QR needs a four-module margin of plain background around it. Event badges with decorative borders right against the QR are the most common silent failure. Measure the margin after the designer hands back the artwork.
Print resolution. 300 DPI minimum on the actual print. Some badge printers downsample files to 150 DPI without flagging it; small modules become muddy. Ask the printer to confirm.
Custom subdomain. A QR pointing at bit.ly/3xK7p1 on a $200 conference badge reads as suspect. A QR pointing at events.yourdomain.com/in/8f1jq2 reads as legitimate. The custom subdomain costs roughly nothing and is the cheapest scan-rate improvement available. The branded short links and trust post quantifies the gap; for event use, "looks like our brand" is enough.
WiFi reality check. Venue WiFi will fail. The check-in page should cache the attendee manifest at load. The schedule page should be cacheable. The feedback form should queue submissions locally if the network drops. Test all three on the cheap-phone-bad-WiFi worst case before the doors open.
What we built around this
Linked.Codes runs the redirect layer that any of these QR codes can sit on top of. Bring an events.yourdomain.com subdomain (or use a free subdomain for the first event), generate slug families in the dashboard, point the QR designer at the slugs, and your printed codes resolve to whatever you want them to — today, tomorrow morning when the keynote moves, or three weeks after the event closes. The whole event suite lives under one domain, with the dashboard showing scan counts per slug family so the sponsor report and the session-feedback summary write themselves. The QR code designer handles the visual side; the short-link docs cover the slug structure; the events docs walk through the multi-day, multi-track layout.
For a one-off event a single subdomain and a dozen slugs is enough. For a recurring conference, the agency-branded approach of one domain per client event with shared analytics underneath becomes the right shape.
Related reading
- QR codes for tradeshow booths — capturing leads on the floor — the per-day and per-rep slug pattern applied to booth operations
- Calendar event QR codes — get an event into a phone fast — the iCalendar payload that powers the save-the-date
- Wedding QR codes — RSVPs, photos, and registries — the print-led adjacent case
- QR code analytics — what scans tell you — what each scan does and does not say
- Static vs dynamic QR codes — the decision behind every schedule QR
How do per-attendee QRs work without an attendee-facing app?
The badge carries the QR; the volunteer at the door carries the phone. The phone's regular camera opens the URL on the volunteer's check-in laptop, the laptop looks up the row, the volunteer taps "Mark checked in." No attendee install, no kiosk hardware, no vendor app. The slug is the ticket ID generated at registration; the camera does the work that an app would otherwise do.
Can the schedule QR survive a session-time change?
Yes — that's the whole reason to make it dynamic. The QR encodes a short URL like events.yourdomain.com/sched. You edit the destination in the dashboard when a speaker moves; every printed QR resolves to the new schedule within seconds. The pixels on the lanyards do not change; the row in your platform does.
How do I prove a sponsor sent traffic?
Per-sponsor slug families across every placement that mentions the sponsor — lanyard insert, booth signage, welcome bag, programme page. Each slug has a different placement label. The post-event report shows scans by placement; the sponsor sees which placement worked and which didn't. That report is what renews the sponsorship the next year.
What happens if the venue WiFi goes down?
The check-in page should cache the attendee manifest at load and queue check-ins locally, flushing when the network returns. The schedule page should be a small static-ish HTML page that caches in the browser. The feedback form should queue submissions in localStorage. The QR codes themselves don't care about WiFi — they're a URL, the camera reads them offline; the destination is what needs the network handling.
Can I edit the destination after badges are printed?
Yes, for any dynamic QR — that's the architecture. The pixels encode a short slug on a domain you control. Change the destination of the slug in the dashboard, the printed badge keeps working, every future scan lands at the new destination. Static QRs (those that encode the destination URL directly) are the exception; for events, default to dynamic for everything except a fixed save-the-date.
Are QR codes secure for ticketing?
For ordinary admission control, yes — a six-character base-36 slug gives 2.2 billion possibilities, hard enough to guess that forged badges don't statistically work. For high-value or restricted events, add a server-side check that flags a slug used twice (anti-passback), require the badge photo to match the row on lookup, and rotate slugs if the event is multi-day. The QR is the ID; the server is the security.
Do I need a custom domain or is a generic shortener enough?
A custom subdomain — events.yourdomain.com — is the cheapest scan-rate improvement available and pays for itself in trust. Senior attendees and sponsors look at the URL preview the phone shows before opening; a bit.ly URL on a printed badge reads as suspicious, and a fraction simply don't tap. The custom subdomain is a one-time DNS record and a fixed cost; for an event over a few hundred attendees it's not a real spending decision.
Sourcesshow citations
- ISO/IEC 18004:2024 — QR Code bar code symbology specification (capacity tables, error correction levels). https://www.iso.org/standard/83389.html
- IETF RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar) — https://www.rfc-editor.org/rfc/rfc5545
- Wikipedia — QR code (Reed-Solomon error correction, finder patterns). https://en.wikipedia.org/wiki/QR_code
- Apple Developer — Wallet passes and event ticket format. https://developer.apple.com/documentation/walletpasses
- Google Developer documentation — Google Wallet event ticket objects. https://developers.google.com/wallet/tickets/events
- Center for Exhibition Industry Research (CEIR) — primary trade-show and event industry reports. https://www.ceir.org/
- Eventbrite — published research on event registration funnels and on-site check-in. https://www.eventbrite.com/blog/academy/
Try it on your own domain
Branded short links and dynamic QR codes, on your subdomain or your own domain. One-time purchase, no per-click fees.
