The short answer
A dynamic QR code is a QR code whose printed pattern encodes a short redirect URL rather than the real destination. The short URL lives on a server you control, and that server holds a small table mapping the short slug (say r.yourdomain.com/abc) to the real destination. When someone scans the code, their phone opens the short URL, the server replies with a 301 redirect to the real destination, and the phone follows it automatically. Because the mapping lives on the server, you can change the destination later without reprinting the code — and because every scan passes through the server, you can count scans, set expiry, add a password, and route by device.
Our static vs dynamic QR guide covers the two-way choice in brief; this page is the deeper dive for the buyer who has decided they probably want dynamic and needs to understand the mechanism, the powers, the cost, and the single biggest risk (link rot if the provider disappears). Read it alongside the qr code redirect guide (which explains the redirect mechanic in isolation) and the qr code tracking and qr code analytics guides (which cover what the server logs as scans pass through).
What makes a QR code “dynamic”
The label “dynamic” refers entirely to what is printed in the QR pattern. A static code prints the real destination (the full menu URL, the WiFi payload, the vCard) directly into the grid — the data is self-contained and the phone reads it straight off the image. A dynamic code prints only a short redirect link, typically on the provider’s own short domain, and the real destination is stored server-side behind that link.
That one difference is the root of every power and every cost that follows. Because the destination is not in the image, it is not fixed by the image — so it can be edited, swapped, expired, gated, and measured. And because the destination is not in the image, the code depends on the server that holds the mapping staying alive, which is the source of the one serious risk (covered below). Our static vs dynamic QR guide frames the trade-off; this page unpacks the dynamic side of it.
How the redirect works
The redirect is a three-step dance that happens in roughly the time it takes the phone to load a page. First the camera decodes the printed pattern and the phone opens the short URL — say r.yourdomain.com/abc — exactly as if you had typed it. The browser issues a normal HTTP request to that URL. Second, the redirect server looks up the slug abc in its mapping table, finds the real destination you configured, and replies with a 301 (permanent) or 302 (temporary) redirect carrying the real destination in the Location header. Third, the phone’s browser follows that redirect automatically and loads the real destination — the scanner never sees the short URL on screen for more than a moment.
Nothing about the printed code ever changes; the entire editability lives in the server-side mapping table. That is why you can repoint a dynamic code the day after a ten-thousand-copy print run without reprinting a single sheet, and why the qr code redirect guide treats the redirect as the single mechanic that powers editability, analytics, and routing at once.
The powers a dynamic tier unlocks
Once a scan passes through a server you control, a handful of features become a matter of server logic rather than printed ink. The destination becomes editable — fix a typo or swap a seasonal landing page after the code is printed. Every scan is logged, which is the basis of qr code analytics: total scans, approximate location, device and OS, time of day, and repeat-scan rate. You can set an expiry by date or by scan count, so a campaign code stops working the day the event ends. You can gate the destination behind a password for exclusive or sensitive content. And you can route a single code to different destinations by device (iOS to the App Store, Android to Google Play) or split traffic A/B to compare two landing pages.
The table below maps each power to what it does and the situation that calls for it. None of these are possible with a static code because a static code has no server in the loop — the destination is fixed at the moment of generation.
| Power | What it does | When you need it |
|---|---|---|
| Editable destination | Change where the short link points without reprinting the code. | You may fix a typo, swap a seasonal page, or rebrand after printing. |
| Scan analytics | Count scans and record location, device, time of day, repeat rate. | You need to know whether the code is being seen and by whom. |
| Expiry (date / scan-count) | Disable the redirect after a date or after N scans. | A time-boxed campaign or a one-time-use ticket/check-in code. |
| Password gate | Require a password before the redirect is served. | Exclusive, member-only, or sensitive content behind the code. |
| Multi-URL routing | Send iOS and Android to different stores, or split A/B traffic. | App-install codes, or A/B tests comparing two landing pages. |
| Short printed URL | A short slug keeps the QR grid low-version and easy to scan. | Long destinations that would make a static code dense and hard to scan small. |
The cost — a server and the dynamic tier
A dynamic code is not free in the way a static code is free. The short redirect link has to resolve somewhere, which means a server (or a serverless function) has to stay online for the life of the printed code, and the mapping table has to be stored, backed up, and protected from abuse. That is real, ongoing compute and storage cost, and it is why dynamic codes are a paid tier rather than a free giveaway — an honest provider prices it as a flat subscription to cover the infrastructure and the abuse defense.
Beware of “free dynamic QR” offers. A provider that gives the redirect away is usually paying for it another way — gating scans behind a paywall after the fact, expiring codes to force an upgrade, or quietly injecting ads and trackers into the redirect. The honest model is a clearly priced dynamic tier with the redirect on a domain you control or can move; the qr code generator free guide covers how a free static tier and a paid dynamic tier fit together honestly.
The link-rot caveat — the one serious risk
The same server that gives a dynamic code its powers is also its 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 far 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. 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, and keep the printed short URL on infrastructure you can move. And keep a static fallback for any code whose destination truly will not change — the qr code redirect guide covers the redirect-as-dependency trade-off in detail.
When static beats dynamic
Dynamic is powerful, but it is not the right default for every code. A static code is the better choice whenever the destination will not change and you do not need scan counts: a WiFi sign, a business card vCard, a one-off event invitation, a permanently-printed product label, or any code that must keep working decades after the provider may be gone. Static codes are free, private (nothing is uploaded), and immortal — the printed pattern carries the data and the phone reads it directly, with no server that can expire, misconfigure, or be shut down.
The rule of thumb is to start static and step up to dynamic only when one of its powers is the actual lever — when you genuinely need to edit the destination later, count scans, set an expiry, gate with a password, or route by device. For a one-off permanent print with no tracking needed, the qr code tracking guide explains why a static code’s zero analytics is a feature, not a gap.
How QRForge delivers it
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. The planned paid dynamic tier replaces the static destination with a short redirect link on a server you control, which unlocks the editable destination, the scan analytics our qr code analytics guide catalogs, expiry by date or scan count, optional password gating, and multi-URL routing by device or A/B split — all powered by the single redirect mechanic covered in the qr code redirect guide.
Because those features all flow from one server you can move, the dynamic tier is designed against the link-rot risk: the redirect lives on infrastructure you control 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 that decision, and the qr code tracking guide covers what the dynamic tier can and cannot tell you.
Frequently asked questions
What is a dynamic QR code?
A dynamic QR code is a QR code whose printed pattern encodes a short redirect URL rather than the real destination. The real destination is stored on a server behind that short link. When someone scans the code, their phone opens the short URL, the server replies with a 301 redirect to the real destination, and the phone follows it automatically. Because the mapping lives on the server, the destination can be edited later without reprinting, and every scan can be counted.
How do dynamic QR codes work?
In three steps. The camera decodes the printed short URL and the phone opens it. The redirect server looks up the short slug in its mapping table, finds the real destination you configured, and replies with a 301 or 302 redirect. The phone’s browser follows the redirect automatically and loads the real destination. The printed code never changes; all the editability lives in the server-side mapping table.
Dynamic vs static QR code — which should I use?
Use a static code when the destination will not change and you do not need scan counts (a WiFi sign, a business card, a permanent label). Use a dynamic code when you need to edit the destination after printing, count scans, set an expiry, gate with a password, or route by device. Static is free, private, and immortal; dynamic adds powers but depends on a server staying online and usually costs money.
Can a dynamic QR code stop working?
Yes — that is the one serious risk. A dynamic code depends on the redirect server and the short domain staying alive. If the provider shuts down, the subscription lapses, the short domain is sold, or the account is closed, every printed dynamic code pointing at that domain stops working at once. Point dynamic codes at a domain you own so you can repoint the DNS if the provider disappears, and keep a static code for any destination that truly will not change.