What each actually is
A static QR code is a direct encoding of the target. Scanning decodes the exact bytes that were printed. If the target is https://example.com/promo, the printed pattern literally encodes those characters. There is no server involved; it works offline; it works forever.
A dynamic QR code encodes a short link on a provider domain — for example qrforge.meta-mind-lab.com/q/abc123. When a scanner opens that link, the provider's redirector looks up the current destination and sends the scanner there. The destination is stored on the server and can be changed anytime without touching the printed code.
The trade-off in one line
Static trades flexibility for independence. Dynamic trades independence for flexibility. Neither is strictly better — they solve different problems.
Static is free, works when our servers are down, and keeps working in ten years whether or not we still exist. The downside is that once the code is printed, the destination is frozen. Reprint or nothing.
Dynamic is editable, measurable, and pauseable. The downside is that it depends on our redirector staying online and on you keeping the account active.
When to use static
- Personal use — One-off Wi-Fi QR at home, vCard on a business card, link to a blog post you control — the destination is stable and you don't need analytics.
- Offline payloads — Wi-Fi credentials, vCards, plain text, calendar events — these encode the data directly with no URL in the middle, so dynamic adds nothing.
- Regulated or archival contexts — A QR on a government form, a museum placard, or a published book should keep working without depending on a third-party service.
- Very short-lived printing — A handwritten flyer at a meetup you are hosting tonight. Dynamic is overkill for a piece of paper that goes in the recycling tomorrow.
When to use dynamic
- Anything you'll print in quantity — Menus, packaging, signage, posters, business cards for a whole sales team. The moment you print more than 50 copies, dynamic pays back the first time you need to update anything.
- Campaigns with a start and end date — A holiday promo, a product launch, a seasonal menu. When the campaign ends, you redirect the QR to a follow-up page instead of leaving customers at a 404.
- Anything you want to measure — Dynamic codes log every scan — device, browser, country, timestamp. Static codes have no server in the loop so there is nothing to measure except what lands in your destination's web analytics.
- A/B testing destinations — Same printed code, different landing pages in different weeks. You cannot do this with static — the printed pattern is fixed.
- Per-channel attribution — A dedicated dynamic code per magazine, billboard, or postcard lets you compare channels by scan count without needing UTM parameters printed on the creative.
The cost question
Static codes are free on every QR generator that is worth using. No account, no watermark, no limits. That part is genuinely free forever.
Dynamic codes cost money somewhere. Either you pay a subscription to a provider that keeps the redirector running, or you self-host the redirector yourself. A free tier exists (QRForge includes one dynamic code free), but you cannot credibly offer unlimited free dynamic QR codes because the redirector has ongoing hosting and support costs.
The practical math: if you're going to print even a few hundred copies of a single design, the cost of a dynamic subscription is less than the cost of one reprint. Dynamic pays for itself the first time you need to change the URL.
What about scan tracking on static codes?
You can track scans on static codes in a limited way. Put a URL with UTM parameters in the code and your destination's web analytics (GA4, Plausible, Mixpanel, Fathom) will record the hit. That gives you per-code totals and destination-page behavior.
What UTM-on-static does not give you: country, device type, or browser at the scan level. Those come from the destination-page context, not the scan itself, and you lose anyone who scans and bounces before analytics loads. Dynamic codes log the scan before the redirect, so you capture bounces and mis-scans that web analytics never sees.
Common mistakes
- Using static for anything campaign-driven — The moment the campaign shifts, the printed code is useless. Reprinting is the expensive path; dynamic would have cost a fraction.
- Using dynamic for Wi-Fi or vCard — Dynamic only makes sense for URLs. Wi-Fi and vCard payloads are self-contained; there is nothing to redirect. Using a dynamic URL that redirects to a Wi-Fi page is worse — it requires an internet connection to join a network, which defeats the point.
- Picking the wrong provider — If the provider shuts down, every dynamic code you printed becomes dead. Use a provider with an exit story (data export, self-hostable alternatives) or self-host the redirector on a domain you own.
- Over-optimizing for dynamic on single-use codes — A dinner-party invite that will never be reused does not need analytics. Static is fine; stop over-engineering.
A simple decision rule
Ask two questions. Will I print this more than 50 times? Will the destination ever plausibly change? If either answer is yes, go dynamic. If both are no, static is fine.
If you're still unsure, default to dynamic. The worst case is a wasted subscription for a few months; the worst case for static is a scrapped print run.