QR Code Check-In: How the Door Actually Works (and How Many Lanes You Need)

QR code check-in is simple to describe and easy to get wrong. An attendee shows a code, someone scans it, a screen says yes or no. The hard parts are everywhere else: how many people one lane really processes, what happens when the venue Wi-Fi drops, what the code should contain, and what the person on the door does when the answer is no.

This guide covers the door as an operation rather than as a feature list. It assumes you have decided to use QR codes and now have to make them work for a real number of people arriving at a real time.

How QR Code Check-In Works

Every QR check-in system, from a spreadsheet to a five-figure platform, is the same four pieces:

1. An identifier per attendee. A unique string — ideally a random one — that means nothing on its own.
2. That identifier encoded as a QR code and delivered to the attendee, by email, in a wallet pass, or printed on a badge.
3. A list at the door mapping identifiers to people, and a record of which ones have already been used.
4. A scanner that reads a code, looks it up, and shows a decision fast enough that the next person can step forward.

Notice what is not in that list: nothing in a QR code is checked, signed or verified by the format itself. A QR code is a way of writing text down so a camera can read it, nothing more. All the security lives in your list, which is why the design of the identifier matters so much.

What the Check-In Code Should Contain

An opaque identifier, and nothing else. This is the single most common design mistake at small events, and it comes from a reasonable-sounding instinct: put the attendee's name and email in the code so the door can see who they are without a lookup.

The problem is that a QR code has no access control. Any scanner pointed at a badge reads everything in it — the QR code payload decoder on this site will show you exactly what any code gives away, including your own. A badge encoding a name, employer, email and phone number is handing that to anyone in the room who can see it across a table, and conference badges are worn for two days in crowded spaces.

Under the GDPR this is also a compliance question, not just a courtesy. Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary for the purpose it is processed for. The purpose at the door is validating entry, and the minimum needed for that is a reference that is useless without your list. A random ticket ID satisfies it; a vCard does not. (This is the general principle, not legal advice for your event — the lawful basis and retention period for your attendee data are worth a specific answer.)

Keep the identifier long enough and random enough that it cannot be guessed. Sequential numbers — 001, 002, 003 — are the other common mistake: anyone holding ticket 47 can work out what ticket 48 looks like and generate it. Our breakdown of what conference badge QR codes actually carry shows how varied real-world practice is here, and how much some events leak.

How Fast Is a Check-In Lane, Really?

This is the number that decides your staffing, your floor plan and whether your keynote starts on time. It is also the number nobody can tell you.

Here is what published event-industry guidance says one staffed lane handles. These are planning figures offered by companies that sell event software, not measurements from a controlled study, and they are presented here precisely because they disagree:

The top of that range is more than eight times the bottom. A plan built on 500 an hour when your real rate is 120 is not slightly optimistic — it is wrong by a factor that turns two lanes into eight.

The spread is not carelessness. It reflects a real variable: how much the person on the door is doing besides scanning. The scan itself is well under a second on any modern phone. Everything around it is the cost — the attendee reaching the front, finding the right email, waking a dimmed screen, the lookup resolving, the greeting, the badge printing, the lanyard, the move away from the desk.

Measure your own rate in five minutes

Line up twenty colleagues with codes on their phones. Run them through exactly the process you will use on the day — same app, same badge design, same venue lighting if you can. Divide the elapsed time by twenty. That single number beats every row in the table above, because it includes your staff, your network and your attendees' phones.

Then put it into the check-in lane calculator, which takes your headcount, your arrival window and your measured seconds-per-scan and tells you the lane count, the peak queue and the longest wait. It deliberately refuses to guess the scan rate for you, and it shows how far the answer moves when that one input changes.

How Many Lanes Do You Need?

The arithmetic is short enough to do on paper, and the important part is what it starts from.

Size the door to the busiest window, never to the headcount. This is the one thing the sources agree on. A 1,000-person conference where people drift in across three hours is an easier door than a 300-person awards dinner where almost everybody arrives in the ten minutes before the room opens. Published planning advice commonly assumes something like 60–70% of attendees arriving inside a single short window, and your own figures from last year are better than any rule of thumb.

Then:

• Peak arrivals = headcount × share arriving in the window
• Arrival rate = peak arrivals ÷ window in minutes
• One lane's rate = 60 ÷ seconds per attendee, in people per minute
• Lanes needed = peak arrivals × seconds ÷ (window × 60), rounded up

A worked example

A 500-person conference. Experience says 70% arrive in the half hour before the keynote. A dry run measured 8 seconds per attendee.

Peak arrivals are 500 × 70% = 350 people in 30 minutes, so 11.7 a minute. One lane at 8 seconds does 7.5 a minute. Lanes needed = 350 × 8 ÷ 1,800 = 1.56, rounded up to 2.

Now run the same event on one lane. Capacity is 7.5 a minute against 11.7 arriving, so the queue grows by 4.2 people every minute. After the half hour, 125 people are still waiting, the last of them for about 17 minutes, and the door does not clear until 47 minutes after it opened — well into a keynote 350 people were meant to be seated for. The difference between those two doors is one member of staff.

Then add slack, and an exception desk

Two caveats turn the minimum into a plan.

First, the model assumes arrivals land at a steady rate. They do not — real arrival curves spike, and a spike inside your window makes a longer queue than the arithmetic shows even when the totals match. Treat the lane count as a floor. Industry planning advice converges on roughly 20–25% spare capacity for breaks, flat batteries and bursts.

Second, keep one staffed position off the scanning rota entirely. A scanning lane is only fast while every code works. The moment somebody arrives with no booking, a refunded ticket, a name that does not match or a dead phone, that lane stops being a lane and becomes a help desk while everyone behind them waits. An exception desk protects the throughput of every other lane, and it is the cheapest thing on this page.

One more free improvement: run a single feeder queue serving all lanes rather than a separate queue per lane. It stops a lane sitting idle while the queue beside it backs up behind one slow attendee.

The Duplicate Problem

A QR code is data, so it copies perfectly. A screenshot of a ticket is indistinguishable from the original, a photo of a printed badge scans exactly the same, and no styling, watermark or logo on the image changes that — we go through this in detail in whether a screenshot of a ticket QR code works.

The only thing that stops a copy being used is first scan wins: the door records that an identifier has been admitted and refuses it the second time. This is the single most important feature of a check-in system and the one most likely to be quietly missing. Some tools accept a repeat scan of the same code without flagging anything at all — worth testing before you rely on it, by scanning the same code twice and watching what the screen says.

Why offline mode makes it worse

Offline check-in is sold as resilience, and it is, but it changes what duplicate detection can promise. An offline device can only compare a scan against the attendee list it last downloaded. Two consequences follow, and both are structural rather than bugs:

• It cannot know about changes since the sync. A ticket refunded or revoked after the list was downloaded still looks valid on that device.
• Two offline doors can admit the same code. If gate A and gate D are both offline, a code scanned at A is unknown at D until one of them syncs, so the same ticket gets two people in. Vendor documentation is candid that offline check-ins queue until reconnection; shorter sync intervals shrink the window but do not close it.

If duplicate detection genuinely matters at your door, you have two honest options: keep the devices online, or split the code ranges by gate so that no single code can be presented at two doors. The second works offline and needs no network at all, at the cost of telling attendees which entrance to use.

Check-In and Check-Out

Some events need to know not just who arrived but who is still in the building — a contractor induction, a volunteer shift, a training session logging attended hours, or a venue with a roll-call obligation.

Mechanically this is the same scan, recorded twice. The design decisions that matter are:

• Direction. Either dedicate a device to each direction — the in-door scanner only checks people in — or have the system infer the direction from the previous state of that identifier. Inferring is more convenient and fails more interestingly: a missed exit scan leaves someone apparently inside all night.
• Timestamps you can export. Attendance records only matter if you can get them out. A duration is a subtraction between two timestamps, so what you need from the scanner is a full timestamped history, not just a tick next to a name.
• Honest gaps. People leave without scanning out. Every attendance report built this way has open sessions in it, and it is better to show them as unknown than to guess an exit time.

Note that check-out breaks first-scan-wins: the same code is now meant to be scanned repeatedly. If you need both duplicate protection on entry and repeat scans for exit, the scan log has to carry the direction, otherwise the two rules contradict each other.

Doing It Without an Event Platform

For an event up to a few hundred people, the platform-free route is genuinely viable, and nobody selling an event platform is going to tell you where the line is. Here it is as honestly as we can put it.

What you need:

• A unique code per guest. The event check-in QR generator turns a pasted guest list into one code each and a printable sheet, and includes a door check that flags a code scanned twice.
• A phone or two with a scanner that keeps a timestamped history — that history is what you reconcile against the guest list afterwards, and what gives you your real seconds-per-scan for next time.
• Badges sized so the code scans first time. A code that is too small or too tightly cropped costs seconds on every scan, and those seconds are the input that drives your whole lane count. The print size calculator gives the width and the quiet zone the badge needs.

Where the DIY route stops being the right answer:

• Multiple simultaneous doors needing shared state. This is the real boundary. Two independent devices with two independent lists cannot catch a duplicate across doors.
• On-demand badge printing, which needs hardware and software integration.
• Walk-up registration and payment at the door.
• Per-session scanning across a multi-track programme, where the same attendee is checked into a dozen rooms and you need reporting per session.
• Lead retrieval for exhibitors, which is a different purpose from entry validation and needs its own consent — attendees have not agreed to have their details handed to a sponsor just by walking through your door.

One structural point worth making before you choose: a check-in code should be static. The appeal of dynamic QR codes is that you can change where they point after printing, but that routes every scan through a third-party redirect — which means a dependency on their servers and their uptime at the exact moment your door is busiest, and no function at all if the venue Wi-Fi fails. Validation belongs in your list, not in the code.

For the wider picture — tickets, schedules, networking, sponsor booths, venue Wi-Fi — see our full guide to QR codes for events. This page is just the door.

What Goes Wrong on the Night

In rough order of how often it actually happens:

• The code will not scan off a phone screen. Dimmed brightness, a cracked screen, a matte protector, or direct sunlight on the glass. Ask attendees in advance to turn brightness up and have the code open before they reach the front — this one request buys more throughput than another lane. Why barcodes fail to scan from screens covers the rest.
• The attendee cannot find the email. Hence the exception desk.
• The name does not match the booking. Transferred and group-booked tickets. Decide the policy before the door opens, not at it.
• The network drops. Test the venue's Wi-Fi at the door position, at the time of day you will use it, with the number of devices you will have on it.
• A phone battery dies mid-rush. Battery packs per lane, and one spare configured device that someone can pick up and use immediately.

Frequently Asked Questions

How many people can one QR code check-in lane handle?

Published event-industry estimates range from about 60 an hour for a desk that also prints badges to 300–500 an hour for a dedicated scanner reading codes attendees already have open. The spread is genuine and depends almost entirely on what staff do besides scanning. Measure your own rate with a twenty-person dry run rather than adopting any single published figure — a plan built on the wrong end of that range is out by a factor of eight.

How do I calculate how many check-in lanes I need?

Take the number of people arriving in your busiest window, multiply by your seconds per attendee, and divide by the window length in seconds, then round up. For 350 arrivals in 30 minutes at 8 seconds each: 350 × 8 ÷ 1,800 = 1.56, so two lanes. Add about 25% spare capacity and keep one extra staffed position off the scanning rota for problem cases. The lane calculator does this and shows the queue and longest wait.

Can someone use a screenshot of a check-in QR code to get in twice?

They can copy the code perfectly — a QR code is just encoded data and nothing in the image prevents duplication. What stops the copy working is the door recording that the code has already been admitted and refusing it on the second scan. Test that behaviour before you rely on it: scan the same code twice and see whether the system flags it, because some tools accept the repeat silently.

Does QR code check-in work without internet?

Scanning works offline — reading a QR code is local to the camera. What needs the network is shared state. An offline device validates against the list it last downloaded, so it cannot see a ticket refunded since then, and two offline doors can both admit the same code before either syncs. For a single door, offline is fine. For several doors that must not double-admit, either stay online or give each gate its own range of codes.

What should a check-in QR code contain?

A random, opaque identifier that means nothing without your attendee list. Not a name, email or phone number: any scanner pointed at the badge can read everything in the code, and GDPR Article 5(1)(c) limits personal data to what is necessary for the purpose. For validating entry, a reference is sufficient. Avoid sequential numbers too, since ticket 47 tells you what ticket 48 looks like.

Should check-in codes be static or dynamic?

Static. A dynamic code routes every scan through a third-party redirect, which adds a dependency on someone else's servers at your busiest moment and fails entirely if the venue network does. The ability to change the destination after printing — the reason dynamic codes exist — is not something a check-in code needs, because the validation lives in your list rather than in the code.

Can I do event check-in without buying an event platform?

For up to a few hundred guests at a single door, yes: one unique code per guest, a printed sheet or emailed codes, and a phone scanner that keeps a timestamped history you can reconcile afterwards. The point at which a platform earns its cost is multiple simultaneous doors needing shared duplicate detection, on-demand badge printing, walk-up registration and payment, or per-session scanning across a multi-track programme.

How do I handle check-in and check-out with QR codes?

Scan the same code twice and record the direction, either by dedicating a device to each direction or by inferring it from that identifier's previous state. Export timestamps rather than a simple attended flag, because a duration is the subtraction of two times. Expect missing exit scans and report those sessions as unknown rather than estimating. Note that check-out conflicts with first-scan-wins, so the log must distinguish an entry from an exit.