QR Codes for Events: Check-In and More in 2026

QR codes for events in 2026 let you run registration, ticketing, check-in, and feedback from a single scan, so attendees use their phones instead of paper and organisers skip the queues. Someone scans a poster code to sign up, shows a ticket code at the door, then taps into the schedule, a feedback form, or a sponsor page, all without downloading anything. This guide covers what QR codes can do at an event, how check-in actually works, whether to use static or dynamic codes, and the steps to set it all up.

What Can QR Codes Do at an Event?

A lot more than open a website. Across the run of an event, a QR code can do most of the small, repetitive jobs that used to need paper or staff time. The usual ones:

• Registration. A code on your poster, email, or social post opens a sign-up form.
• Digital tickets. Each registrant gets a unique ticket code to show on arrival, stored on their phone or in a wallet app.
• Check-in and access. A scan confirms the booking, marks attendance, and can gate VIP areas or specific sessions.
• Schedules and info. One code opens the agenda, floor plan, or speaker bios, no printed programme needed.
• Feedback. A code on the exit or the final slide links to a short survey.
• Networking and sponsors. Codes on badges swap contact details, and sponsor codes send attendees straight to their page.

The trick is one code per job, each placed where people actually need it. For the wider list of ideas beyond events, our QR code uses guide runs through them.

Why Are QR Codes So Popular for Events in 2026?

Because almost everyone already knows how to use them, and the numbers keep climbing. The QR code is an internationally standardised format, defined under ISO/IEC 18004, now in its fourth edition published in 2024, so any modern phone camera reads any properly made code the same way. That same standard is why a scuffed badge still works: it specifies four levels of built-in error correction, from L at roughly 7 percent recovery up to H at about 30 percent, meaning a code can lose a chunk of itself and still resolve. For events, where lanyards get creased and printed tickets live in pockets all day, pick a higher level than you think you need.

Adoption backs it up. According to Statista, mobile QR code use has been climbing year on year and is forecast to keep growing through 2028, with Asia-Pacific the leading region for adoption. That regional detail is the one that matters for organisers here. Across Singapore, Malaysia, and much of Southeast Asia, scanning a code to pay a hawker or board a train is routine, so an event QR needs no explanatory poster and no instructions from your door staff. People see a code and they already know what to do with it.

If you want proof the model holds up at volume, Singapore ran it nationally. The Government Technology Agency built SafeEntry as a national QR check-in system covering potentially 220,000 businesses and 5.7 million residents. More than 58,000 locations and 30,000 businesses applied for codes in the first opening weekend alone, and at peak on 11 May 2020 GovTech issued over 16,600 QR codes to 5,600 businesses in a single day. Once running, it averaged around 9 million check-ins a day across 200,000 locations. Your event is not that, obviously. But if a QR check-in can absorb nine million scans daily, it will comfortably handle your 400-person conference.

Advertisement

How Does QR Code Check-In Work?

The flow is simple. When someone registers, they receive a unique QR code as their digital ticket, usually by email. At the entrance, a staff member or a self-service kiosk scans it with a phone or tablet. The system checks whether the person is registered, whether the ticket is valid, and whether any access rules apply, then marks them as arrived. The whole thing takes a couple of seconds.

The speed difference is the whole argument, and you don't need a study to see where it comes from. A manual check-in is a search problem: your volunteer scans a printed list for a surname, finds it, ticks it, and hands over a badge. A QR check-in is a lookup: the scan resolves the exact record instantly. One takes as long as it takes to find a name on a page. The other takes as long as the camera needs to focus.

Be sceptical of the precise numbers floating around this topic, though. Plenty of QR vendors publish confident before-and-after timings, and almost none of them show their method or sample. Treat those as marketing. What holds up is the shape of it: scanning removes the search step, and the bigger your guest list the more that compounds. At 50 people nobody notices. At 500, it's the difference between a moving queue and a jam at the door.

The other real gain is your headcount. Every scan updates attendance live, so you know how many people are actually in the room rather than how many said they'd come. That matters for catering, for fire-safety limits, and for telling a sponsor what they got.

There's a design decision hiding in here that most organisers make by accident: how many lanes you run, and who goes where. Once check-in is a scan rather than a search, lanes stop being interchangeable. You can route people by what they need instead of by whoever's queue looks shortest. A typical split is one high-throughput lane for standard tickets, one for people collecting something physical like a badge or a lanyard, and one staffed lane for anyone who needs help.

That third lane is the one worth arguing for. It costs you one volunteer and it quietly solves the problems further down this page: the flat battery, the guest who never got the email, the attendee who can't scan at all. Signpost it as assistance rather than as an accessibility lane, because plenty of people who need it won't self-identify with that label. And put it where the queue can see it, not tucked around a corner, or nobody will use it until they're already stuck at the front of the wrong line.

One trick most organisers skip: scan people out as well as in. Singapore's Ministry of Digital Development and Information rolled out SafeEntry check-out boxes from late June 2021 for exactly this reason, noting that without check-out data its contact tracers had to fall back on interviews to work out how long someone had stayed somewhere, which cost time and manpower. Same logic at a smaller scale: a code on the exit door tells you actual dwell time per session, which session people walked out of early, and when the room really emptied. Ask attendees to tell you that in a survey and most won't remember. Scan them out and you just have it.

How Many Check-In Lanes Do You Need?

Work backwards from your busiest thirty minutes, not from your total headcount. That's the whole method, and almost nobody does it, which is why the queue outside always looks worse than the organiser expected.

There's a proper number to anchor against, and it comes from a regulator rather than a vendor. The Sports Grounds Safety Authority, which sets UK safety standards for grounds and stadia, publishes the Green Guide figure for ingress: an upper limit of 660 persons per entry point per hour. The SGSA also says that if your actual measured rate turns out lower, you use the measured figure instead, and that entry rates should be measured at least once a year and written down.

Now read that number honestly, because it isn't a target for you. 660 an hour is about 5.5 seconds a person, and it describes a turnstile where the only thing anyone does is walk through. A check-in desk adds a scan, a lookup, quite often a badge print, and roughly one person in fifteen who booked under a different name. Treat 660 as the ceiling that physics allows and plan for a fraction of it. A staffed desk that also prints badges realistically lands somewhere well below half that.

So the sizing goes like this:

• Estimate the peak, not the total. For anything with a fixed start time, a large share of your guests turn up in the last half hour before it. Plan around that window, because it's the only one that produces a queue.
• Divide, don't guess. Lanes needed equals peak arrivals divided by your per-lane hourly rate, times the length of the window. Say 600 people arrive in the busy 30 minutes and each lane genuinely handles 200 an hour. That's 600 divided by 100 per lane for the half hour, so six lanes. Not three.
• Add a lane just for problems. One dedicated exceptions desk for the name that isn't on the list, the expired ticket, the person who forwarded their email to a colleague. This is the highest-value lane you'll run, because without it a single awkward case stalls everyone behind it.
• Don't average kiosks and humans. Self-service scanning and staffed desks run at different speeds. Count them separately or your maths will flatter you.
• Assume badge printing is the bottleneck. The scan takes a second or two. The printer, the peel, and the lanyard take much longer. If you can pre-print or skip badges, you've done more for your queue than any software choice.

And then do the thing the SGSA actually asks for. Time your own lanes at the next event, count what you really processed in the peak half hour, and record it. One measurement from your own door beats every throughput claim you'll read in a sales deck, including the ones further up this page that we told you to be sceptical about.

What Are Your Data Obligations for Attendee Scans?

Everything above quietly turns you into someone holding personal data. Names, emails, arrival times, which sessions people sat through. If you run events in Singapore, two things are worth knowing before your next one.

The first has a deadline attached. Singapore's Personal Data Protection Commission announced in February 2026 that organisations must cease using NRIC numbers for authentication by 31 December 2026, and it is stepping up enforcement against misuse of NRIC numbers. Plenty of check-in desks still verify people by asking for the last few characters of an NRIC. If yours does, that clock is running. A unique QR ticket per attendee is the straightforward replacement, which is a nice accident of timing for anyone reading a QR guide.

The second is the one that actually catches organisers out, and it's about sponsors. Scan data feels like yours because you collected it. But under the PDPA's data protection obligations, you can only use personal data for purposes people were told about and agreed to. Handing a sponsor your attendee list because they paid for a booth is a different purpose from "register for this event," and if nobody was asked, you have a problem. The fix is small: a separate, ticked-by-choice checkbox on your registration form saying exactly who the data goes to and why. Not buried in terms, not pre-ticked, and not bundled into the same box as the registration itself. Do that once when you build the form and the rest of your scanning stays clean.

When Do You Have to Delete the Attendee Data?

Sooner than almost anyone does. The section above covers what you're allowed to collect and use it for. This is the half that gets forgotten, and it's a separate legal duty rather than good housekeeping.

Singapore's PDPA carries a Retention Limitation Obligation under section 25. In plain terms, you must stop keeping documents containing personal data, or strip out whatever links that data to named individuals, as soon as it's reasonable to assume two things are both true: the purpose you collected it for is no longer served by keeping it, and you don't need it for a legal or business reason either. Both halves have to be satisfied, and "we might do another event next year" is not one of them.

That's a sharper rule than most organisers realise, because a scan list feels like an asset. It sits in a spreadsheet, it cost you effort, and nobody ever sends an email telling you to delete it. But the purpose your attendees agreed to was running that event. Once it's run, the clock has started.

The practical version, which takes about ten minutes to set up once:

• Decide the retention period before the event, not after. Write it on the registration form. "We'll delete your details within 90 days of the event" is clear, easy to honour, and doubles as the notice the PDPA wants you to give.
• Separate the operational data from the record you actually keep. Names, emails, and arrival timestamps are the sensitive part. Headcounts, session attendance totals, and dwell times are not personal data once the names come off.
• Anonymise rather than delete when you want the numbers. The obligation explicitly allows removing the means of associating data with particular individuals as an alternative to deletion. So keep "142 people attended session 3 with median dwell time 38 minutes" forever if it's useful. Just don't keep the list of who they were.
• Delete the exports too. The copy in your ticketing platform is rarely the only one. There's usually a CSV in someone's downloads folder, an attachment in a WhatsApp group, and a sheet a volunteer made. The obligation covers all of them.
• Watch the sponsor copy. If you shared data with a sponsor under the consent you gathered, your own deletion doesn't reach their systems. Agree their retention period in writing when you agree the sponsorship.

None of this is onerous, and the anonymise-then-keep route means you lose nothing you actually use. The one thing to avoid is the default: an attendee list from 2023 still sitting in a shared drive because deleting it was never anyone's job.

Do the Rules Change If You Have EU Attendees?

Yes, and here's the part that surprises people. The trigger isn't where your event is held. It's who walks through the door.

The EU's official guidance on data protection under the GDPR says the rules apply to a company established outside the EU when it processes personal data in relation to offering goods or services to individuals in the EU, or monitors the behaviour of individuals within the EU. Run a conference in Bangkok, sell tickets to someone in Dublin, scan their badge at the door, and you're processing their personal data. There's a further obligation attached too: businesses outside the EU that fall in scope have to appoint an EU representative.

Now the reassuring part. If you've built the registration form the way described above, you've already done most of the work. The GDPR consent standard is that consent must be "freely given, specific, informed and unambiguous by way of a request presented in clear and plain language." Read that against the advice to use a separate, unticked, plainly worded checkbox naming who gets the data, and it's the same instruction. Good practice in one regime tends to be good practice in the others, which is why building the form properly once beats maintaining two versions.

Two obligations do go further than a checkbox, though. You can only use the data for the purposes consent was given for, and people have to be able to withdraw that consent, which means a working unsubscribe or a real contact route rather than a no-reply address. And you have to tell people up front how long you'll keep their data. There's no universal retention limit to memorise, since the period follows the purpose, but the number has to exist and be stated rather than left vague.

So the practical version for anyone running events across borders. Assume some attendees will be covered by rules from somewhere you're not sitting. Write the strictest version of your form, state a retention period, give a real withdrawal route, and don't hand scan data to sponsors without a specific opt-in. That covers you in most jurisdictions at once, and it's less work than trying to sort attendees by passport at the registration desk.

How Do Exhibitors Scan Attendees for Leads?

Check-in is one scanning flow. If you're running a conference or trade show there's a second one going the other way, and it's the one sponsors care about most.

The mechanics are simple enough. Each attendee badge carries a unique QR code, and exhibitors scan it at their booth to capture that person as a lead instead of collecting business cards or typing names into a phone. Same code as check-in in most setups, read by a different scanner for a different purpose.

And that phrase, a different purpose, is exactly where this goes wrong. Everything in the data section above applies here, only harder. Your attendee agreed to register for your event. Being handed to fourteen exhibitors is not the same thing, and the fact that the badge scans cleanly doesn't mean anyone consented to what happens after the scan.

So decide which of two models you're running, and be honest with attendees about it:

• Opt-in at the booth. The attendee chooses to be scanned, in person, knowing what it means. This is the cleaner model and the one that survives questions. Make sure your signage says the scan shares their details with that exhibitor, because a lot of attendees genuinely think they're collecting something rather than giving something.
• Blanket sharing at registration. Everyone's data goes to all sponsors. If you do this, it needs its own unticked checkbox at registration naming who receives the data, exactly as covered above. Bundling it into the registration box itself isn't consent.

Two things worth building in. Let attendees see what they've shared, because someone will ask at the end of day two and "we can't tell you" is a bad answer. And give exhibitors a note field at the point of scanning, since a lead captured with no context is close to worthless three weeks later, which is the actual reason business cards survived as long as they did.

One practical warning about the badge itself. If the same code does check-in and lead capture, it's on a lanyard in public view all day, which is a fair bit of exposure for something that identifies a person. Keep what the code encodes to a meaningless reference that only your system can resolve, never the attendee's name, email, or anything resembling an identifier. A QR code is not a secret, and anyone standing behind someone in a coffee queue can photograph one. If the code resolves to nothing without your system, that photo is worthless.

Does Your Check-In Count Help With Crowd Safety Rules?

It can, and in the UK it's about to stop being optional. If you run events anywhere near the 200-person mark, this is the section to read twice.

The Terrorism (Protection of Premises) Act 2025, which almost everyone calls Martyn's Law, received Royal Assent in April 2025 and sets counter-terrorism duties for venues and events by headcount. According to ProtectUK, the UK's official counter-terrorism policing resource, the thresholds are these:

• Standard tier: 200 to 799 people expected at the same time. You notify the Security Industry Authority and put in place public protection procedures that could reasonably be expected to reduce the risk of physical harm in an attack.
• Enhanced tier: 800 or more. Same notification and procedures, plus protective measures to reduce the vulnerability of the premises or event, plus documentation handed to the regulator.

The Security Industry Authority is the regulator. And here's the detail that surprises people at the standard tier: the guidance is explicit that there's no requirement to put in place physical security measures. What's being asked for is procedural readiness. Do your staff know the evacuation route, the lockdown call, and who says the words?

The government has said it intends an implementation period of at least 24 months from Royal Assent before the duties bite, which puts enforcement somewhere around April 2027 at the earliest. So you have time. You don't have as much as it sounds like, because the thing most organisers need to change is a habit rather than a piece of kit.

Where your QR data actually fits. A check-in scanner gives you something a clicker at the door never did: a timestamped list of who is inside. During an evacuation that's the difference between a headcount and a guess. But be careful about what the number really means, because this is where people fool themselves.

A check-in count is not an occupancy count. It's a cumulative total of everyone who ever walked in, and it only becomes a live figure if you also scan people out. That's the same argument the check-in section above makes for exit codes, and it's the reason it matters more than dwell-time analytics. Without a scan-out, your system will happily tell you 640 people are in the room two hours after 200 of them went home.

Three practical notes, none of which needs new software:

• Count the people your list forgets. Staff, crew, security, caterers, performers and their guests all count toward the threshold and almost none of them go through the attendee scanner. A separate crew check-in fixes it.
• Assume the tablet dies. A safety procedure that depends on a working scanner and live WiFi isn't a procedure. Print the current list at intervals, or keep an offline copy on the device, so somebody can walk out with a piece of paper.
• Don't let the count replace the plan. Attendance data is an input to a safety procedure, not the procedure itself. The Act asks about what your people do, not what your dashboard shows.

One note on scope. This is UK law, so it doesn't bind your conference in Singapore, Kuala Lumpur or Jakarta. But the thresholds are a genuinely useful planning heuristic wherever you are, because 200 and 800 are roughly the points at which a room stops being manageable by line of sight and starts needing a written procedure. And if you ever run a UK date, or a sponsor does, you'll be asked about it.

Which Should You Use, Static or Dynamic?

For most event uses, dynamic. The difference matters more than it sounds. A static QR code has its destination baked permanently into the pattern, so once it's printed, you can't change where it goes or see how many people scanned it. A dynamic code points to a short URL you control, which means you can update the destination after printing and get scan data by station, session, or sponsor.

That flexibility is gold at an event. If a session room changes or a link breaks, you fix the dynamic code's destination in seconds instead of reprinting banners. And the scan analytics tell you which sponsor board or which feedback prompt actually got used. Save static codes for details that will never change, like a WiFi login. Our dynamic vs static QR code guide explains the trade-offs in full.

Should You Use NFC Wristbands Instead?

For most events, no. For a large multi-day festival with cashless bars, quite possibly yes. The line between those two isn't really about size, it's about who ends up buying the readers, and once you see why, the decision makes itself.

Start with what the two technologies actually are, because everything else follows from it.

A QR code is optical. It's a printed pattern, your camera looks at it, and the standard behind it is ISO/IEC 18004, which is why any phone reads any properly made code the same way. That point is made earlier in this guide and it's the whole reason QR works at events.

NFC is radio. The NFC Forum describes it as a contactless technology on a base frequency of 13.56 MHz "with a typical range of up to 2cm", carrying data at anywhere from 46 kbit/s to 1.7 Mbps. And here's the number that tells you most about how it behaves in practice: the Forum's Certified Compliant range is 5mm. Five millimetres. That isn't a shortcoming to engineer around. It's the design. NFC is a tap, deliberately, so that you can't accidentally pay for something by walking past it.

Now follow what a 2cm range does to your floor plan. Every single place an attendee needs to be recognised has to have a reader within a couple of centimetres of their wrist. Every gate. Every bar. Every zone boundary. Every merch till. You're not buying wristbands, you're building a network of readers and then buying wristbands to go with it.

A QR checkpoint, by contrast, needs a phone. Which your staff already have, and which your attendees already have. The reader cost isn't lower. It's zero, because it got paid for by somebody else years ago.

That's the real trade, and it's why the answer depends on how many checkpoints you have rather than how many people.

But there's one place NFC is genuinely, structurally better, and it's worth being honest about because it's the failure mode this guide keeps circling.

The NFC Forum notes that NFC is unusual in that one side can transmit power across the connection, which allows battery-less operating modes. Read that again with a queue in mind. An NFC wristband has no battery, no screen, and no operating system. It cannot go flat, it cannot lock itself, it cannot dim into unreadability, and it does not care whether the venue has signal. A phone showing a QR ticket can do all four, and on the afternoon of day two of a festival, a meaningful number of them will.

The wallet section and the connectivity section of this guide are both about working around that. NFC just doesn't have the problem.

One more difference that cuts the other way. NFC Forum devices have to interoperate with a spread of existing protocols: ISO/IEC 14443 Type A and Type B readers and cards, ISO/IEC 15693 cards, ISO/IEC 18092 devices, JIS-X 6319-4, and NFC Forum tags. The contactless proximity protocol itself sits in ISO/IEC 14443-4. That's a lot of standards to be compatible with, and the Forum wrote a superset specification precisely because the landscape underneath is fragmented. QR has one standard and one behaviour. Fragmentation is somebody else's problem when you're buying a hardware stack, and entirely your problem when a reader doesn't like a band.

So here's the split, stated plainly.

• QR wins when the checkpoint count is low and the attendee count doesn't matter much. A 3,000-person conference with two doors is a QR event. So is a 200-person workshop. Adding people to a QR queue costs you staff, not equipment.
• NFC wins when the checkpoint count is high. Cashless bars, multiple stages with separate access tiers, re-entry gates around a perimeter. Once you're placing readers anyway, the marginal cost of one more tap point is small.
• NFC wins on reliability at the moment of contact. No battery, no screen, no signal dependency, and a tap is faster than framing a camera. If your queue has to clear in a fixed window, that gap compounds.
• QR wins on everything before the event. You can email a ticket in seconds, reissue it instantly when somebody loses it, and change nothing about your logistics. A wristband has to be manufactured, shipped, and physically handed to a person.
• QR wins on walking away. If the event doesn't happen, or the format changes, you've spent nothing on hardware.

Which brings up the answer most large events actually land on, and it isn't either one.

They run both. QR handles everything up to the door: registration, the confirmation email, the ticket the attendee brings with them. The wristband takes over once they're inside, where taps are frequent and the phone is a liability. First entry is the handover point, where somebody scans a QR once and fits a band.

If you're reading this guide to plan a check-in process, that's probably your model too, just at a smaller scale. QR to the door is the part you can build today, for free, with no procurement conversation. The band is a decision you can make later, once you know how many times a day you're actually asking people to prove who they are.

How Do You Set Up QR Codes for Your Event?

You can get a basic setup running in an afternoon. Here's the order that works:

1. Map each job to a code. List what you need, registration, tickets, schedule, feedback, and plan one code for each.
2. Point each code at a mobile-friendly page. Everyone scanning will be on a phone, so the destination has to load fast and read well on a small screen.
3. Generate the codes. Make them with a free QR code generator, and use dynamic codes for anything you might edit or track.
4. Size and print with contrast. Print large, keep strong dark-on-light contrast, and add a short label so people know what each code does. Our QR code size guide has the numbers.
5. Test on more than one phone. Check every code on both an iPhone and an Android before anything goes to print.
6. Brief your door staff. Make sure whoever is scanning knows the tool and has a manual backup ready.

Two settings decide whether a badge still scans on day two, and most generators bury both.

Error correction. QR codes carry redundant data so a damaged code still reads. DENSO WAVE, which invented the format, sets out four levels: L, M, Q and H, in increasing order. Level M restores around 15 percent and is the one most generators pick by default. Level Q restores around 25 percent, and H is higher again.

Default is fine for a poster on a wall. It is the wrong choice for a lanyard badge, because a badge spends the day being folded, sat on, rained on, and covered by a thumb at the exact moment someone scans it. Bump event badges up a level or two. The tradeoff is that higher correction means a denser code, so pair it with printing slightly larger rather than trying to keep the same footprint.

The quiet zone. This is the plain margin around the code, and it is the single most common reason a nicely designed badge refuses to scan. ISO/IEC 18004 asks for clear space at least four modules wide on all sides, a module being one of those small squares. Designers crop to the artwork edge, or run a border right up against it, and the scanner loses the code outline.

So leave the margin, keep it the same colour as the light squares, and put nothing in it. No logo, no name, no lanyard hole. If your badge layout is tight, shrink the code rather than the margin.

For the finer points on placement and design, our QR code best practices guide is worth a read before you print.

Should You Put Event Tickets in a Wallet App?

For anything ticketed, yes, and the reason is the failure you're most likely to actually hit. An emailed PNG needs the attendee to find the right email, in a crowded inbox, standing in a queue, on whatever signal the venue lobby gives them. A wallet pass is already on the device.

This isn't a workaround, it's a supported format. Apple's Wallet Developer Guide lists five pass styles, and one of them exists purely for this: event tickets, which it describes as "appropriate for passes used to gain entry to an event like a concert, a movie, a play, or a sporting event."

Two details from that documentation are worth knowing before you pick a format.

The first settles the WiFi problem this guide keeps flagging. Apple's guidance notes that when the information a scanner needs is encoded in the barcode itself, "you do not need to connect to your database to process the passes, letting the scanners operate in locations where network access is unavailable." Read that from both ends. The attendee's pass is stored on their phone rather than fetched when they open it, and your scanner can validate without a live connection. That's your basement conference room and your marquee in a field both covered.

The second is a small format choice with a real consequence. Apple lists QR, PDF417, Aztec and Code128 as valid barcode formats, then notes that watchOS does not support Code128, and suggests optimising "for Apple Watch's smaller screen, by using square-sized barcodes, like QR codes." Plenty of people now hold up a watch at the door. A square code is the one that survives that.

Now the honest trade-off, because the offline benefit isn't free. Apple is explicit that this approach "doesn't let you modify the data stored in the barcode." A self-contained code that works with no network is also a code you can't revoke or centrally mark as used the moment it's scanned, which runs straight into the duplicate-ticket problem in the next section. You don't have to pick one. Cache the guest list locally on the scanning device so it can mark codes used offline and sync when the signal returns, and you get both.

What to actually do:

• Offer a wallet pass alongside the emailed ticket, not instead of it. Some attendees won't use it, and the email is still your fallback.
• Tell people to add it before they travel. The pass is only useful if it's on the phone before they're standing in your lobby with one bar of signal.
• Choose QR over Code128 if watches matter to you. It's a free decision at setup and impossible to change once tickets are issued.
• Brief your door staff on screen brightness. A dimmed phone is the most common reason a valid pass won't scan, and it takes two seconds to fix if someone knows to ask.

Android users have Google Wallet as the equivalent, so plan for both rather than assuming your audience is on one platform. And if you're issuing wallet passes, the accessibility rule further down still applies: somebody needs a route in that doesn't involve a phone at all.

Can Event QR Codes Be Faked or Tampered With?

Yes, and it's the one risk most event guides skip entirely. The attack is almost stupidly simple: someone prints their own QR sticker and puts it over yours. The signage still looks right, the code still scans, and it sends people somewhere you didn't choose.

This isn't hypothetical. The US Federal Trade Commission has warned consumers about exactly this pattern in a consumer alert on QR code scams, describing scammers covering legitimate codes on parking meters with their own, and sending codes by text and email with invented reasons to scan. Where it leads is a convincing fake login page that harvests details, or a malware download. The FTC's core advice to the public is not to scan codes that turn up unexpectedly.

Events are an unusually good target for this. Your codes sit on printed signage in a semi-public space, often unattended overnight during setup. Everyone in the building is primed to scan things. And a fake login page asking attendees to "confirm your registration" is exactly what a legitimate event might ask for, so the usual instinct to be suspicious never fires.

Five things make it much harder:

• Laminate or print codes into the material. A code printed directly onto a banner is far more work to cover convincingly than one on a stuck-on card. Anything adhesive is the easy target.
• Walk your signage before doors open, and again after breaks. A physical look for a sticker sitting slightly proud of the surface catches this faster than any technology. Add it to your existing venue check.
• Show the destination in writing. Print the short URL next to the code. Anyone can then see where it should go, and a tampered code becomes obvious to attendees, not just to you.
• Use your own domain for dynamic codes. If your codes resolve through a link shortener nobody recognises, you've trained your attendees that an unfamiliar domain is normal. That's the exact instinct an attacker needs.
• Never ask for passwords or payment behind a scanned code. Registration details and a session link are fine. The moment your legitimate flow asks for credentials, you've made the fake version indistinguishable.

Ticket codes are a slightly different problem, and the answer is validation rather than vigilance. A screenshot of someone else's ticket scans perfectly well, so what stops duplicate entry is your system marking a code as used the first time it's scanned and flagging the second attempt. If your setup doesn't do that, your tickets are decorative.

Can Someone Screenshot a Ticket and Resell It?

Yes, and single-use validation doesn't actually solve it. It just moves the problem to your door, which is worth understanding before you decide you're covered.

Think about what happens with a static ticket code. Someone buys a ticket, screenshots it, sells the image to three people, and turns up themselves. Your system marks the code used on the first scan and rejects the next three. Good. But you now have four people at the entrance, three of them holding what looks like a valid ticket and one of them genuinely paid. Your scanner can tell you the code was already used. It can't tell you which of them is the buyer. That's a dispute your door staff resolve on the spot, at your busiest moment, and the person who paid is as likely to lose as win.

The fix that actually removes the duplication is a rotating barcode. Per Google's Wallet developer documentation, the code on screen changes periodically rather than staying fixed, and the reader is programmed to accept only the current one. Google states the purpose plainly: it reduces the risks tied to barcode screenshotting, specifically ticket theft and unauthorised resale.

Underneath, it's a time-based one-time password, the same idea as the six-digit code in your banking app. A shared secret plus the current time generates a value that gets embedded in the barcode, so a screenshot captures a code that has already expired by the time anyone else tries it. Google's documentation also warns implementers to store the pass on Google's servers and reference it by ID rather than passing the barcode's secret key around, since a leaked secret defeats the whole mechanism.

Now the honest part, because most event guides sell this without mentioning the cost. Rotating barcodes are not something you bolt onto a free static QR code. They need a wallet pass, a shared secret, scanners that validate against a clock rather than a list, and a ticketing platform that supports the whole chain. If you're running a 200-person meetup, this is not your tier.

So match the control to the risk:

• Free or low-value events. Unique code per attendee plus single-use validation is genuinely enough. Nobody is building a resale market for your free workshop.
• Paid events where a ticket is worth reselling. Add a name on the ticket and check one form of ID at the door for anything flagged as a repeat scan. Low tech, and it settles the dispute above in seconds.
• High-demand events with a real secondary market. This is where wallet passes and rotating barcodes earn their setup cost, and where a static PDF ticket is close to negligent.

One thing worth telling attendees in advance either way: if your tickets live in a wallet app, say so on the confirmation email. People screenshot tickets because they're worried the app won't load at the door, and a screenshot of a rotating code simply won't work.

How Do You Handle Re-Entry and Multi-Day Events?

Decide before you print whether the code is a one-time key or a repeatable identity. Almost every problem in this area comes from picking single-use validation, then discovering on the day that people want to step out for lunch.

Look at the conflict directly, because the section above recommends single-use validation and it's the right advice in the case it describes. Single-use marks a code as spent the first time it scans. Perfect for a one-session free workshop. Wrong the moment someone takes a call outside, or the event runs Tuesday through Thursday on the same badge.

The fix is to stop treating the code as a ticket and start treating it as an identity. The code says who this is. Your list decides what they're allowed to do right now. That one change handles both cases:

• Multi-day. The same code stays valid across the run, with one check-in recorded per day. You're storing per-day state against the attendee, not burning the code.
• Re-entry. Scan people out as well as in, and let the code alternate. In, out, in again. The record stays honest and nobody gets turned away at their own event.
• No exit scanning? Then drop single-use entirely and record the timestamp of the most recent scan instead of a spent flag. You lose the duplicate protection, so only do this where the ticket has little resale value.

There's a safety reason to care, not just a convenience one. The crowd-safety section above makes the point that a check-in count is a cumulative arrivals figure rather than a live occupancy number. Re-entry is what widens that gap, and it widens through the day. If your event sits near the thresholds in the UK's Martyn's Law, where the standard tier covers 200 to 799 people who may be present and the enhanced tier starts at 800, the number that matters is how many are inside now. Arrivals-so-far will overstate it, and the overstatement grows every time somebody pops out for a cigarette.

Alternating in and out scans also closes a gap worth knowing about. If a code only ever scans inward, one attendee can walk their badge back out to a friend and you've admitted two people on one ticket. Requiring an exit scan before the next entry makes that fail. It adds friction, so it earns its place at paid events and is usually overkill at a free one.

A few things that only bite once you've printed:

• Settle the rule before the print run. Badge stock gets produced once. Discovering on day one that your codes are single-use is not a software problem at that point.
• Plan for lost lanyards. On a multi-day event, some will vanish overnight. You want a reprint path that reissues the same underlying identity rather than creating a second person in your list.
• Don't make coming back slower than getting in. Re-entry queues form at the worst moment, right when a session is about to start. Same lanes, same speed.

One practical note on tooling. Per-day state and re-entry logic need a code that resolves to something you control rather than a fixed string, which is the case our guide on dynamic versus static codes lays out, and the best practices guide covers the printing and placement side.

Do Your Codes Work for Attendees Who Just Landed?

Often not, and it's the failure mode conference organisers discover at the door rather than in testing. Your codes work perfectly on your own phone, on your own network, in your own country. The person who flew in this morning is running a different experiment entirely.

Three things stack up on them at once, and none of them are about the code.

Roaming is not the safety net you think it is

Inside Europe it mostly is. The EU's roam-like-at-home rules mean that "when you travel outside your home country to another EU country, you don't have to pay any additional charges to use your mobile phone."

But read the boundary. Those rules cover EU member states plus Iceland, Liechtenstein, Norway, Moldova and Ukraine, and the guidance is explicit that "other countries are not covered by this regime." So your delegate arriving from Brazil, India, Japan or the United States is on whatever their operator charges, which is frequently enough that people simply switch data off at the airport.

There's a second detail that catches even covered travellers. Operators apply automatic cut-offs at 50 euros or another preset limit, and data surcharges are capped at 1.30 euros per gigabyte in 2025, falling toward a maximum of 1 euro per gigabyte from 2027. An attendee who has been streaming on the flight can hit a cut-off partway through your event. Their phone worked at breakfast and doesn't at the afternoon session.

The venue WiFi is a browser problem, not a signal problem

"We have WiFi" is the standard answer, and it's usually true and usually not sufficient, because of what sits between the network and the internet.

The IETF's Captive Portal Architecture, RFC 8952, defines the thing precisely: a captive portal is "a network to which a device may be voluntarily attached, such that network access is limited until some requirements have been fulfilled. Typically, a user is required to use a web browser to fulfill requirements imposed by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials."

A web browser. Which means connecting to venue WiFi is not one step, it's a session someone has to complete before anything else on their phone works.

And the RFC is candid about how messily these are built. It notes that current solutions "typically implement some variations of forging DNS or HTTP responses", with some attempting "man-in-the-middle (MITM) proxy of HTTPS in order to forge responses." That is precisely the layer a scanned dynamic code depends on. A code that resolves through a redirect needs working DNS and HTTPS at the moment of the scan, and a captive portal is a system designed to interfere with both until the visitor has clicked through.

What to actually do about it

• Send the ticket in a form that survives no connection. This is what the wallet pass section above is really for. A pass already on the device needs nothing from the network at the door, with the revocation trade-off noted there.
• Don't make arrival depend on a dynamic redirect. Dynamic codes are the right default for signage you might edit, as the static versus dynamic section explains. The entry ticket is the one place where the network round-trip is a liability rather than a feature.
• Tell people to download before they travel. One line in the joining email, phrased for someone who will read it on a plane: save your ticket to your phone now, do not rely on opening the email at the venue.
• Put the WiFi details on the badge, not behind a code. A code that gives you the WiFi password is useless to someone who cannot get online to scan it. Print the network name and password as text.
• Keep one staffed lane that needs no phone at all. Name and ID, checked against a list. The re-entry and accessibility sections both point at the same fallback, and this is a third reason to have it.

The pattern worth noticing is that none of these are QR code problems. The code is fine. What fails is everything the code assumes: a charged phone, a working data connection, an email that loads, a portal someone has already clicked through. Design your entry flow so that the scan is the fast path rather than the only path, and an attendee with a dead SIM becomes a ten second manual check-in instead of a queue.

What About Attendees Who Can't Scan?

Some of them can't, and if your event runs on QR codes alone, that's a problem waiting at your door rather than a hypothetical.

The US government's accessibility team publishes guidance on this, and it's blunter than most event advice. Section508.gov's note on accessible QR code implementation states that users who are blind or have low vision may not be able to locate, scan, or interact with QR codes at all.

Read that word "locate" again, because it's the one people miss. The conversation about QR accessibility usually jumps straight to whether someone can operate a camera. But a code is a purely visual object sitting somewhere on a poster. If you can't see it, you don't know it exists, and no amount of scanning skill helps with a thing you were never told was there.

The guidance's core requirement is simple and most events fail it: provide a text alternative or link next to the code, so anyone who can't scan has another route to the same content. A few specifics worth lifting straight into your event checklist:

• Print the destination URL beside every code. Keep it short enough to type on a phone. This is the single highest-value fix, and you may notice it's the same thing the tampering section above recommends. One change, two problems solved.
• Give digital codes real alt text. Describe what it does, not what it looks like. "QR code linking to the session schedule" is useful. "QR code" is not.
• Hold contrast at 4.5:1 or better. That's the WCAG 2.1 ratio the guidance points to, and it helps scanning generally, not just accessibility.
• Never make a code the only path to something essential. Registration, entry, and the schedule all need a non-scanning route. A staffed desk that can look someone up by name covers most of it.

Then there's the plainer version of the problem, which needs no standards document. Some attendees have an old phone, a flat battery, or no smartphone at all, and older guests are over-represented in every one of those groups. A staffed manual desk isn't a fallback for when the WiFi dies. It's the accommodation that keeps your event open to everyone who bought a ticket, and it should be there on purpose rather than by accident.

One note on scope: that's US federal guidance, so it binds US agencies rather than your conference in Singapore or Kuala Lumpur. But the design principle travels intact, and so does the reputational maths. Turning someone away at your own door because they couldn't scan a square is a bad story regardless of which country's rules apply.

What Mistakes Should You Avoid?

A few small errors cause most event QR problems, and all are easy to dodge:

• No label. A bare code makes people hesitate. Always add a line telling them what it does and why they'd want to scan it.
• Printing too small or low-contrast. A code on a distant banner needs to be big. Faint or tiny codes just don't scan.
• Relying on venue WiFi. Signal is unpredictable at packed venues. Plan for mobile data, offline check-in lists, and lightweight pages.
• Using static codes for everything. If a link changes and the code was static, you're reprinting. Default to dynamic.
• Skipping the test. Always scan every code on a couple of real phones before the doors open.

Get those right and the tech disappears into the background, which is exactly what you want.

What Else Do People Ask About Event QR Codes?

How do QR codes speed up event check-in?

Each attendee gets a unique QR ticket when they register. At the door, staff scan it with a phone or tablet, which confirms the booking and marks the person as arrived in seconds. Scanning replaces the slow part of manual check-in, which is searching a printed list for a surname, so the queue keeps moving. Ignore the precise before-and-after timings QR vendors publish, since almost none disclose a method, but the saving is real and grows with your guest list.

Do attendees need an app to scan event QR codes?

No. Modern iPhone and Android cameras read QR codes with no app at all. Attendees just open the camera, point it at the code, and tap the notification that pops up. Only quite old phones need a free scanner app, so it's worth having a simple backup, like a short link or a staffed desk, for those few guests.

Should event QR codes be static or dynamic?

Dynamic for most event uses. A dynamic QR code points to a short URL you control, so you can change the destination after printing and see scan data by station or session. Static codes have the destination baked in and can't be edited or tracked. Use dynamic for anything you might update or want to measure, and static only for fixed details.

Can you use QR codes for event tickets for free?

Partly. You can make a free QR code that links to a registration form or a schedule at no cost. For unique per-attendee ticket codes with scan validation, a dedicated ticketing platform is easier, and many offer free tiers for small events. So a small gathering can run entirely on free tools, while larger events usually add a ticketing service.

What should you do if the venue WiFi is weak?

Plan for it in advance. Have staff use mobile data as a backup, cache or download the check-in list so scanning still works offline, and keep entry codes pointing to lightweight, mobile-friendly pages. A downloadable schedule and a staffed manual desk as a fallback stop a signal drop from turning into a queue at the door.

Sources: ISO/IEC 18004:2024 QR code bar code symbology specification (iso.org); US Federal Trade Commission consumer alert on QR code scams, December 2023 (consumer.ftc.gov); Government Technology Agency of Singapore on SafeEntry, the national QR check-in system (tech.gov.sg); Ministry of Digital Development and Information of Singapore on SafeEntry check-out (mddi.gov.sg); Personal Data Protection Commission of Singapore on ceasing NRIC use for authentication by 31 December 2026, on the PDPA data protection obligations, and on the Retention Limitation Obligation under section 25 of the PDPA, which requires ceasing retention of documents containing personal data, or removing the means of associating that data with particular individuals, once the collection purpose is no longer served and retention is no longer needed for legal or business purposes (pdpc.gov.sg); Apple Wallet Developer Guide on pass design and creation (developer.apple.com), for the eventTicket pass style, the supported barcode formats including QR, the note that watchOS does not support Code128 and the suggestion to use square barcodes for Apple Watch, and the statement that encoding data in the barcode lets scanners operate where network access is unavailable while not allowing that data to be modified; Statista on mobile QR code usage trends; Section508.gov (US General Services Administration) on accessible QR code implementation, including the requirement to provide a text alternative or link adjacent to the code (section508.gov). All linked above. The data protection section is general information, not legal advice, so check the PDPC guidance for your own situation. We have deliberately not cited a figure for how much faster QR check-in is than a manual list: the numbers circulating on that come from vendor marketing without published method or sample, and we could not find peer-reviewed work establishing a specific figure.

Ready to set up your event? Use our free QR code generator to create a code with no signup and no watermark, and download it as PNG or SVG.

Create a Free QR Code →