What is a dynamic QR code? Plain-English answer

A dynamic QR code is a QR code that encodes a short URL pointing at a server you control, and the server decides where each scan ends up. The printed pattern never changes. The destination behind the URL does — you edit it in a dashboard, every printed code starts sending people to the new place on the next scan. That single property is what separates dynamic from the older static QR codes that bake the destination directly into the printed pixels and can never be repointed.

People ask "what is a dynamic QR code" because they've usually been burned at least once. A flyer goes out with a URL that's now wrong, a menu PDF moves to a new host, a vCard QR is printed onto 500 business cards two weeks before a phone number changes. Static QR codes don't forgive any of that. Dynamic QR codes are how the same printed code keeps working when reality moves underneath it. The trade-off is real — there's a server in the loop, which means a vendor in the loop, which means a dependency — but for almost every commercial QR job, dynamic is the only sane default.

This post is the plain-English definition. What "dynamic" actually means, the redirect step that does the work, what changes versus a static QR in operational terms, the analytics and editability and A/B switching it unlocks, the cost of static codes that look free but aren't, when static is still the right call, and the honest list of things you give up to get the flexibility. If you want the side-by-side comparison with a decision matrix, the deep static-vs-dynamic comparison covers that in more detail. If you want the technical baseline on what's inside any QR code first, the foundational what is a QR code explainer is the prerequisite this post assumes.

A dynamic QR code is a short link wearing a QR coat#

The thing photographed by a phone camera is a grid of black and white modules. Every QR code, static or dynamic, is exactly that — the format is defined by ISO/IEC 18004 and the decoder doesn't know or care whether the bytes it decodes encode a long URL, a short URL, a vCard, a WiFi credential, or "Hello world". A QR is bytes printed as pixels. The "dynamic" part lives in what those bytes happen to spell.

A static QR encodes the actual destination. Print one for https://yourbrand.com/spring-campaign-2026?utm_source=poster&utm_medium=print&utm_campaign=spring, and those 95 characters are physically baked into the printed grid. Decoding gives the phone those 95 characters, and the phone opens that URL. Done. No server hop. No edit afterward.

A dynamic QR encodes a short URL. Something like lnks.work/k/spring. The printed pattern stores those 19 characters. When a phone decodes them, the phone makes an HTTP request to that short URL, the server looks up what spring maps to right now, and responds with a 302 redirect to the actual destination — which could be the same long URL you would have encoded statically, or a different one, or a different one tomorrow. Render the same destination as a static long URL and as a short-link-backed dynamic in the public QR designer — the module count drops visibly, and the second one stays editable after you've left this page.

That redirect hop is the whole story. It costs about 80–120 milliseconds on a healthy host — invisible to the user, who experiences it as "the page loaded" the same way it would after any other tap. But for the operator, that hop is the seam where a hundred useful things become possible.

What changes when the destination is editable#

Edit-after-print is the headline feature. Print a thousand restaurant flyers in March pointing at lnks.work/k/menu. The short link goes to your spring menu PDF. In June you swap to the summer menu — log in, paste the new PDF URL, save. Every flyer still in someone's drawer, every poster still on a noticeboard, every business card someone slipped into their wallet now sends people to the summer menu. Zero reprint cost, zero communication required.

That same edit handles the everyday breakages too. A PDF gets re-uploaded to a new path. A landing page gets moved from /spring to /lp/spring. The marketing team renames the campaign. Without dynamic, every one of those is a reprint or a dead scan; with dynamic, every one of those is thirty seconds in a dashboard.

Analytics is the second big change. Because every scan transits through your server, every scan can be logged. Timestamp, country (from IP geolocation), device type, referrer if there is one. You move from "we printed 500 flyers and hope it worked" to "the flyer drop on Saturday delivered 84 scans, 71% Android, 62% in the first six hours, 9% of scanners hit the booking page." That's not vanity — it's the difference between guessing whether a printed campaign earned its cost and knowing.

A/B switching is the third. Because the redirect is server-side logic, you can split traffic. Send 50% of scanners to landing-page-A and 50% to landing-page-B for two weeks, look at which one converted better, kill the loser. The QR code on the printed material doesn't move; only the rule behind it does. Some platforms also support geo-routing (US scans go to the dollar pricing page, EU scans go to the euro pricing page) and device-routing (iOS goes to App Store, Android goes to Play Store) from the same printed code.

Expiry is the fourth and most underrated. A campaign code printed in March can be set to redirect to a "this campaign has ended, see what's running now" page automatically on June 1. Without dynamic, the expired campaign becomes a dead link forever; with dynamic, the same print can do graceful degradation.

A static QR code locks one decision into the print. A dynamic QR code locks zero decisions — the printed pattern is just a stable doorway, and what's behind the door is yours to rearrange.

The operational cost of static codes that look free but aren't#

Static QR codes are pitched as free, and the generation itself is free. The hidden cost shows up later, in two forms.

The first is the reprint tax. Anytime the destination needs to move — and over a multi-year campaign it almost always does — every printed surface needs to be regenerated, reprinted, redistributed, and the old material recalled or accepted as wrong. For a stack of 500 takeaway menus this is a couple of hours and a printer invoice. For a packaging refresh that touches a million units it's a six-figure number. The static QR's "free" sticker price is always inverted by the first time you need to change anything.

The second is the data tax. With static, every scan is invisible. You don't know whether the flyer worked, whether the conference table got attention, whether the packaging QR moved any traffic at all. That invisibility makes the next campaign decision worse — you re-spend on something that might have been a flop or might have been a hit, with no signal either way. The dynamic equivalent gives you the answer for free as a side effect of the redirect.

There's a third quieter cost — the security one. A static QR can't be revoked. If someone prints stickers of malicious QRs and slaps them over yours, you can't repoint your code to neutralise the attack. A dynamic code can — flip the redirect to a warning page, or pause the link entirely, and the only QRs that resolve are the legitimate ones. We covered the broader pattern in our QR code security and quishing writeup, but the short version is that dynamic gives you a kill switch static physically can't have.

The size and design advantage nobody mentions#

There's a fourth reason dynamic wins that has nothing to do with editability — the printed pattern is smaller and cleaner.

A QR code's printed density scales with how much data it encodes. A 95-character URL with UTM parameters produces a version 7 to 10 code, somewhere around 45×45 to 57×57 modules. A 19-character short URL like lnks.work/k/spring fits in version 2 or 3 — 25×25 modules at most. The visual difference is dramatic. Sparse codes round beautifully, accept logos better, scan from further away, survive smaller print sizes, and look less like a digital cockroach on a poster.

If you've ever wondered why some QRs look elegant and some look like static, the answer is almost always payload length. Dynamic codes are short because short URLs are short; static codes with full URLs are long because full URLs are long. For visual design, this isn't a small thing. The round QR shape rules basically only work on sparse grids, which is another reason marketing-grade design almost always starts with a dynamic code under the hood.

A dynamic-vs-static decision picker#

Plug in your scenario. The widget tells you whether dynamic clearly wins, whether static is fine, or whether you're in a borderline case where the answer depends on what you optimise for.

The picker doesn't pretend the answer is always dynamic. There's a real corner — low volume, permanent destination, zero budget, no analytics need — where static is genuinely the right call. Outside that corner, the math goes one way.

When static is still the right call#

Three honest cases where static wins.

The first is truly permanent payloads on truly permanent media. A QR code etched into a stainless steel plaque outside a museum, pointing at the museum's homepage, for the next thirty years. Dynamic adds a server dependency that's shorter-lived than the plaque. Burn the URL into the etching and accept that you can't repoint it.

The second is structured non-URL payloads in offline-acceptable contexts. A WiFi QR on a coffee shop wall that almost never rotates passwords. A vCard on the back of a business card for someone who never changes employers. A SEPA payment QR on a paper invoice. The static version is fully offline-capable — the scan works with no signal — and the payload is short enough that the size advantage of dynamic doesn't matter. For these, static is operationally simpler. We've argued elsewhere that every QR type should be dynamic by default for non-trivial use, but if you're genuinely in the offline-permanent corner, static is correct.

The third is privacy-by-design contexts. A dynamic QR generates a scan log; a static QR doesn't. For medical instructions printed inside a product, internal-only documentation, or any context where "we know someone photographed this code at 14:32 from this IP" is itself a problem, the absence of a server in the loop is a feature, not a bug. The trade-off is that you also can't revoke the code if something goes wrong.

Outside those three corners — flyers, posters, packaging, restaurant tables, business cards linking to websites, conference badges, retail tags, billboards, anywhere you're paying to print something and might want to know if it worked — dynamic is the default. Not because dynamic is technically superior in every dimension, but because the editability and observability you get are almost always worth more than the server dependency they cost.

What you give up to get dynamic#

Two real trade-offs. Both manageable, neither zero.

Network dependency at scan time. A dynamic QR needs a server response. If the phone has no signal, the scan returns an error. For consumer scenarios — a coffee shop, a conference, a poster in a city — this is almost never an issue. For underground transit posters, rural billboards, or any scan environment where signal is unreliable, static is the safer default for the actual destination URL. The QR pattern itself decodes offline either way; it's the resolution step that needs the network.

Vendor and platform dependency. Your dynamic QRs depend on the platform hosting the redirect. If that platform shuts down, sells to someone who turns the redirect off, or starts charging dramatically more, your printed codes break or get held hostage. The mitigation is choosing a platform that lets you use your own domain — the way the QR code domain matters deep-dive lays out — so a code printed as yourbrand.com/q/spring keeps working even if you migrate platforms, because you control the domain. The same principle applies to custom domains for QR codes on the setup side. Pair that with the broader case for owning your link infrastructure and the vendor-risk part of dynamic shrinks to something manageable.

For posts that go deeper than this overview, the side-by-side static vs dynamic comparison covers the use-case-by-use-case decision matrix, and the dynamic-by-default argument extends the case from URLs to vCard, WiFi, calendar, and email. For specifically dynamic vCard and dynamic WiFi, the dynamic vCard writeup and the dynamic WiFi writeup cover the format-specific details. The QR codes documentation covers the platform side — how a dynamic code is generated, edited, and tracked in practice.

The shorthand that helps#

If a sentence helps it lock in: a static QR encodes a destination; a dynamic QR encodes a doorway to a destination. The destination behind the doorway is yours to rearrange whenever you want, and every printed copy of the doorway keeps working the whole time. That single property is what every "dynamic vs static" decision comes back to.

If the destination is the kind of thing that could ever change — a campaign URL, a menu, a booking page, a phone number, a WiFi password, a calendar event date, an employer's website — print a dynamic code. If the destination is the kind of thing that genuinely never changes — a museum's homepage etched on a plaque, your home WiFi password on a fridge magnet, a SEPA payment QR on a paper invoice — static is correct.

Everything else, default to dynamic. The cost is small, the upside is large, and the "I wish I'd printed it dynamic" regret shows up far more often than the "I wish I'd printed it static" one.