Dynamic QR Codes: How They Work & When You Need One
The redirect architecture in detail, what you gain and what you take on, the dependency question nobody prices in, and how to decide between static and dynamic for a specific job.
Guide
Advanced QR Code Topics
Everything on this page follows from one architectural fact: a dynamic QR code puts a server between the scan and the destination. That single hop is what makes codes editable, what makes analytics possible, what creates a privacy obligation, what an API can operate on, and what an attacker can impersonate. Understand the hop and the rest of this section is downstream of it.
The short version
- The redirect hop is the whole story. Editability, analytics, privacy and risk all come from it.
- Scan counts and analytics sessions never match, and both numbers are correct.
- Scan data is coarse by nature — device, rough location, timing. Not people.
- You inherit a data-protection obligation the moment you use a dynamic code.
- Static codes cannot be revoked, which is a security property as well as a limitation.
- Bulk work belongs in an API once you're past a few dozen codes.
What's on this page
The redirect hop, and what it changes
A static QR code contains your destination. Scanning it is a purely local act — the phone decodes the pattern and opens what's written there. No server is involved, nothing is recorded anywhere, and the code will keep working for as long as the destination does.
A dynamic code contains a short URL belonging to a redirect service. Scanning it makes a request to that service, which records the hop and answers with a redirect to wherever you've currently pointed it.
Four consequences, each of which gets its own page in this section:
- The destination becomes editable, because it's a server-side setting rather than printed ink.
- Scans become countable, because a request is made that someone can log.
- You become a data controller, because that log is information about people.
- You acquire a dependency, because the code stops working if the service does.
That last one deserves more weight than it usually gets. A static code printed in 2015 still works today. A dynamic code works as long as somebody keeps paying for and operating a redirect service — which, over the ten-year life of a printed sign, is a real assumption.
What scan data actually measures
Scan analytics are genuinely useful and routinely over-read. The hop can record when a request arrived, roughly where from, and what kind of device made it. It cannot tell you who anyone is, whether they did anything afterwards, or whether the same person came back next week.
The most common confusion is the gap between scan counts and web analytics:
A 10–30% gap between the top and bottom of that funnel is normal. A much larger one usually means something is wrong with the redirect rather than with the measurement.
What scan analytics can and can't tell you → · Connecting scans to Google Analytics →
The obligation that comes with it
The moment you put a dynamic code on something, a log of scan events starts accumulating — timestamps, coarse locations, device types. Under GDPR and similar regimes that is personal data being processed, and you are the one deciding why. That makes you a controller, with the duties that follow.
This is not usually onerous, and it's rarely a reason to avoid dynamic codes. But it is a set of questions with real answers: what's collected, how long it's kept, what your privacy notice says, and whether your provider will tell you any of that. A surprising number won't.
Worth asking your provider
Do they store raw IP addresses? For how long? Is scan data deleted when a code is? Where is it processed? Those four questions separate providers who have thought about this from providers who haven't, and the answers belong in your privacy notice rather than in a support ticket.
Working at scale
Everything above assumes a handful of codes made by hand. Past a few dozen — a code per product, per property, per table, per campaign — the constraint stops being design and starts being operations: creating them in bulk, keeping records of which code is on what, and repointing them without clicking through a UI a thousand times.
That's an API problem. It's also where the interesting failure modes live: partial batch failures, keys with the wrong scope, rate limits hit during an import, and the reconciliation question of which physical object carries which code.
Where the risk lives
QR codes carry text, and text doesn't execute — so the code itself is never the threat. The risk is entirely about destination and trust:
- For people scanning: a code is an opaque link. You cannot read it before following it, which is what makes sticker-over-sticker attacks on public codes work at all.
- For people publishing: your codes are in public, on materials you don't watch, and a covered code redirects your customers to someone else while looking exactly like your campaign.
- The dynamic trade-off cuts both ways: a dynamic code can be repointed if it's abused, which a static one can't — but a compromised dynamic account can repoint every code you've ever printed, at once.
Frequently asked questions
What makes a QR code "advanced"?
Practically, it's whether a server sits between the scan and the destination. Static codes are self-contained and behave like printed text. Dynamic codes route through a redirect, and that single architectural difference is what creates editability, analytics, a privacy obligation, an API surface and a class of security risk. Everything in this section follows from that hop existing.
Do I need a dynamic QR code?
If the code is printed in volume, tied to a campaign, or needs measuring, yes — being able to fix a wrong destination without a reprint is worth the dependency on its own. If it's self-contained data that will never change, like a Wi-Fi password or an asset tag, a static code is simpler, free, works offline and can never be switched off by someone else.
Can QR code scans be tracked without the person knowing?
A dynamic code records the hop whether or not the person notices, which is exactly why it carries a disclosure obligation rather than a technical one. The data is coarse — time, approximate location, device type — and doesn't identify anyone by itself. But "they didn't notice" is not a legal basis, and if you use dynamic codes your privacy notice should say so.
What happens to my QR codes if the service shuts down?
Dynamic codes stop resolving, and there's no way to fix printed material. This is the single largest risk of dynamic codes and it's rarely priced in when choosing a provider. Mitigations: prefer providers who let you export your code-to-destination mapping, consider a redirect on your own domain so you keep control of the short URL, and use static codes for anything that must survive independently.
The full Advanced series
QR Code Analytics: What Scan Data Shows (and Doesn't)
Every field a scan can produce, what each one is actually worth, the four questions scan data cannot answer, and how to design a code scheme that measures something useful.
Connecting QR Scans to Google Analytics
UTM parameters that survive a redirect, why scan counts and GA sessions never agree, how to attribute offline placements, and the consent problem in the middle of it.
QR Codes, Privacy & GDPR
When scan tracking becomes personal data, what to put in a privacy notice, retention and deletion, and the four questions worth asking any provider before you depend on them.
QR Code APIs & Bulk Generation
When to stop clicking and start scripting: batch creation, all-or-nothing semantics, key scoping, rate limits, CSV export, and keeping track of which code is on which object.
QR Codes and Security
Why a code can't carry a virus, how quishing actually works, what to check before tapping, and how to protect codes you've published into the world.
QR Codes vs NFC Tags
Range, cost, hardware support and durability compared honestly — including the cases where NFC genuinely wins and the ones where using both is the right answer.