How many times can a QR code be scanned?

The five-minute version

1. A static code has no limit and cannot be given one. The data is in the pattern; the phone decodes it locally. There is no counter, no server, nothing to run out.
2. A scan cap is a billing meter, and it belongs to a dynamic code’s redirect service — free and trial tiers commonly cap in the low hundreds of scans a month.
3. The cap is on the account, not the code. The same printed poster works or fails depending on the state of a subscription nobody standing in front of it can see.
4. Caps fail at the worst possible moment — a threshold is crossed by success, so the code dies at the peak of the thing you printed it for.
5. If you genuinely want a one-scan code, the limit goes at redemption, in your list, not in the pattern.

Why a static code cannot have a scan limit

It is worth being precise about what happens when someone scans, because the whole answer falls out of it. The camera sees a grid of light and dark squares. Software on the phone finds the three corner markers, reads the modules, corrects any that were dirty or creased, and turns the result into a string. If that string is a URL, the phone offers to open it. Up to that point nothing has touched the network at all — the decode is arithmetic on an image, done offline, on the device.

So there is no moment in the scan of a static code at which a limit could be enforced, and no place a count could be kept. The pattern does not know how many times it has been read, any more than a printed phone number knows how many people have dialled it. This is why “unlimited scans” on a static generator’s feature list is faintly absurd: it is not a feature, it is the absence of a mechanism.

One honest caveat: the code is unlimited, the destination is yours. A static code will hand out your URL forever, but the page at the end of it is a normal web page with normal limits — it can go down, move, or fall over under load. The difference is that those are your problems on your infrastructure, fixable without a reprint, rather than a threshold in someone else’s pricing table.

Where scan caps actually come from

A dynamic code does not encode your destination. It encodes a short link on the QR vendor’s domain, and every scan is a request to their server, which logs it and issues a redirect. That log is the product — it is where scan analytics come from — and it is also the meter. Because every resolution costs the vendor a request, the plan you are on has to be denominated in something, and the natural unit is scans.

What happens at the ceiling varies, and the variation is itself a problem. Some services stop redirecting and show an upgrade page. Some keep redirecting but stop counting. Some disable the code until the month rolls over. You cannot tell which from the printed object, and neither can the person holding it: they see a code that worked yesterday and does not work today. The expiry guide covers the same machinery from the time direction; a scan cap is that machinery metered by volume instead.

A cap is worse than a deadline, and this is why

An expiry date is at least a date. It is knowable in advance, it can go in a calendar, and it arrives whether the campaign went well or badly. A scan cap has none of those properties. It is triggered by use, so it is triggered by success — and it will therefore fire on the day the code is scanned most, which is the day the printed thing is doing exactly what you printed it for.

The shapes this takes are all the same shape. The conference badge run that works through registration and stops in the afternoon. The menu that survives four quiet weekdays and fails on Saturday evening. The launch flyer that gets picked up more than expected and then, precisely because of that, sends the next few hundred people to an upgrade prompt. Monthly caps that reset add a final insult: the code starts working again a few days later, after the event it was printed for is over, which makes the failure almost impossible to diagnose from complaints.

This is the cluster’s standing rule arriving from a new direction. The static-versus-dynamic guide argues that renting a redirect puts a landlord between your printed object and your customer. The usual worry is the lease ending. A scan cap is the same landlord charging by the visitor and locking the door when too many turn up — the identical dependency, failing on a different axis, and it does not care whether your subscription is current.

If you actually want a limit

Sometimes the question is not a fear but a requirement: one scan per ticket, one redemption per voucher, one entry per person. The answer is that the limit cannot live in the code and does not need to. Anything a camera can read, a camera can copy — a screenshot of a “single-use” code scans exactly as well as the paper original, so no property of the pattern can enforce anything.

Put the limit where the decision is made instead. The code carries a random ID; the first scan marks that ID used in a list you hold; every later scan of the same ID is refused at the door. The copy is not prevented, it is made worthless, which is the only form of prevention available. The event ticket guide works through the full first-scan-wins setup, and the coupon guide does the same for redemption state. Note what this buys you: an unlimited static code plus a list you control gives you a hard per-code limit, which is strictly more than a metered dynamic service offers, because its cap is per account and not per code.

No, the code does not wear out

A related worry sits underneath the question: that a code has some finite number of good scans in it, like a scratch card. It does not. Reading a pattern does not consume the pattern. A code on a museum label scanned two hundred thousand times is in exactly the condition its ink and substrate are in, and no worse for the traffic.

What genuinely degrades is physical, and it degrades on a clock rather than a counter:

• Fading. Sunlight kills contrast, and contrast is what the decoder needs most. An outdoor code printed in a mid-grey starts with less margin than it looks like it has.
• Abrasion. Anything pocketed, stacked or wiped loses modules. Error correction absorbs a surprising amount of this, which is why damaged codes often still scan — see the troubleshooting guide for what has usually been spent by the time one stops.
• Curvature and lamination. A code on a bottle or a curved case distorts the grid; gloss adds glare. The packaging guide covers both.
• Encroachment. Someone puts a price sticker or a second label over the quiet zone, and the decoder can no longer find the symbol’s edge.

How to tell whether the code you are about to print has a cap

1. Decode it and read the host. Scan your own code and look at the URL before opening it, or paste the file into any decoder. If the domain belongs to the QR company rather than to you, it is dynamic and metered, whatever the generator called it.
2. Find the number in the pricing page, not the feature list. “Unlimited scans” on the marketing page and a scan allowance in the plan table are routinely both present. The plan table is the one that is enforced.
3. Ask what happens at the ceiling — stops redirecting, stops tracking, or disables the code — and whether it resets monthly. If you cannot get a straight answer before printing, you will get it during your event.
4. Estimate against your print run honestly. Five hundred flyers do not mean five hundred scans; they can mean far more, because one poster in the right place is scanned by everyone who walks past it. Caps are crossed by the successful placements, not the average ones.
5. If none of this is appealing, encode your own URL. A short path on a domain you own is sparse enough to print small, editable server-side, and answerable to nobody — the data limit guide covers keeping that path short enough to stay a small code.