How Dynamic QR Codes Actually Work: A Plain-English Explainer for Non-Tech Marketers
A clear, no-jargon explanation of how dynamic QR codes work under the hood — what the printed dots actually encode, what happens on a phone when someone scans, why the destination can change, and what your data tells the QR provider. Useful for anyone explaining QR codes to a CMO or a client.
If you've ever had to explain dynamic QR codes to a non-technical CMO, a print vendor, or a client, you've probably resorted to hand-waving — "they're just smart QRs." That's fine until someone asks: "But how can the dots on paper change?" This guide is the answer you can send them. No jargon, no marketing fluff — just the truthful mechanics of what dots on a page do, what happens in 280 milliseconds when a customer scans, and exactly what the QR provider can and cannot see.
What the printed dots actually encode
Every QR code (static or dynamic) is the same kind of object: a 2D matrix of black and white squares that encodes a small piece of text. That text could be:
- A URL like `https://google.com`
- A short URL like `createqr.in/d/abc12`
- A UPI string like `upi://pay?pa=you@okbank&am=100`
- A WiFi block like `WIFI:T:WPA;S:HomeNet;P:secret123;;`
- A vCard block with contact details
- Plain text up to ~2,953 alphanumeric characters
Static QR = the actual data
A static QR encodes the *real* data. A static UPI QR has your VPA literally inside the dots. A static URL QR has the full URL inside the dots. There is no server in the middle — your phone reads the data and acts on it directly.
This is why static QRs cannot be edited: changing the destination would require changing the dots, which means reprinting the QR.
Dynamic QR = a short URL pointing at a redirect server
A dynamic QR encodes a *short URL* like `createqr.in/d/abc12`. The actual destination lives in a database on the QR provider's server. When you scan:
- 1. Your phone's camera decodes the dots → gets the short URL
- 2. Your default browser opens the short URL → an HTTP request to createqr.in
- 3. createqr.in looks up `abc12` in the database → finds the current destination URL
- 4. createqr.in responds with HTTP 302 (temporary redirect) → your browser follows it
- 5. Your browser opens the real destination → you see the page
- 6. The whole sequence typically takes 60-200 milliseconds — invisible to the user
Why the destination can change
Because the destination lives in a database (not in the dots), you can change it by updating the database entry. The next time anyone scans the QR, step 3 above returns the new destination. Same dots, new destination, instant.
This is identical to how bit.ly, t.co, lnkd.in or any URL shortener works — dynamic QRs are just URL shorteners with a printed front-end.
What the QR provider can see (and what it can't)
Because the redirect passes through the provider's server, the provider can log a few things about each scan. On Create QR specifically, we log:
- Scan time (server timestamp)
- Approximate location (country + city, derived from IP — never GPS)
- Device type (mobile / tablet / desktop)
- OS family + browser family (from the User-Agent header)
- Browser language preference (Accept-Language header)
- Referer header when present (most scans show no referer)
What is NEVER logged
A few things are explicitly outside what dynamic-QR providers can see:
- Phone number, email, name, or any personal identifier — we don't receive these
- GPS location — we only see the IP, which gives a city-level approximation
- What the user does on the destination page (that's the destination's analytics, not ours)
- Identity across QRs — a user scanning two of your QRs is two anonymous events to us
- Anything before the scan or after the user leaves the destination
Performance: does the redirect slow things down?
Practically no. Create QR's redirect server runs on a global edge network (Cloudflare Workers). A scan from anywhere in India typically gets the redirect response in 30-80 ms, well under the 200 ms threshold a user perceives as "instant". For comparison, a typical mobile page load is 1,500-3,000 ms — the redirect is invisible noise inside that.
In one specific case, dynamic is actually faster than static: when the static QR encodes a very long URL (200+ characters), the QR has so many tiny modules that older phones struggle to scan it. A dynamic QR encodes only 30-40 characters, has bigger modules, and scans at a longer distance. For hoardings and packaging, dynamic almost always scans more reliably.
What happens if the QR provider goes down?
Honest answer: scans temporarily fail. This is the trade-off with any URL-shortener-style product. Mitigations on Create QR:
- Multi-region active-active hosting (Cloudflare Workers in 300+ cities)
- 99.99% historical uptime
- Daily backup of all destinations — restorable in minutes
- You can always export your destinations and migrate to another provider or self-host
- For mission-critical use (e.g. medical equipment QRs), pair a dynamic QR with a printed fallback URL underneath
Dynamic QR codes are not magic — they're a printed short URL whose destination is editable in a database. That single mechanical fact unlocks everything else: editability, analytics, A/B testing, anti-counterfeit, lifecycle management. Now when your CMO asks "but how can dots change?" you have a one-paragraph answer: the dots don't change; only what they redirect to does. Same trick as bit.ly, plus a printer and a camera.
