The short answer
A static QR code bakes the destination directly into the printed pattern and a dynamic QR code prints a short redirect link whose real destination lives on a server. That one structural difference cascades into every other difference: static is free, private, immortal, and permanent; dynamic is editable, trackable, expirable, gateable, and routable — but paid and server-dependent. Our earlier static vs dynamic QR guide gives the brief version; this is the comprehensive side-by-side for the buyer at the decision point who needs the whole picture before choosing which QR type to use.
The rule of thumb is simple: start static, step up to dynamic only when one of its powers (editability, analytics, expiry, password gating, multi-URL routing) is the actual lever. The rest of this page lays out the feature-by-feature comparison, when each side wins, the total-cost difference, and the one serious risk (link rot) that decides the dynamic question on its own.
The side-by-side feature comparison
The table below compares the two QR types across the dimensions that actually decide the choice. Read it column by column: cost is the headline, editability and trackability are the dynamic powers, expiry and scan speed and capacity set the practical limits, and privacy separates a self-contained print from a server-mediated one.
Two notes on how to read it. "Scan speed" compares the scan-to-action time, not the decode time — a static code decodes and acts in one step, a dynamic code adds a 301 redirect hop after the decode. "Capacity" compares the effective capacity after each type spends its budget: a static code spends its grid on the full payload, a dynamic code spends its grid on a short slug and pushes the real payload to a server, so a dynamic code can effectively point at an arbitrarily long destination for the price of a short printed URL.
| Feature | Static QR code | Dynamic QR code |
|---|---|---|
| Cost | Free forever — generated in-browser, no server, no subscription. | Paid subscription — the redirect server is ongoing compute + storage + abuse defense. |
| Editable destination | No — the destination is baked into the pattern; change it and you reprint. | Yes — repoint the server-side mapping without reprinting a single copy. |
| Scan analytics | None — the phone reads the image directly, no server to count. | Yes — total scans, location, device/OS, time of day, repeat rate. |
| Expiry | Never expires — no clock, no server, the data is in the ink. | Can expire by date or scan count — the server can stop redirecting on a schedule. |
| Scan speed | One step — decode and act (open the URL, join WiFi, save the contact). | Two steps — decode, then a 301 redirect hop before the destination loads. |
| Effective capacity | Bounded by the grid (~2,953 bytes at level L); long payloads make dense grids. | Effectively unbounded for the destination — only a short slug is printed, the real URL lives server-side. |
| Privacy | Self-contained — nothing is uploaded, nothing is logged, no middleman. | Server-mediated — every scan passes through the redirect and is logged; pick a privacy-respecting provider. |
| Best use case | Permanent, one-off, no-tracking prints: WiFi, vCard, event, product label. | Campaigns, menus, analytics, A/B tests, anything that may change after printing. |
When static wins
A static code is the right default whenever the destination will not change and you do not need to count scans. That covers a wide band of real-world QR uses: a guest WiFi sign on the wall (the SSID and password are fixed, and the code must keep working for years with no server to maintain), a vCard on a business card (your contact details do not move after the cards are printed), a one-off event invitation that adds the date to the scanner’s calendar (a VEVENT payload is self-contained and needs no internet at all), and a permanently-printed product label whose link must keep resolving decades after the printer who made it may be gone.
In each of these the defining property is the same: the destination is fixed at generation time and you want the code to keep working with zero ongoing dependency. Static codes are free, private (nothing is uploaded to a server), and immortal — the printed pattern carries the data and the phone reads it directly, with no server that can expire, misconfigure, be sold, or be shut down. When those properties matter more than editability or measurement, static is not a compromise — it is the right answer.
When dynamic wins
A dynamic code earns its paid subscription the moment one of its server-side powers becomes the actual lever. Restaurant menus are the canonical case: a table tent printed once should be repointable to a lunch menu, a dinner menu, or a corrected PDF without reprinting thousands of tents — the editable destination alone pays for the tier. Marketing campaigns need the analytics stack (total scans, location, device, time of day) to know whether the code is being seen at all, and they need A/B routing to compare two landing pages from a single printed surface. App-install codes need multi-URL routing by device (iOS to the App Store, Android to Google Play) from one code. Any time-boxed promotion needs expiry so a campaign code stops redirecting the day the event ends.
The common thread is that the destination may change, or you need to measure or control the flow after printing. A dynamic code puts a server in the loop, and that server is what makes editability, analytics, expiry, password gating, and routing possible at all — none of which a static code can do because a static code has no server in the loop. When any one of those is the lever that moves the result, the dynamic tier pays for itself on the first reprint it saves.
The total-cost comparison
The cost difference is not just "static is free, dynamic is paid" — it is the shape of the cost over the life of the code. A static code is free forever: you generate it once, print it once, and pay nothing for the rest of its life, however long that is. A dynamic code is a recurring subscription for as long as you want the codes to keep working: pay every month or the redirect goes dark and every printed copy stops resolving at once. Over a five-year print run a static code costs the same as a one-day print; a dynamic code costs five years of subscription.
The honest comparison is therefore not "which is cheaper" but "which cost shape matches the use case". For a permanent, fixed-destination print the answer is static — free forever, no recurring bill, no dependency. For a campaign or a menu that genuinely needs the dynamic powers, the subscription is the price of those powers, and the question becomes whether the powers are worth the ongoing cost (and whether you own the short domain so the codes survive the provider — see the link-rot caveat below). For a one-off with no tracking need, paying a recurring subscription for a code that could have been static is wasted spend.
The link-rot caveat
The one serious risk that decides the dynamic question on its own is link rot. A dynamic code’s redirect server is a single point of failure: if the provider shuts down, your subscription lapses, the short domain is sold, or the account is closed, every printed dynamic code pointing at that short domain stops working at once — not one destination going stale, but the entire code going dead on every printed copy simultaneously. That is a categorically worse failure mode than a static code going stale one destination at a time, and it is the reason our do QR codes expire guide draws the line so sharply: a static code never expires, a dynamic code can.
The practical defenses are simple and they shape the dynamic buying decision. Point dynamic codes at a short domain you own rather than the provider’s branded domain, so you can repoint the DNS if the provider disappears. Choose a provider with a credible longevity story. Keep the printed short URL on infrastructure you can move. And keep a static fallback for any code whose destination truly will not change. If those defenses are not possible — you cannot own the short domain, the provider is unproven — then a static code is the safer default even at the cost of giving up the dynamic powers. Our dynamic QR code deep dive covers the link-rot risk from the dynamic side; this page frames it as the single factor that can overrule every other argument for going dynamic.
How QRForge delivers both
QRForge’s free generator ships static codes by default, and that is the deliberate right default for the majority of prints — free, private, immortal, no server to expire, no subscription to lapse. Every content type (URL, text, WiFi, vCard, SMS, email, event) is generated in-browser with full styling (colors, gradients, per-eye and per-module shapes, centered logo, frames), vector SVG / EPS / PNG export, and batch CSV — all on the free static tier, all self-contained, all immortal.
The planned paid dynamic tier is for the case where this page’s comparison pointed you to dynamic: it replaces the static destination with a short redirect link on a server you control, unlocking the editable destination, the scan analytics, expiry by date or scan count, optional password gating, and multi-URL routing — all from the single redirect mechanic. It is designed against the link-rot risk: the redirect lives on infrastructure you can move rather than a throwaway branded short domain. Start with a free static code to prove the placement, the scan distance, and the styling; step up to the dynamic tier only when editability, analytics, expiry, or routing is the lever that moves the result. Our static vs dynamic QR guide frames the brief version and the dynamic QR code deep dive unpacks the dynamic side; this page is the comprehensive comparison that ties them together.
Frequently asked questions
What is the difference between a static and a dynamic QR code?
A static QR code encodes the destination directly into the printed pattern — free, private, immortal, but the destination cannot change without reprinting. A dynamic QR code prints a short redirect link whose real destination lives on a server — editable, trackable, expirable, but paid and server-dependent. The structural difference (data in the ink vs data on a server) is the root of every other difference.
Which QR type should I use?
Start static. Step up to dynamic only when one of its powers is the actual lever: you need to edit the destination after printing, count scans, set an expiry, gate with a password, or route by device. For a permanent, fixed-destination, no-tracking print (WiFi sign, business card vCard, event invite, product label) static is the right answer, not a compromise. For a campaign, menu, or anything that may change or needs analytics, dynamic earns its subscription.
Are dynamic QR codes free?
Honest dynamic codes are a paid subscription because the redirect server has real ongoing compute, storage, and abuse-defense cost. Beware of "free dynamic QR" offers — they usually pay for it another way: gating scans behind a paywall after the fact, expiring codes to force an upgrade, or injecting ads and trackers into the redirect. A free static tier plus a clearly priced dynamic tier is the honest model.
Can a dynamic QR code stop working?
Yes — that is the link-rot risk. If the provider shuts down, your subscription lapses, the short domain is sold, or the account is closed, every printed dynamic code stops resolving at once, on every copy simultaneously. A static code never expires; a dynamic code can. The defenses are to point dynamic codes at a short domain you own, choose a provider with longevity, and keep a static fallback for anything that must last.