Dynamic QR codes: editable after printing, with scan analytics

A static code has its data baked in forever. A dynamic code points to a short redirect URL you control — so you can change where a printed code goes, and see exactly how it performs in the real world.

Static vs. dynamic, in one table

	Static code	Dynamic code
What’s encoded	Your URL, literally	A short redirect URL
Editable after printing	No — ever	Yes — anytime
Scan analytics	None possible	Time, device, browser, OS, location
Works offline / forever	Yes, unconditionally	Needs the redirect service reachable
Code density	Grows with URL length	Always small — short URL
Cost here	Free, unlimited	Paid plans, from $3/mo billed yearly

Neither is “better” — they solve different problems. A wedding-invite code that will be scanned for one month: static. Ten thousand product boxes with a two-year retail life: dynamic, without question.

How the redirect actually works

Instead of encoding your destination, a dynamic code encodes a short tracking link (bulkqrtool.com/api/q/…). A scan requests that link; the server logs the scan’s metadata, looks up your current destination, and answers with an instant redirect. The hop adds tens of milliseconds — imperceptible next to the destination page’s own load time. Because the printed pattern only ever contains the short link, two useful properties fall out: the code’s density never depends on how long your destination URL is (a 300-character UTM-tagged monster produces the same clean, coarse pattern as a short link), and the destination can change as many times as you like without the ink changing at all.

What editability is worth in practice

Fixing mistakes after the print run. The wrong-URL-on-10,000-flyers story ends with a 30-second destination edit instead of a reprint invoice.
Outliving your links. Menus move from /menu.pdf to /menu, sites get rebuilt, marketing pages expire. Printed dynamic codes survive every migration.
Campaign rotation. The same table tent points at the brunch page on weekends and the dinner menu at night — or January’s promo, then February’s — with zero reprinting.
Retiring gracefully. When a campaign ends, point the code at your homepage instead of letting it 404 in the wild.

Reading the analytics

Every scan through a dynamic code records a timestamp, device type, browser, operating system, and approximate location (country and city, derived from the request — no GPS involved). The dashboard turns that into scans-over-time, top-device and top-location breakdowns, and a recent-scan log. How to actually use it:

Scans over time tells you when your audience engages — a restaurant sees the dinner spike; a conference poster sees the coffee-break spikes. Schedule destination changes around real usage.
Device mix is a design input: 95% phones means your destination page had better be flawless on mobile before it is anything else.
Location breakdown validates distribution — if the flyers went to three cities and scans come from one, you have learned something about the other two.
Placement A/B testing: create two dynamic codes pointing at the same destination, put one on the counter and one in the window, and let the per-code counts tell you which placement earns its space.

Privacy of the people scanning: metadata only, no names, no accounts, no cross-site tracking. Details in the privacy policy.

Setting one up

Sign in with Google in the generator (the free generator itself needs no account; dynamic codes do, since they live on a server).
Create a URL code, flip on Analytics & Tracking, and save it to your collection with a recognizable name.
Download the code from My Collection — that version encodes the tracking link. This is the step people miss: the plain generator preview encodes your raw URL and tracks nothing.
Edit the destination or open analytics from the same collection row, whenever you need to.

Honest limitations

The redirect must stay reachable. Printed dynamic codes depend on the service being up and your plan active — that is the structural trade of every dynamic-QR provider. Your destination list is always visible in your collection, so you are never locked out of knowing where your own codes point.
If a subscription lapses, static codes are untouched (they never involved a server), while dynamic redirects pause until reactivation. For once-in-a-lifetime print pieces you cannot re-issue, static is the conservative choice.
Scan counts measure redirects, not humans — the same person scanning twice counts twice. Treat trends as the signal, not absolute uniqueness.

Plans

Static codes: free forever, unlimited. Dynamic codes and analytics start on the Personal plan — $3/mo billed yearly ($36/yr) or $6 month-to-month — with 2 dynamic codes and 500 tracked scans a month. Past that quota the codes keep redirecting perfectly; only the analytics pause until the month rolls over. Pro ($15/mo billed yearly) raises that to 250 dynamic codes, unlimited tracked scans, and 500-code bulk batches. Both include a 7-day free trial, and the pricing modal in the generator always reflects the current numbers.

Migrating existing printed codes toward dynamic

Plenty of teams arrive here with static codes already in the wild and wonder what can be salvaged. The honest inventory: printed static codes cannot be converted — their destination is in the ink — but the destinations they point at are still yours. If an old code points at a page on your domain, you can keep that specific URL alive as a permanent redirect on your own site, which rescues the deployed print without any QR-level change. Going forward, the cleaner policy is to make dynamic the default for anything that will be printed, and reserve static for screens (where regenerating is free) and for the never-changes category. Migration is also the right moment to build the habit that makes dynamic codes manageable at scale: name every code for its physical placement when you create it, because a collection of codes named after where the ink actually lives — not what campaign it ran — is what lets you confidently repoint the right one two years later.

Anatomy of a scan, millisecond by millisecond

Walking through one scan makes the architecture obvious. The camera decodes the pattern locally and finds a short URL — that part is identical to any static code and involves no network at all. The phone then requests the short URL; the server receives that request along with the standard metadata every web request carries (user-agent string, from which device/browser/OS are derived, and the network’s approximate location), writes one analytics row, looks up the destination currently assigned to that code, and responds with an HTTP redirect. The browser follows it, and the visitor is on your page. Total added time is one round trip — typically 30–80 ms — which is why nobody perceives the hop. Two things this design deliberately does not do: it does not run scripts on the visitor’s device (there is no page in between, just a redirect header), and it does not set cookies or fingerprint the visitor — the analytics row is the request metadata and nothing more. When you later edit the destination, you are changing a single database field; the next scan reads the new value, which is why edits are instant and reprint-free.

Deciding static vs. dynamic: a checklist

Run each printed piece through four questions:

Can the destination change during the print’s life? Menus, campaigns, packaging: yes → dynamic. A wedding website that dies in October on invitations that die in October: static is fine.
Do you need to know if anyone scans it? If the answer affects a decision — placement, spend, reprints — that alone justifies dynamic; a static code is a black box forever.
How expensive is being wrong? Reprinting ten table tents is a nuisance; reprinting 50,000 boxes is a budget line. The bigger the run, the stronger the dynamic argument as insurance.
Must it work with zero dependencies, forever? Memorial plaques, safety instructions, archival material: static, pointed at the most durable URL you control.

Most real projects sort themselves in seconds against these four. When a project mixes both — say, packaging with a dynamic support code and a static regulatory URL — that mix is correct, not indecisive; the two codes are doing different jobs.

Common questions

Do dynamic codes expire?: They redirect for as long as your plan is active. The printed image itself never degrades — reactivate the plan and the same code works again.
Can I convert a static code to dynamic?: No — the ink already says what it says. This is exactly why the static/dynamic decision belongs before the print run, not after.
How fast is the redirect?: Typically imperceptible — a single HTTP redirect measured in tens of milliseconds, dwarfed by the destination page’s own load.
Does editing the destination change how the code looks?: Never. The pattern encodes the short link, which is permanent; only the server-side pointer changes.
Can a dynamic code point to a PDF? A video? A form?: Anything with a URL — the redirect does not care what is on the other end.
What do the people scanning see?: Just your destination, after an instant redirect. No interstitial page, no branding of ours, no cookie banner from us.

Create a dynamic QR code →