Static vs dynamic QR codes: the real difference
Every QR code decision reduces to one question: what exactly does the pattern encode? Your address, or someone else's address that forwards to yours. That single difference explains permanence, pricing models, analytics — and most of the rescue stories on this site.
The mechanism
Static: the pattern contains `https://your-site.com`. The phone reads it off the paper and goes there. Two parties: the paper and your server.
Dynamic: the pattern contains `https://provider.io/x7Kp2`. The phone goes to the provider's server, which looks up where `x7Kp2` currently points, and forwards. Three parties — and the middle one has a pricing page.
What each one buys you
| | Static | Dynamic | |---|---|---| | Destination after printing | Fixed forever | Editable anytime | | Depends on a third-party server | No | Yes, on every scan | | Can expire or be disabled | No | Yes — trial, cap, account, shutdown | | Scan analytics | Via UTM in your own analytics | Built-in dashboards | | Cost model | Once (or free) | Subscription for the code's lifetime | | Speed | Direct | One extra hop |
The honest cases for dynamic
Dynamic is a legitimate tool, and pretending otherwise would be marketing. It earns its subscription when: the destination genuinely must change after printing (a monthly program on a permanent sign), scan analytics drive real decisions (A/B campaigns, media attribution), or one printed code must rotate across uses. If one of those is your actual situation, buy dynamic knowingly — meaning: from a provider you trust, with the subscription budgeted for the print's whole life, because the free-trial version of dynamic is where the horror stories come from.
The default for everything else
For menus, packaging, business cards, signage, manuals, labels — anything where the print outlives a billing cycle — static is not a preference, it is risk management. The printed object's lifespan should not depend on a SaaS renewal. Editability, the one real sacrifice, has a structural workaround: point the static code at a page you control, and edit the page. You keep permanence *and* changeable content; the only thing you give up is the intermediary.
Deciding in one line
Need to change the *destination itself* after printing, or need built-in scan dashboards → dynamic, with a provider you trust and a budget line. Everything else → static, verified before the print run. And whichever you choose: run the test — scan it, read the URL, know what you printed.
Frequently asked questions
What is the difference between a static and a dynamic QR code?
A static code encodes your destination directly in the pattern; scanning goes straight to your page. A dynamic code encodes a provider's short URL that redirects to your page — editable, trackable, and dependent on that provider's service staying active.
Which one is better for printing?
For anything printed at volume or meant to last — menus, packaging, signage — static: the printed object stays valid as long as your destination exists, with no subscription keeping it alive. Dynamic suits campaigns that genuinely need post-print edits or scan analytics.
Can a static QR code be tracked?
Not by the code itself — there is no intermediary to count scans. You can add a UTM parameter to the destination URL and read visits in your own analytics, which covers most real needs without a rented redirect.
Can I convert a dynamic QR code into a static one?
Not the printed one — the pattern encodes the provider's URL forever. You generate a new static code encoding your real address and reprint. That is why the choice matters most before the first print run.
Create a QR code that answers to no server.
Static, permanent, yours. €5 once — no subscription, no expiry, print-ready files.
Create my permanent QR