Static and dynamic QR codes, compared
One encodes your destination, the other encodes someone else's short link. That difference decides everything else.
What this covers
- What is physically encoded in each case
- A side-by-side comparison of editability, cost, privacy and failure modes
- The middle option: a redirect on a domain you control
- What OpenQRS deliberately does not do, and when that should send you elsewhere
What it does not
- Recommendations between specific dynamic QR vendors
- Analytics practice: if you collect scan data you take on obligations this page does not cover
- Any suggestion that dynamic codes are a trick — for some print runs they are the correct purchase
What each one puts in the symbol
A static code contains your payload. Encode https://example.com/spring-menu and those exact 31 characters are in the modules; a scanner decodes them and hands them to the browser with nothing in between.
A dynamic code contains a short address belonging to a redirect service — something on the order of https://qr.example/aB3xQ. The scanner decodes that, the phone requests it, the service looks the code up in its database and answers with a redirect to wherever you have currently pointed it. The destination is not in the printed square at all.
Everything people argue about follows from that single difference. It is not a quality difference between two kinds of QR code — both are ordinary symbols encoding ordinary text — it is a question of whether a third party sits between the scan and the destination.
Side by side
| Static | Dynamic | |
|---|---|---|
| What is encoded | Your destination or your data | A short address owned by a provider |
| Editable after printing | No | Yes |
| Scan analytics | None are possible | Yes, held by the provider |
| Ongoing cost | None | Usually a subscription |
| If the provider stops trading | Unaffected | Every printed copy stops working at once |
| Symbol size for a long destination | Grows with the destination | Fixed and small |
| Works with no network | Yes for Wi-Fi, vCard and text payloads | No — the redirect must resolve |
| What the scanner reveals | Nothing to anyone | IP address, time and user agent to the provider |
| Destination visible before opening | Yes, the reader shows it | No, only the short domain is shown |
The size row is the one people underestimate. A 180-character destination is a version 9 symbol at level M; a 25-character short link is version 2. That is 53 modules against 25 — at a fixed printed width, more than twice the density. If a long destination genuinely has to fit on a small sticker, a redirect is the honest engineering answer. The question is whose redirect it is.
The middle option nobody sells you
Point a static code at a short path on a domain you own — example.com/m — and serve a redirect from there. The symbol stays static and small, and the destination stays changeable, because you can edit the redirect whenever you like.
- The provider-shutdown row stops applying, because the provider is you.
- The symbol is as small as any dynamic code, since the encoded address is just as short.
- The person scanning sees your domain in the reader's preview, which is a real anti-phishing property a generic short domain cannot offer.
- You need a domain you intend to keep for as long as the print run lives, and a host that can serve a redirect.
- You also get the server logs, which means you now hold scan data and whatever obligations come with holding it.
This is the arrangement worth considering for packaging with a multi-year shelf life, where the destination may well move but a subscription lapsing is unacceptable.
What OpenQRS does not do
Every generator on this site is static, without exception. The payload is built in your browser and written into the symbol, and no part of it is stored, shortened or routed through anything of ours.
That has two consequences worth stating plainly rather than burying. We cannot change where a code points after you have printed it, and we cannot tell you how many people scanned it. There is no account to log in to and no database that would make either possible. If editing after printing or scan reporting is a requirement of your project, a dynamic provider is the correct purchase and this site is not a substitute for one.
- Print run you control, destination on your own site: static, with no further thought needed.
- Long-lived packaging with a destination that may move: static code pointing at a redirect you own.
- Campaign-level scan reporting is a hard requirement: a dynamic provider, and read their data retention terms first.
- Wi-Fi credentials, a contact card, a phone number or plain text: there is nothing to make dynamic. The payload is the content, and a redirect could only get in the way.