Static vs Dynamic QR Codes: How to Choose, and What It Costs to Get It Wrong
A decision framework for static vs dynamic QR codes, built around reprint cost and vendor dependency rather than a feature list.
A static QR code stores its destination inside the pattern itself: scan it years from now and it opens the exact same page, because there is nothing else it could open. A dynamic QR code stores a short redirect instead — a tilg.in/{code} link, for example — so the printed pattern stays fixed while the destination behind it can change. Nearly every static-versus-dynamic argument you'll read is this one question wearing a disguise: will you ever need that flexibility, and is it worth paying to keep available?
Static and dynamic solve different problems, not competing ones
A static code can encode a URL, plain text, a vCard contact card, WiFi credentials, an email address, or a phone number, directly. Once it's generated, nothing else needs to happen for it to keep working: there's no server in the loop, no subscription to lapse, no company that needs to still exist. Its entire risk is decided at the moment of printing. Whatever destination or content sits inside the pattern is what a scanner will get, forever.
A dynamic code encodes a short link instead: a standalone tilg.in/{code} URL, or a Short URL type built for print, that resolves to a destination held on the platform's side. The printed artwork never changes. What changes is the mapping the redirect looks up. That single indirection is where every dynamic advantage and every dynamic dependency both come from. You can fix a mistake or update a campaign without a reprint, and every scan passes through a service that has to still be running, still be trustworthy, and still be the same one you signed up with.
Neither format is the "better" one in general. A permanent facility plaque and a limited-run product flyer have almost nothing in common as printing problems, and they shouldn't use the same kind of code.
It also helps to be clear about what dynamic does not change. A dynamic code doesn't make the printed pattern itself editable — the colour, the centre logo, the physical size, all of that is locked in the moment you print, exactly as it would be for a static code. The only thing dynamic makes editable is where the code sends someone after they scan it. If your worry is a design mistake rather than a destination mistake, dynamic doesn't help you; only a reprint does, on either format.
Four questions to ask before you choose
Most static-versus-dynamic debates skip straight to features. The more useful version of the question is about what happens after the ink is dry.
| Question | Static is enough | Dynamic earns its cost |
|---|---|---|
| Will the destination ever need to change after the artwork is printed? | No — the content is genuinely fixed: WiFi credentials, a phone number, a vCard, a warranty page that will never move | Yes — a URL, an offer, or a landing page that might be revised, replatformed, or seasonally swapped |
| Do you need to know how many people scanned, when, and roughly from where? | No — the code just needs to work, and nobody downstream will ask for a number | Yes — a marketer, a client, or a manager will want scan volume, timing, or location to justify the placement |
| What does getting it wrong actually cost you? | High-volume or high-value substrate — packaging, cartons, permanent signage — where a wrong destination means a genuine reprint | Low-stakes or already-flexible substrate — a poster you'll swap next month anyway, a screen, a one-off event banner |
| How long does the code need to keep working? | Indefinitely, on a timescale longer than you'd trust any vendor to exist — archival documents, equipment labels, a monument | A defined campaign window, where an ongoing platform relationship is an acceptable trade for editability |
If your placement lands mostly in the left column, stop reading and use static — the next two sections exist to argue you out of paying for flexibility you don't need. If it lands mostly in the right column, the rest of this piece is about using dynamic well.
What a wrong static code actually costs
The cost of a wrong static code isn't the QR code. It's whatever it's printed on, and how much of that you printed.
Signage and short-run print are forgiving. A standee, a poster, or an A4 flyer is typically produced from a digital file with no dedicated plate or die — correcting the artwork and reprinting is close to the same job as printing it the first time, just done twice. The waste is real but bounded: the cost of one more short run, and the time it takes to get one.
Packaging and label runs are not forgiving, for a structural reason. High-volume print processes such as flexography or gravure are set up with tooling, plates or cylinders, cut specifically for that artwork, and that tooling has a minimum order quantity built into its economics. You don't print a thousand cartons cheaply and a hundred thousand cheaply per unit; the tooling cost is amortised across the run, which means a mistake found after the run has started is a mistake found after most of the cost is already committed. A wrong static URL on a carton isn't a design fix. It's the full print run, the tooling, and the packed inventory sitting on it, all written off at once — plus whatever it costs to hold the product back from sale while it's redone.
Signage between these two extremes — standees at a retail counter, wall graphics in an office, vehicle wraps — sits on a sliding scale of the same logic: the more specialised the substrate and the larger the run, the more a static mistake resembles the packaging case rather than the poster case.
There's a second cost that rarely makes it into the conversation: time. A print correction on packaging usually means a design fix, a fresh proof, tooling turnaround, and a new production slot, in sequence rather than in parallel. If the product is already committed to a launch date or a retailer's shelf-reset window, the calendar cost can end up mattering more than the reprint bill itself, because stock that can't legally ship with a wrong or unreviewed code just sits, unsold, while all of that happens. None of this is a reason to avoid static codes. It's a reason to be certain, before a high-volume run starts, that "fixed" genuinely means fixed.
This is the actual argument for dynamic on anything printed at volume: not that analytics are nice to have, but that a dynamic code turns a potential reprint into an edit. Editing a dynamic code after it ships costs nothing at the printing stage — the artwork never has to be touched again, because the mistake, if there is one, lives in the destination mapping, not the ink.
Static vs dynamic, capability by capability
| Capability | Static | Dynamic |
|---|---|---|
| Destination fixed at the moment of printing | Yes, permanently | No — editable afterwards, with a record of what changed and when |
| Requires an ongoing platform or subscription to keep working | No | Yes — the redirect has to resolve every time it's scanned |
| Scan analytics (total vs unique, scans over time, top geography, top device) | Not possible — there is no redirect step to observe | Yes, per code |
| Content types available | URL, plain text, vCard, WiFi, email, phone | Short URL / standalone short link |
| Can be disabled if the destination turns out to be compromised | No — the destination is inside the pattern, so there's no redirect to intercept | Yes — a live dynamic code can be disabled |
| Colour, centre logo, PNG and vector export | Available on both | Available on both |
| Ongoing cost to keep it working | Zero — nothing has to keep running for the code to still work | A live subscription and a live redirect domain, indefinitely |
| Vendor dependency | None | Depends on the redirect domain and the company behind it staying operational |
The pattern in that table is not "dynamic wins on features." It's that every dynamic advantage is downstream of a live service, and every static limitation is the price of having no live service at all.
The other mistake: defaulting to dynamic for everything
The less-discussed error runs the opposite direction. Dynamic codes are the ones that count against your plan's allowance — static codes are unlimited — so treating dynamic as the safe default for anything you're not sure about quietly spends that allowance on codes that never needed the flexibility, the subscription, or the dependency in the first place. A vCard on a business card, a WiFi code for a meeting room, a phone number on a service van: none of these benefit from being editable, and printing them as dynamic just adds a redirect step, and a dependency, to something that was already finished the moment it was designed. Build them as static in the QR code generator instead, and save the allowance, and the dependency, for placements where flexibility is actually worth paying for.
It also weakens the case for the dynamic codes you do need analytics on. If half your dynamic codes exist out of habit rather than need, the scan data you're reporting upward is diluted by placements nobody was ever going to measure meaningfully. Reserve dynamic for the placements in the right-hand column of the decision table above, and the analytics you do collect will say something.
The dependency you take on with dynamic
Choosing dynamic means choosing a standing dependency: on a domain staying registered and pointed correctly, on a company staying in business, and on that company continuing to run the redirect the way it did on the day you printed. That dependency is real regardless of which platform you use, and it's worth being honest about rather than treating as a footnote.
What differs between platforms is how much of that dependency is disclosed. A redirect domain that's openly named, a legal entity that's identifiable, and a published contact for problems don't remove the dependency — but they mean you know exactly what you're depending on, rather than trusting an anonymous shortlink and hoping. MyQRx's redirect domain, tilg.in, is disclosed rather than hidden behind a generic shortener, and the company behind it — SafeKT Technologies — is named, with a published grievance contact for exactly this kind of accountability question. None of that makes the dependency disappear. It makes it a dependency you can actually evaluate, which is the more honest starting point than a platform that doesn't tell you what you're relying on in the first place. Who owns your QR code goes through that due-diligence checklist in full, including the parts of it that are still a work in progress.
When static is the right call, not the cheap one
It's worth saying plainly: static is not the fallback option for people who can't justify a subscription. There are placements where static is the correct engineering choice regardless of budget — a WiFi network that will never be renamed, a vCard that must keep working with no possibility of a lapsed renewal, an offline payload that never touches a network at all, a permanent installation meant to outlast any vendor relationship you could sign today, including this one. When a static QR code is the right choice sets out six of these cases in full, and the trade-off each one accepts in exchange for zero dependency: no editing, no analytics, and no ability to disable the code if something ever does go wrong with the destination behind it.
What this means for your next campaign
Don't decide static-versus-dynamic once for the whole campaign. Decide it once per placement, using the four questions above, and expect the answer to come out differently for different pieces of the same print run. A product's warranty-card vCard is a static decision. The same product's shelf-talker pointing at a seasonal offer page is a dynamic one. Treat "static or dynamic" as a checkbox on your artwork brief, next to every individual code, not a policy decision made once at the top of the project.
Where you do go dynamic, plan for what you'll actually measure before the campaign starts, not after the first report is due — the metrics that matter should shape which placements get their own code, not the other way round.
Want the short version? The five rules for static or dynamic fit on one screen.
Before locking a print file with a dynamic code on it, see how dynamic codes actually work end to end.
Straight answers
Can I convert a static QR code into a dynamic one?
Not directly. A static code carries its destination inside the pattern, so there is nothing to redirect and nothing to repoint. The only route is to generate a new dynamic code and reprint — the original static code keeps working exactly as before, pointed at whatever it always pointed at.
Can I tell a static and a dynamic QR code apart just by looking at them?
No. Both scan as an ordinary black-and-white pattern to any camera. The only difference is what's encoded inside: a static code holds the destination directly, a dynamic one holds a short redirect that resolves elsewhere. You cannot tell which is which without scanning it.
Does choosing static get me more free codes?
Static codes are unlimited on every MyQRx plan, including Free Forever; only dynamic codes count against your allowance (five on Free Forever, more on paid tiers). So choosing static where it fits never costs you a slot, and it also removes an ongoing dependency.
Can I see scan data for a static QR code?
No. A static code has no redirect step for any server to log, so there is nothing generated to count in the first place. If measurement matters at all for a given placement, even a little, that alone is usually reason enough to use a dynamic code there instead.
Can I build a QR code before creating an account?
Yes. You can design and preview any code type, static or dynamic, before creating an account, and only need to sign up once you're ready to download the file — useful when you want design approval from someone else before anyone commits to a plan.
