QR Code Security: Dynamic QR Risks and Shortened URL Traps

Published 2026-04-13 7 min read

Summary (TL;DR)

A few weeks ago I scanned a café’s table-menu QR and it resolved to an unfamiliar ql.st shortener. When I looked closer, a clean sticker had been laid over the original QR. The owner told me it had been there for weeks and no one had noticed. There is almost no literature on “hacking” the QR format itself, and for good reason — the actual attacks are this boring. Someone prints a new sticker. Your customer follows it. The rest of this post tries to respect that reality: most QR security is paper, tape, and the URL you picked two years ago.

A QR code is not a security primitive. It is a visual encoding of a string — usually a URL — and its safety is almost entirely a function of the destination URL and the way the code was produced. Static QR codes carry the final URL directly and cannot be changed after printing. Dynamic QR codes carry a short redirector URL that can be repointed at will, which is convenient but creates long-term risk: if the redirector service shuts down, changes hands, or is compromised, every scanned code follows the new destination. URL shorteners have the same class of issues (expiry, hijack, tracking), which makes them poor choices for public print materials that should work for years. A good default is to encode a canonical URL on your own domain directly into a static QR, and reserve dynamic QR or shortened links for short-lived marketing campaigns where you explicitly plan for the end of life of the redirector.

Background

QR codes are defined by ISO/IEC 18004. Versions range from 1 to 40; higher versions have more modules (grid cells) and can carry more data. Every QR code also stores Reed-Solomon error-correction data at one of four levels:

  • L: up to roughly 7% recoverable
  • M: up to roughly 15% recoverable
  • Q: up to roughly 25% recoverable
  • H: up to roughly 30% recoverable

Higher correction levels allow dirt, creases, or a logo overlay to obscure part of the code without breaking it, but they increase module density, which makes very small printed codes harder to scan. Business cards and posters typically default to M, with Q or H chosen when a center logo is required.

Static QR codes embed the final URL directly into the modules, so the scanned result is permanent. Dynamic QR codes embed a short redirector URL and rely on a provider that can repoint the destination. That flexibility is the feature — and also the long-term risk — of dynamic codes.

There is also a capacity angle. A Version 1 QR code (21x21 modules) can hold around 25 alphanumeric characters at M correction; a Version 10 code (57x57 modules) can hold more than 300 characters. Long URLs push you to higher versions, which are denser and harder to scan at small sizes. A dynamic QR’s short redirector is genuinely smaller on paper, but that compactness is paid for in long-term dependency. If the destination you actually care about can be shortened within your own domain (for example, example.com/p/123), you get most of the size benefit without outsourcing the redirect.

A related concept is quiet zone. QR scanners rely on a blank border — typically four modules wide — around the code. If your layout compresses the quiet zone to save space, scanning becomes unreliable even though the code itself is intact. When print designers say “the QR doesn’t scan,” the quiet zone is the first thing to inspect.

Data / Comparison

CriterionStatic QRDynamic QR
Encoded URLThe final destination URLA short redirector URL
Scan tracking / analyticsNot available by defaultStandard feature
Expiry riskNone as long as your domain is maintainedDepends on the provider’s plan, contract, and lifecycle
Third-party dependencyNoneRedirector service
Phishing surfaceOnly the destination URL needs vettingRedirector hijack or handover can silently change destination
Editability after printingNot possible, must reprintPossible

A short URL can look cleaner on print, but users cannot visually verify where it leads. That is the same property attackers exploit — you are trading a bit of aesthetics for a large category of risk.

Real-world Scenarios

Scenario 1 — Business cards and posters. I recently pulled a business card from a 2019 contact and scanned its QR out of curiosity. The bit.ly target returned a 404 — presumably the owner’s shortener plan lapsed when the company reorganized. Encode a canonical URL on your own domain into a static QR. Print materials often circulate for years, and redirector dependencies rarely survive hype cycles or company reorgs. For small printed codes, lower the correction level and minimize URL length to keep module count down and scan reliability up.

Scenario 2 — Measuring a marketing campaign. A startup I know used a popular dynamic QR service at a trade show; three months later, the free tier quietly retired the feature they relied on, and every physical handout started redirecting to a “plan expired” page. When tracking is the entire point, consider dynamic QR with a reputable provider or static QR pointing to a URL with UTM parameters. I now default to a self-hosted shortener path like yourdomain.com/go/summer-2026: as long as you hold the domain, there is no expiry clock. If you still choose third-party dynamic QR, document a shutdown plan: where the redirect goes when the campaign ends, and who owns that decision.

Scenario 3 — Document integrity and verification. Instead of only a URL, encode a document hash or a signed URL parameter (e.g., ?d=abc123&sig=...) so a scanner can confirm the document matches the original. On one certificate-issuing project I worked on, we packed the first 16 hex characters of a SHA-256 hash plus an HMAC signature into the QR; that pushed us to Version 10+ codes, and we had to rebalance print size versus scan reliability. This is useful for contracts, certificates, and product labels where tamper detection matters.

Scenario 4 — Restaurant menus and public kiosks. The post-2020 surge in menu QR codes made public places a rich target for sticker-based phishing: an attacker prints a lookalike QR, places it on top of the real one, and the unsuspecting diner is redirected to a credential-harvesting page. Defensive measures are boring but effective: laminate the code onto a fixed surface, inspect daily, and use a canonical URL on your restaurant’s own domain so that customers who do check the preview can recognize it.

Common Misconceptions

“QR codes can be hacked.” The format itself is not typically the weak link. The real risks are malicious URLs encoded inside the QR and physical tampering — someone sticking a new QR sticker on top of yours in a public place. Visually inspecting posted codes for added stickers is a basic physical-security habit.

“Short URLs are cleaner, so they are better.” They are cleaner visually, but users cannot verify them, the underlying service can close or be compromised, and the QR itself becomes a long-lived dependency on a third party. For long-lived print material, a canonical long URL is safer.

“Higher error correction is always better.” H-level correction is handy if you want to cover the center with a logo, but it increases module density and reduces scan reliability at small print sizes. M is a typical safe default.

“You can always tell where a QR goes.” iOS 17 and 18’s built-in camera app shows a URL banner before opening, but some Android OEM camera apps and third-party scanners will jump straight into the browser on a single tap. Public-Wi-Fi-login phishing QRs specifically target that auto-open behavior. Disable auto-open where possible, and make it a habit to verify the domain before tapping.

“A QR code I generated myself is automatically safe.” Not if you generated it through a third-party web service that logs every input. Some free QR generators save submitted URLs and resell the analytics, or silently wrap your URL in their own redirector so they can track scans. Read the privacy statement or generate the code in a tool that runs entirely in your browser.

“Encoding is encryption.” QR is an encoding, not an encryption scheme. Anyone with a scanner can read the encoded data, and the same applies to barcodes generally. If you need secrecy, encrypt the payload before encoding it — for example, encode a signed JWT rather than a readable parameter.

Checklist

  1. How long must this QR work?
    • Years: prefer static QR + your own domain URL.
    • Short campaign: dynamic QR or UTM parameters are reasonable.
  2. Do you really need tracking?
    • No: static QR is sufficient.
    • Yes: pick a reputable dynamic QR provider, and plan for end-of-life redirection.
  3. What is the print size?
    • Very small: shorter URL and M-level correction.
    • Normal to large: you can afford Q or H if you want a logo overlay.
  4. Is the code placed in public? Inspect periodically for tampering or sticker overlays.
  5. Is the destination URL safe? Confirm HTTPS, domain ownership, and current validity.
  6. Where is the QR generated? Prefer offline or in-browser generation so that the encoded URL never leaves your device as a log entry on a third-party site.
  7. What happens if the QR fails? Design a fallback: a short printed URL next to the code, or a human-readable hint, so the material remains useful even when a scanner misreads or the destination is temporarily down.

The Patrache Studio QR code generator builds codes in the browser, so the URL you enter is not sent to an external server. If the resulting QR is embedded in an image for the web, pair it with the format guidance in the Image Compression Guide. If the QR ends up on a packet of documents you intend to distribute, the flow in PDF Merge & Split in Browser keeps the whole pipeline — from asset to final PDF — within a consistent privacy boundary.

References

Related Tool

tools.patrache.studio/qr/generator/