Static vs dynamic QR codes
Every QR code generator eventually asks you to upgrade for "dynamic" codes, usually with a warning that static ones can never be changed. The distinction is real, but it is narrower than the pricing pages suggest, and the useful half of it is available without a subscription.
What the two actually are
A static code contains the destination. The URL is encoded directly in the pattern. Scanning it goes straight there — no intermediary, nothing to expire, nothing that can be switched off. Change the destination and you must reprint.
A dynamic code contains a redirect. The pattern encodes a
short URL on the provider's domain, something like
qr.provider.com/a4f2b. Scanning it hits their server, which
forwards you on. Because the forwarding rule lives in their database, the
destination can be edited after printing.
The scan-time behaviour is otherwise identical. A phone cannot tell the difference, and neither can a person.
What you actually pay for
Dynamic codes are sold on three benefits. They are worth separating:
| Benefit | Real? | Needs a subscription? |
|---|---|---|
| Change the destination after printing | Yes | No — see below |
| Scan counts and analytics | Yes | No, if you run the redirect |
| Smaller, denser-free pattern | Yes | No — any short URL does this |
All three come from the same thing: the code points at a short URL you can control. Nothing about that requires it to be their short URL.
The version without a subscription
Point your codes at a path on a domain you own, and redirect from there.
https://ex.co/m1 encoded in the print run; where
/m1 sends people is a line of configuration you can change
whenever you like.
You get the editable destination, and you also get:
- Your own domain in the code. Scanners increasingly preview the URL before opening it, and people are more willing to tap a name they recognise than an unfamiliar shortener.
- No third-party dependency. Provider shuts down, changes pricing, or lets a domain lapse and every printed code you own becomes dead. This is not hypothetical; QR shorteners have disappeared before, taking client campaigns with them.
- Your own analytics. Server logs already record the hits. That is the same data, without a dashboard subscription.
- No scan limits. Free tiers cap scans per month and stop resolving when you exceed them — the worst possible failure, because it arrives exactly when a campaign is working.
The cost is that you need somewhere to host the redirect. If you already have a domain and any hosting, it is minutes of work.
Why short URLs help regardless
A shorter URL needs fewer modules, and fewer modules at a fixed physical size means larger, more readable squares. This is the single biggest lever on whether a small printed code scans reliably — bigger than error correction, bigger than most sizing decisions. See sizing for print.
So the redirect approach improves scannability as a side effect, which is why long tracking URLs encoded directly into a small label are worth avoiding.
Scan tracking, and what it costs you
Analytics is the other half of the dynamic pitch, and it deserves more scrutiny than it usually gets. When a code routes through a provider, every scan is a request to their server, carrying the scanner's IP address, approximate location, device type and timestamp. You see a dashboard; they see the raw data across every client they serve.
If your codes are on anything sensitive — patient-facing material, internal asset tags, anything in a workplace — that is a data-sharing decision, and under GDPR or similar regimes it is one you have to be able to account for. A processor agreement with a QR shortener is rarely on anyone's list until an audit asks for it.
Running the redirect yourself avoids the question entirely. Your server logs contain the same information, on infrastructure you already have a legal basis for, and you can aggregate or discard as your own policy requires. If you genuinely do not need per-scan analytics — and for asset tags and menus you usually do not — you can log nothing at all.
Worth checking before you commit to any paid plan: what happens to existing codes if you stop paying, whether there is a scan cap and what happens when you exceed it, and whether you can export your redirect map to move elsewhere. Providers vary, and the answers are rarely on the pricing page.
When a static code is simply correct
Plenty of jobs never need an editable destination:
- Asset and inventory tags where the code encodes a fixed ID rather than a web address. There is nothing to change. See asset labels.
- Event badges tied to a single attendee for a single day. See event badges.
- WiFi credentials, phone numbers, contact details — fixed data with no server in the picture.
- Anything permanent: a plaque, a museum label, a building sign pointing at a stable page.
For these, a static code is more robust, not less. It has no dependency that can lapse.
What this tool makes
The generator produces static codes. Whatever you supply is encoded directly, with no intermediary and no account.
Which means the two approaches combine cleanly: put your short redirect URLs in the spreadsheet column, and generate static codes pointing at them. You get editable destinations and full control, with nothing to subscribe to. The CSV walkthrough covers the bulk version of that.
Before committing a code to something expensive or permanent, ask what happens if the destination has to move in two years. If the answer is "reprint everything", route it through a path you control now.