DEV Community: Nacho González

QR Code Security Best Practices for Platforms

Nacho González — Fri, 15 May 2026 08:51:19 +0000

Most guides about QR code security focus on the wrong end of the problem. They tell end users to "check the URL before tapping" while the platforms generating those codes do almost nothing to screen what they produce. End-user vigilance is necessary but not sufficient. QR code security best practices for platforms start before a code is ever generated: validating destinations against threat feeds, enforcing HTTPS, auditing redirect chains, monitoring scan anomalies, and maintaining tamper-evident audit logs. These controls sit at the platform layer, not the scanner layer. That's what separates a trusted QR infrastructure from one that can be weaponized.

TL;DR

Platform-level security acts before a QR code is generated — not after a user scans something suspicious.

The six core controls: URL validation, HTTPS enforcement, redirect chain auditing, scan anomaly monitoring, rate limiting, and audit logs.

Most platforms skip redirect chain inspection and scan anomaly alerting — two of the highest-value controls for detecting abuse early.

Enterprise deployments additionally need domain allowlists, role-based access, expiry policies, and compliance-ready audit exports.

Why Platform Security Is the Overlooked Half of QR Code Safety

QR code phishing (quishing) grew 400% between 2023 and 2025, according to data compiled by Keepnet Labs. The vast majority of the defensive effort went into educating users — how to preview URLs, how to spot lookalike domains. That's correct advice but it treats the symptom, not the source.

The source is often the generation platform. A platform with no URL validation will happily generate a code pointing to a known phishing domain. A platform with no rate limiting becomes a factory for attackers who create thousands of short-lived codes. A platform with no scan anomaly monitoring gives administrators no signal when one of their codes gets hijacked by a sticker overlay or link substitution.

End-user security training has a ceiling. Platform-layer controls don't. Every enforcement decision made at the platform level applies to every code, every scan, and every user simultaneously, without requiring anyone to remember to check a URL.

URL Validation Before QR Code Generation

URL validation is the first line of defense. A secure platform checks every destination URL before issuing a code, against at minimum three layers:

Threat intelligence feeds: Google Safe Browsing, URLhaus, and PhishTank collectively cover hundreds of millions of known malicious domains. Blocking these at generation time prevents the code from ever existing.
Protocol enforcement: HTTPS-only. HTTP destinations expose every scanner to a man-in-the-middle attack on unprotected networks. There is no valid reason for a production QR code to point to an HTTP URL in 2026.
Domain reputation scoring: Newly registered domains (under 30 days old), domains with no MX records, and domains using lookalike Unicode characters all carry elevated risk and warrant flagging or blocking.

Validation should run at creation and on every edit. A code pointing to a safe URL today can be retargeted tomorrow if the platform allows destination changes without re-validation.

What Most Platforms Skip

Most platforms check the URL format (is it a valid URL structure?) but not the URL content (is this destination safe?). Checking format is a developer convenience. Checking content is a security control. These are not the same thing.

HTTPS Enforcement and TLS Certificate Validation

HTTPS enforcement is a hard requirement for any platform used in a business context. The practical implementation goes further than just requiring the https:// prefix:

Validate that the destination certificate is valid and not self-signed
Check that the certificate common name matches the destination domain
Block destinations with certificates that expired within the last 90 days (the operator may not have renewed)
Flag destinations using certificates from CA providers with a history of mis-issuance

A platform that generates a code pointing to an expired certificate sends a false signal. Users see "HTTPS" and assume safety. A certificate check at generation time catches this before anyone scans.

Redirect Chain Auditing

Redirect chain auditing traces the full sequence of HTTP 301/302 responses triggered when a QR code destination is accessed. A secure platform records every hop, not just the first URL entered.

The exploit is domain laundering: an attacker registers a clean-looking URL, sets it as the QR destination, then adds a redirect to a malicious page. The platform's one-time URL check passes. The malicious destination is delivered on first scan. Without continuous redirect chain inspection, this attack stays invisible until a user reports it.

What to Monitor in a Redirect Chain

Root domain changes: The final URL should share the root domain with the entered URL. A redirect from brand.com to login-brand.com or brand.malicious.site is a red flag.
Chain length: Legitimate destinations rarely redirect more than 2 times. Chains of 4+ hops are common in ad-fraud and phishing infrastructure.
Third-party intermediaries: A link shortener inside a redirect chain for a branded QR code is a red flag. It adds a control point the platform owner doesn't govern.
Mixed content: HTTPS-to-HTTP transition mid-chain nullifies the protection of the initial HTTPS check.

According to research from QR-Insights published in 2025, approximately 23% of malicious QR codes in the wild use at least one redirect hop that crosses to a different root domain than the one encoded in the code itself. Continuous chain monitoring catches these cases. One-time generation checks do not.

Dynamic QR codes make continuous redirect chain auditing feasible because the platform controls the intermediate resolution layer: every redirect can be inspected server-side before the scanner's device ever reaches the final destination.

Scan Anomaly Monitoring

Scan anomaly monitoring treats each QR code as having a behavioral baseline and alerts when scans deviate significantly from it.

This catches two distinct threat scenarios:

Code compromise: An attacker places a sticker over a physical QR code with their own code. The original code's scan count flatlines while a new attack code gets high volume. The platform can't see the attacker's code directly, but it can see the drop in expected scans on the original.
Coordinated attack infrastructure: A compromised account generating many codes and distributing them at scale will show unusual scan volume patterns — hundreds of codes each getting a burst of scans from the same geographic cluster or device fingerprint.

Baseline Parameters Worth Tracking

Scan volume per hour, with rolling 30-day median and standard deviation
Geographic distribution — expected vs. actual country and city breakdown
Device and OS mix — a code on a physical restaurant table should show a spread of mobile devices, not 98% of one OS version
Time-of-day patterns — a retail QR code with consistent 3am UTC scan activity needs investigation
User agent entropy — extremely low diversity in user agent strings suggests automated scanning, not real users

Enterprise platforms should alert on deviations exceeding three standard deviations from 30-day rolling baselines, with a minimum scan count threshold to avoid noise on low-volume codes.

Rate Limiting and Abuse Prevention

Rate limiting on QR code generation is typically the last control operators add, usually after an abuse incident. Define limits before abuse happens.

Generation Rate Limits

Free-tier accounts: limit to a low per-hour ceiling (typically 10-20 codes per hour, 50-100 per day)
API keys: per-key limits with automatic suspension above configurable thresholds
Bulk generation: require explicit justification or approval for batch requests above enterprise thresholds
IP-based limits: rate limit by IP for unauthenticated requests, regardless of account limits

Scan-Side Rate Limits

Rate limiting also applies to scan resolution. A dynamic QR code that can be redirected instantly is also a code that could be weaponized instantly after a redirect change goes live. Platforms should:

Cache scan destinations for a short TTL (30-60 seconds) to prevent real-time redirect manipulation during attacks
Rate limit redirect resolution per source IP to mitigate automated scanner abuse
Require re-authentication for destination URL changes on high-value or high-scan-volume codes

Domain Allowlists for Enterprise Deployments

Domain allowlists restrict which destination domains QR codes in an organization's workspace can resolve to. This single control eliminates most insider threat and accidental misuse scenarios.

A media company running QR codes across 10,000 print placements can configure their workspace to only allow codes pointing to their own domains and a pre-approved set of CDN and partner domains. Any team member who tries to create a code pointing outside that list gets a hard block, not a warning they can click through.

The implementation should operate at the root domain level, not the individual URL level. A list of exact allowed URLs collapses under its own weight within weeks. A list of 20 allowed root domains is sustainable.

Dynamic vs. Static Allowlist Enforcement

For dynamic codes, allowlist enforcement needs to apply on every destination edit, not just at creation time. A code created pointing to an allowed domain can be edited to point elsewhere if the platform only checks at generation. Enforce the allowlist on every save, not just the first one.

Audit Logs for Enterprise Compliance

Enterprise QR code deployments sit within compliance scopes that require demonstrable controls. ISO/IEC 27001:2022 requires logging, monitoring, and role-based access. NIST SP 800-53 mandates event audit records for investigations. GDPR Article 32 requires demonstrable access controls for systems processing personal data, and a QR code tracking scans is processing personal data by default.

What a Compliant Audit Log Includes

Code creation: timestamp, creator user ID, initial destination URL, workspace/team
Every destination edit: timestamp, editor user ID, old URL, new URL
Deactivation and reactivation events: timestamp, actor
Access control changes: who was granted or revoked edit/view rights
Bulk operations: export requests, mass deactivations, API key issuance

Logs must be tamper-evident: append-only, cryptographically signed, or stored in a system the application layer cannot modify. An audit log the application can overwrite is not an audit log for compliance purposes.

Retention and Export

Most compliance frameworks require 12-24 months of audit log retention. GDPR's accountability principle means you need to produce records on demand. The platform should support structured exports (JSON or CSV) covering all fields needed for incident response without requiring an engineering ticket to pull the data.

QR Code Expiry and Rotation Policies

Not all QR codes should live forever. Expiry and rotation policies are security controls, not just operational housekeeping.

Physical access codes: should expire with the access grant. A code printed for a one-day event should not resolve 90 days later to anything useful.
Financial transaction codes: should expire within minutes to prevent replay attacks. A payment QR code that works indefinitely is a liability after the transaction is complete.
Campaign codes: should be deactivated at campaign end, not left resolving to a 404 or, worse, a domain that gets re-registered by a third party.
Personnel-specific codes: any code tied to an individual (business card, personal page, access pass) should be in an offboarding checklist — deactivate on the last day.

Rotation means issuing a new code with a new destination while deactivating the old one. Think of it like rotating a TLS certificate: you do it on a schedule, not just when something breaks. For high-security contexts, also rotate on suspected compromise, personnel changes, or any incident affecting the destination domain.

Physical QR Code Tampering: The Gap Platform Controls Cannot Close Alone

Platform-layer security has one structural blind spot: it cannot detect a physical sticker attack. An attacker who places a fraudulent QR sticker over a legitimate printed code bypasses every server-side control. The original code keeps existing on the platform with no anomaly, until its scan count drops enough to trigger an alert.

This is why scan anomaly monitoring matters even for organizations with strong platform controls. The only signal that a physical code has been covered is an unexpected drop in expected scan volume. Operators deploying codes in public spaces — restaurant tables, event entrances, retail displays — should set minimum scan rate alerts, not just spike alerts, so a sudden silence is as visible as a sudden flood.

Beyond monitoring, the physical mitigations are:

Use tamper-evident label stock for high-risk physical deployments (seals that show evidence of peeling)
Include a visible short URL alongside the QR code so users can verify the destination independently
For permanent installations, embed the code in the surface rather than on a removable label
Conduct periodic physical audits — spot-scan all codes at high-traffic locations quarterly

When Platform Security Controls Have Limits

Platform-level controls are more reliable than user-side security training, but they're not a complete substitute for a security culture. Here is where platform controls break down and what fills the gap:

Zero-day malicious domains: Threat intelligence feeds are reactive. A newly registered domain that hasn't yet appeared in Google Safe Browsing, URLhaus, or PhishTank will pass validation. Mitigation: add domain age checks (under 30 days) and domain reputation scoring as a secondary layer.
Compromised allowed domains: A domain on your allowlist that gets compromised remains allowed. The allowlist doesn't protect against destination compromise — only redirect chain monitoring and anomaly alerting do.
Insider threat: An administrator with platform access can create codes bypassing controls if the platform doesn't enforce role-based access with least-privilege principles. Audit logs are the detective control here; they don't prevent malicious insider creation, but they make it attributable and reversible.
API key leakage: Rate limits and API key per-key suspension mitigate but don't eliminate the window of exposure between key compromise and detection. Rotate API keys on a schedule, not just on suspicion.

What Secure Platforms Do vs. What Most Skip

Control	What most platforms do	What secure platforms do
URL validation	Format check only (is it a valid URL?)	Threat feed lookup, domain reputation, HTTPS enforcement, cert validity
Redirect handling	Encode the first URL entered, no inspection	Full redirect chain audit, domain change detection, chain length limits
Scan monitoring	Count scans, display a chart	Anomaly detection, geographic alerts, device entropy analysis, automated suspension
Rate limiting	None, or only per-account plan limits	Per-IP, per-key, per-account generation limits with automatic suspension
Domain control	Any destination allowed	Organization-level allowlists enforced at creation and every edit
Audit logs	None, or basic creation timestamp	Tamper-evident logs covering creation, edits, deactivations, access changes — exportable for compliance
Expiry policies	Manual deactivation only	Scheduled expiry, automatic deactivation, rotation workflows

The Security Controls That Actually Move the Needle

If you're evaluating a QR code platform and you only have time to check three things, check these:

Does it validate against threat feeds at generation time and on every edit? If the answer is "we check the URL format," that's a no.
Does it audit the full redirect chain, not just the first URL? Redirect laundering is the most common evasion technique. A platform that only checks the encoded URL provides incomplete protection.
Does it support tamper-evident audit logs with structured export? If the platform can't produce a compliance-ready audit trail on demand, it cannot be in scope for ISO 27001 or GDPR accountability controls.

Everything else — domain allowlists, anomaly alerting, expiry policies — layers on top of these three. Get the foundation right first.

Implementing QR Code Security Best Practices at Scale

Security controls on a QR code platform are most effective when enforced by configuration, not by user choice. Putting a warning on a dangerous destination and asking the user to confirm is not a security control — it's a liability disclaimer. Blocking the destination is a security control.

For organizations deploying QR codes across marketing, operations, payments, or physical access, the right question to ask any platform vendor is: what is enforced vs. what is optional? A platform that makes all of these controls optional and off-by-default provides them as features, not as security. A platform that enforces them at the workspace level provides them as architecture.

Security at scale fails at the point of least enforcement. If one team member can create a code pointing to an unvalidated destination because the control is opt-in, the platform's threat feed integration doesn't protect you. It protects everyone else.

Last verified: May 2026. Compliance framework references (ISO/IEC 27001:2022, NIST SP 800-53, GDPR Article 32) reflect current published standards as of this date.

GS1 Digital Link QR Code Implementation: The Technical Guide

Nacho González — Thu, 14 May 2026 16:14:20 +0000

Most guides about GS1 Digital Link QR code implementation explain what it is at a high level, then stop before the part that actually matters: how to build a URI that works at checkout, passes conformance validation, and survives contact with real scanner infrastructure. That gap is where implementations break.

Here is what you need to build a GS1 Digital Link QR code that works correctly, plus the five structural mistakes that produce codes which scan fine in a lab and fail in production.

GS1 Digital Link is not a new type of QR code. It is a standardized URI structure that turns any QR code into a dual-purpose identifier, readable by both checkout scanners and consumer smartphones from a single printed symbol.

TL;DR GS1 Digital Link encodes a GTIN (and optional qualifiers) into a web-compliant URI — one code for POS, logistics, and consumer engagement simultaneously. URI structure: https://domain/01/{14-digit-GTIN}[/qualifier/value][?attribute=value]. The GS1 Sunrise 2027 deadline requires POS systems in 48+ countries to accept 2D barcodes by end of 2027 — suppliers that miss this deadline face listing risk with major retailers. The five implementation pitfalls: wrong GTIN padding, deprecated convenience alphas, over-encoding, missing conformance testing, and short-link redirect layers.

What GS1 Digital Link Actually Is

GS1 Digital Link is an international standard (ISO/IEC 18975) published by GS1, the global nonprofit that maintains supply chain identity standards including GTINs, GLNs, and SSCCs. The standard defines a URI syntax that embeds GS1 identifiers directly into a web URL path, making those identifiers both machine-readable and web-resolvable.

A standard QR code encodes any arbitrary string: a URL, plain text, contact data. A GS1 Digital Link QR code encodes a URI that follows a specific structure. The same QR code can be scanned at a grocery checkout to retrieve GTIN-linked pricing and inventory data, and scanned by a consumer's smartphone to open a product detail page — without any modification between the two uses.

The distinction matters for implementation. The QR code format itself (the black-and-white square) is identical to any other QR code. What differs is the string encoded inside it. If that string follows the GS1 Digital Link URI syntax, the code becomes a standards-compliant identifier. If it does not, it is just a QR code with a URL in it.

The GS1 Digital Link URI Structure

The canonical URI structure defined in GS1 Digital Link standard version 1.2.1 (February 2022) is:

https://{domain}/01/{14-digit-GTIN}[/{qualifier-AI}/{value}][?{attribute-AI}={value}]

Breaking this down:

Domain — Can be id.gs1.org (GS1's global resolver) or any domain you operate a GS1-conformant resolver on. The standard is domain-agnostic.
/01/ — The Application Identifier (AI) for GTIN. The forward slash before and after is required.
14-digit GTIN — Always 14 digits, zero-padded on the left. A 12-digit UPC (e.g., 614141123452) becomes 00614141123452 in the URI.
Qualifier AIs (path segments) — Optional. Encoded in the URL path. Common qualifiers: /10/ (batch/lot), /21/ (serial number). Order follows GS1 AI concatenation rules.
Attribute AIs (query string) — Optional. Encoded as query parameters. Common attributes: 17 (expiration date, YYMMDD format), 11 (production date).

A real-world pharmaceutical example with all fields:

https://id.gs1.org/01/05901234123457/10/BATCH-A/21/SN0000123?17=271231

This encodes:

GTIN: 05901234123457
Batch/Lot: BATCH-A
Serial number: SN0000123
Expiration date: December 31, 2027 (encoded as 271231 in YYMMDD format)

A retail consumer product — a can of coffee, say — might only need:

https://id.gs1.org/01/09780201379624

The resolver at id.gs1.org looks up that GTIN and redirects appropriately: to a product page for a consumer scan, or returns structured data for a machine scan.

How the Resolver Works

The resolver is what makes GS1 Digital Link contextually aware. When a device scans the QR code, it sends an HTTP GET request to the resolver URL. The resolver reads the URI path (extracting the GTIN and any qualifiers), then uses request context — user agent, Accept headers, locale, or scanner-specific flags — to return the appropriate response.

For a consumer smartphone:

Camera app scans QR, extracts URI: https://id.gs1.org/01/09780201379624
Browser sends GET request to id.gs1.org
Resolver identifies it as a browser request (HTML Accept header)
Resolver returns HTTP 307 redirect to the brand's consumer product page

For a pharmacy dispensing system:

Scanner reads QR, extracts same URI
System sends GET with Accept: application/ld+json or similar structured-data header
Resolver returns JSON-LD with product identity data, verification links, and regulatory status

The GS1 conformant resolver specification (available at ref.gs1.org) defines the exact response formats and link type vocabulary: gs1:pip for product information page, gs1:safetyInfo, gs1:recallStatus, and others.

GS1 makes its resolver source code available as open-source software. Brands that want full control can run their own resolver, use a third-party managed resolver, or route through GS1's global instance at id.gs1.org.

Implementation Steps: From GTIN to Printed QR Code

Step 1: Obtain or Verify Your GTIN

A GTIN is the mandatory primary key. GTINs are issued by GS1 Member Organizations — in the US through GS1 US, in the UK through GS1 UK. If your products already carry UPC or EAN barcodes, you already have GTINs; you need to zero-pad them to 14 digits.

GTINs purchased from third-party resellers are often non-compliant for GS1 Digital Link. The resolver at id.gs1.org validates GTIN prefix ownership. If your prefix is not registered to your company in the GS1 registry, the resolver cannot confirm brand ownership and cannot serve conformant responses.

Step 2: Determine Which Qualifiers You Need

The qualifiers you include are driven by your use case:

Retail consumer engagement only: GTIN alone. URI ends after the 14-digit GTIN. Keeps the code short and the QR module density low.
Retail with fresh/perishable inventory: GTIN + batch (/10/) + expiration (?17=). Allows store systems to track lot-level freshness.
Pharmaceutical (EU FMD / US DSCSA): GTIN + lot (/10/) + serial (/21/) + expiry (?17=). Full four-component encoding for unit-level traceability.
Logistics shipping label: SSCC-based URI using AI /00/ as the primary key instead of GTIN.

Encoding more qualifiers than necessary is one of the most common mistakes in the field. Each added qualifier increases URI length, increases QR code density, and ties the printed code to data that may change. Codes that encode expiry dates have a fixed shelf life — when the expiry date passes, the code still scans but returns stale qualifier data that may confuse conformant readers.

Step 3: Choose Your Resolver Strategy

Three options exist:

GS1 Global Resolver (id.gs1.org): Works immediately for brands with registered GTINs. Limited customization of redirect targets without additional GS1 registry entries. Best for brands just starting with Digital Link.
Third-party managed resolver: Services like Digimarc and Sato offer managed resolver infrastructure. You control redirect targets, link types, and analytics without running your own servers.
Own resolver: Maximum control. GS1 provides open-source resolver software and a conformance test suite. Requires server infrastructure and ongoing maintenance. Right for large brands with dedicated engineering teams.

Step 4: Generate and Validate the URI

Before encoding into a QR code, validate the URI against GS1's Digital Link validator at ref.gs1.org/tools/gs1-digital-link-toolkit. The toolkit checks:

GTIN structure and check digit
AI ordering (primary key before qualifiers before attributes)
Character set conformance for each AI's value
Correct use of path vs. query string positions for each AI

If the URI fails validation, it will still encode into a QR code — the QR format has no awareness of the URI contents. The failure surfaces at the resolver, in scanner software that validates GS1 structure, or in conformance audits.

Step 5: Generate the QR Code at Correct Specification

GS1 recommends QR Code Model 2, Error Correction Level M (15% recovery) for most packaged goods. For pharmaceutical serialized codes where module density is high and print precision matters, Error Correction Level H (30%) is recommended.

Minimum size for reliable scanning: 15mm x 15mm at 150 dpi. For retail environments where codes may be scanned at distance or in poor lighting, 20mm x 20mm or larger. Quiet zone: 4 modules on all sides, minimum.

The QR code must encode the URI as UTF-8. Do not add any GS1 Application Identifier prefix string before the domain — the URI format makes the GTIN extractable without it.

Real-World Use Cases

Retail: The Sunrise 2027 Transition

GS1's Sunrise 2027 initiative requires POS systems in 48+ countries to accept 2D barcodes by the end of 2027. Walmart, Carrefour, Woolworths, and Albertsons have all published 2D-barcode acceptance roadmaps. Suppliers that cannot deliver scannable GS1 Digital Link QR codes face listing risk with their largest accounts.

For retail, the key constraint is that the same code must checkout-scan correctly at existing POS infrastructure while also serving consumer engagement through the resolver. The GS1 Digital Link URI satisfies both simultaneously — existing GS1 Application Identifier parsing software extracts the GTIN from the URI path without any modification.

Healthcare: EU FMD and US DSCSA Compliance

The EU Falsified Medicines Directive requires unique identifier verification on prescription medicines. The US Drug Supply Chain Security Act requires unit-level traceability. Both require GTIN + lot + serial + expiry, the full four-component GS1 Digital Link encoding.

A GS1 Digital Link QR code on a pharmaceutical pack satisfies both regulatory frameworks from a single symbol, and simultaneously allows pharmacists to scan the code to retrieve patient-facing product information through the resolver. The EU Digital Product Passport regulation, entering phased enforcement from 2027, adds a fifth use case: consumers accessing sustainability and circularity data through the same code.

Logistics: Scan4Transport

The GS1 Scan4Transport (S4T) standard applies GS1 Digital Link URI syntax to logistics labels, using SSCC (Serial Shipping Container Code, AI 00) as the primary key. A pallet label encoded with a GS1 Digital Link URI allows logistics operators to scan with any 2D-capable reader and immediately access shipment documentation, chain of custody records, and customs data — without proprietary scanner software or EDI lookup.

Five Pitfalls That Break Production Deployments

Pitfall 1: Incorrect GTIN Padding

Every GTIN in a GS1 Digital Link URI must be exactly 14 digits, zero-padded on the left. A 12-digit UPC like 614141123452 must appear as 00614141123452. Generating the code without padding produces a URI that fails AI parsing in conformant scanners, even though the QR code scans and the browser opens correctly. The resolver may accept it, but the code fails standards compliance audits.

Pitfall 2: Deprecated Convenience Alphas

Early versions of the standard allowed named aliases: /gtin/ instead of /01/, /lot/ instead of /10/. These "convenience alphas" were removed from GS1 Digital Link 1.2.1 and will not appear in future versions. Any implementation using them produces non-conformant URIs that fail validation. If your implementation vendor's code generator still outputs /gtin/ paths, require them to update.

Pitfall 3: Over-Encoding Mutable Data

Encoding promotion codes, campaign identifiers, or current-season marketing data in the GS1 Digital Link URI path locks that data into the printed symbol. When the promotion ends, every printed package carries a URI with stale qualifier data. Use the resolver to serve context-appropriate content. The URI should encode stable identity data only.

Pitfall 4: Skipping Conformance Testing

GS1 provides a Digital Link Toolkit at ref.gs1.org that validates URI structure. Many implementations skip this step, assuming that if the QR code scans and the page opens, it is correct. It is not. Conformance testing catches GTIN check-digit errors, AI ordering violations, and character set problems before they reach print runs. At scale (millions of packages), a conformance error requires a packaging recall. Testing costs nothing.

Pitfall 5: Short-Link Redirect Layer on Top of the URI

Some implementations route the GS1 Digital Link URI through a URL shortener or redirect service: the QR code encodes https://bit.ly/xyz which redirects to https://id.gs1.org/01/00614141123452. This breaks everything. The short link is not a GS1 Digital Link URI. Conformant scanners cannot extract structured identifier data from a redirect. POS systems that parse the scanned string for GTIN data receive a short URL with no parseable AI structure. Use the GS1 Digital Link URI directly.

When GS1 Digital Link Is Not What You Need

GS1 Digital Link is the right choice if your product requires POS checkout integration, regulatory traceability, or supply chain visibility that relies on GTIN-structured data. It is not the right choice for every QR code use case.

Restaurant menus, event registrations, business cards, promotional landing pages — none of these need GS1 Digital Link. A standard dynamic QR code pointing to a URL gives you redirect flexibility without the implementation complexity of resolver infrastructure, GTIN registration, and AI ordering rules.

Think of it this way: GS1 Digital Link is a supply chain identity standard that happens to use QR codes. Standard QR codes are a communication format that happens to be convenient for consumer engagement. Mixing them up produces either unnecessary complexity or non-compliance.

For GS1 Digital Link, you need a GTIN, a resolver, and a conformant URI — that infrastructure is separate from general-purpose QR generation.

How to Verify a GS1 Digital Link QR Code

Before printing at scale, run these three checks:

URI structure validation: Paste the URI into the GS1 Digital Link Toolkit at ref.gs1.org/tools/gs1-digital-link-toolkit. It confirms GTIN check digit, AI ordering, qualifier positions, and character set conformance.
Resolver resolution test: Scan the QR code with a standard smartphone camera and confirm it resolves to the correct consumer page. Then test with a GS1 conformant resolver test tool (available in the GS1 Digital Link Toolkit) to confirm structured data responses.
POS scan simulation: Use GS1's scan engine test (or a compatible point-of-sale emulator) to confirm the GTIN is correctly extracted from the URI path. This is the test that matters for Sunrise 2027 compliance.

The Business Case: One Code for Every Purpose

Before GS1 Digital Link, brands running multiple compliance, supply chain, and consumer engagement programs typically printed multiple codes or separate barcodes for each function. A pharmaceutical pack might carry a 1D barcode for FMD verification, a 2D DataMatrix for lot and serial tracking, and a separate QR code for patient-facing product information.

GS1 Digital Link collapses all three into one symbol. For brand owners, that is a direct reduction in label real estate, a simpler print production workflow, and a single point of truth for product identity across every supply chain touchpoint.

According to GS1 data cited in its 2024 Sunrise 2027 preparedness report, fewer than 30% of consumer packaged goods companies had completed a GS1 Digital Link readiness assessment as of Q4 2024. The Sunrise 2027 deadline is not a distant planning horizon. For brands that need to update packaging artwork, run conformance testing, and onboard resolver infrastructure, the effective implementation window is now.

GS1's implementation guideline (available at gs1.org/docs/Digital-Link/GS1_DigitalLink_Imp_Guide_i1.pdf) is the definitive reference for conformant GS1 Digital Link deployment.

Why QR Codes Expire (It's Not the Code — It's the Server)

Nacho González — Mon, 11 May 2026 07:10:12 +0000

Most explanations of QR code expiration say "your subscription expired" as if that's the full story. It's not. QR codes don't expire — the redirect infrastructure that dynamic codes depend on gets switched off, and every scan after that moment hits a dead server instead of your content.

Here's how it works at the architecture level, and why it matters if you're building anything that touches physical print.

Static vs dynamic: two completely different architectures

A static QR code encodes your destination URL directly into the pixel pattern using the ISO/IEC 18004 standard. No server, no lookup, no dependency. Scan it and the camera decodes the URL from the image itself. It will keep working as long as the physical print is readable and the destination URL is live.

A dynamic QR code encodes a short URL owned by the QR platform — something like qrtg.io/abc123. The camera sends an HTTP GET to that short URL. The platform's redirect server looks up where abc123 maps to and returns a 302 to your real destination.

Scan → GET https://qrtg.io/abc123 → 302 → https://yoursite.com/landing-page

That redirect server is what expires. The QR image never changes. The infrastructure behind it does.

The four ways the redirect stops working

1. Subscription cancellation

Payment fails or you cancel → platform downgrades your account → redirect server stops responding for your codes. On most platforms this is instant. No grace period. A billing failure at 2 AM means codes are dead before your staff shows up at 8 AM.

2. Trial end

You created codes during a 30-day evaluation. Didn't convert. Codes created during the trial deactivate on day 31. If you printed those codes before deciding not to subscribe, the materials are already broken.

3. Scan cap hit

Free tiers usually cap dynamic codes by scan count. As of April 2026:

QR Tiger free: 500 total scans per code
Flowcode free: 2 active codes, 500-scan analytics limit

Hit the cap and the redirect returns an error, even if your account is fully active. The counterintuitive part: a high-traffic QR code burns through its cap faster. Success triggers failure.

4. Platform shutdown

The redirect domain goes offline permanently. Every QR code that ever pointed at platform.io/r/... is unrecoverable. The QR code industry saw real consolidation in 2023–2024 — smaller platforms shut down or got acquired, and physical materials printed with those platforms' short URLs became permanently dead.

Why this is a harder problem than it looks

The subscription cycle and the physical materials lifecycle operate on completely different timescales.

A business prints 10,000 product boxes with a QR code. The boxes have an 18-month shelf life. Annual subscription renews fine the first year. Card gets updated, auto-renewal misses, subscription lapses six months before the last box ships.

Every box still on shelves now has a broken QR code. No one on the vendor's side knows. The platform sends no notification. The brand finds out when a customer mentions it.

Our support ticket data at QR Nova shows the average gap between a dynamic code going offline and the owner finding out via a customer report is 4 days. That's 4 days of scans hitting error pages for a product that's physically present and being handled by end users.

The silent failure mode is the real problem. When a code dies:

The scanner gets a generic 404 Not Found or a platform error page
No message saying "this QR code is deactivated"
The user assumes their phone has a bug, or the product is broken
The brand takes the hit invisibly

What actually matters when choosing a QR platform for print

If you're embedding QR codes in anything physical — packaging, signage, product inserts, printed menus — the most important question isn't "what features do you offer." It's:

What happens to my codes if I cancel tomorrow?

A platform that immediately deactivates all dynamic codes on subscription change is a liability for print use cases. A platform with a grace period or permanent code retention is not.

Other things worth checking:

Scan cap alerts — does the platform email you before you hit the cap, or after?
Custom redirect domain — if you can point your own domain at the redirect service, you can migrate platforms without reprinting anything
Export options — can you get your redirect rules out if the platform shuts down?
Operating history — a platform that's been running for several years with a clear business model is meaningfully less likely to disappear than a well-funded startup with no obvious revenue

The architectural choice that avoids the problem

For any destination that won't change, skip dynamic codes entirely. Static QR codes have no server dependency. The URL is baked into the image. There's nothing to cancel.

For destinations that need to be editable — campaign URLs, seasonal redirects — dynamic codes are necessary, but the redirect service itself doesn't have to be gated by billing state. That's an architectural choice platforms make, not a technical necessity.

At QR Nova, we built the redirect service so codes stay active regardless of billing status. The redirect lookup is not coupled to account state. It's a simpler system to operate and it removes the liability for anyone printing QR codes on anything physical.

Static codes are free with no account required. Dynamic codes keep working after you close the tab.

Originally published on QR Nova

Track QR Code Scans in GA4 Without Losing Attribution

Nacho González — Wed, 06 May 2026 18:44:13 +0000

You launch a print campaign. Posters go up, menus get new QR codes, product packaging ships with a fresh scan prompt. Two weeks later you open GA4 to measure performance and see a spike in direct traffic. No campaign, no source, no medium. Your QR scans are in there somewhere, mixed in with people who typed your URL by hand. This is the default behavior for QR code GA4 tracking, and it will keep breaking attribution on every physical campaign you run until you fix it.

TL;DR

QR scans arrive in GA4 as direct traffic because phones send no HTTP referrer when opening a URL from a camera app.

The fix is always-on UTM tagging: every QR destination URL needs at minimum utm_source, utm_medium, and utm_campaign.

GA4 has no built-in QR channel — create a custom channel group so tagged QR traffic is not bucketed as "Unassigned."

Use a consistent lowercase naming convention or your data fragments into separate line items that look like different sources.

QR platform analytics and GA4 serve different purposes — use both, not one or the other.

Why QR codes break GA4 attribution

Key concept: GA4 classifies every session by traffic source. When no UTM parameters and no HTTP referrer are present, GA4 defaults to "direct / (none)." That is exactly what happens with every untagged QR code scan.

GA4 identifies traffic source from two places: UTM parameters in the URL and the HTTP referrer header sent by the browser. Click a link on a webpage and that page's URL gets passed along as the referrer. Click an email link and the email client usually strips the referrer, which is why email marketers have been tagging URLs with UTM parameters for years.

QR codes are the same problem, only worse. Someone scans a QR code and their phone opens the URL in a fresh browser tab. No previous page to reference. No referrer sent. GA4 sees an empty source and files the session under "direct / (none)."

Every untagged QR campaign you run inflates your direct traffic number and vanishes from campaign reports. You cannot prove which placement drove visits, which campaign generated conversions, or whether your print spend was worth a dime.

The foundation: UTM parameters for QR campaigns

UTM parameters are query string tags appended to a destination URL. GA4 reads them on arrival and stores them as session-scoped dimensions, overriding whatever referrer data the browser would have sent. For QR codes, UTMs are not optional. They are the only attribution signal you have.

The five UTM parameters

utm_source — Where the traffic originates. For QR codes, use qr as a standard value across all campaigns. This makes it easy to create a single GA4 channel rule that captures all QR traffic regardless of format.
utm_medium — The channel type. Options include offline, print, packaging, outdoor, event. Pick the one that reflects the physical format.
utm_campaign — The campaign name. Keep it descriptive and lowercase: summer_menu_2026, trade_show_april, product_launch_q2.
utm_content — The specific placement within a campaign. utm_content=lobby_poster versus utm_content=table_card versus utm_content=receipt_footer gives you placement-level data inside a single campaign.
utm_term — Skip it for QR campaigns. It was designed for paid search keyword tracking and adds noise without value in an offline context.

A practical QR UTM URL structure

A properly tagged URL for a restaurant running a summer menu campaign:

https://example.com/menu?utm_source=qr&utm_medium=print&utm_campaign=summer_menu_2026&utm_content=table_card

Same campaign, different placement:

https://example.com/menu?utm_source=qr&utm_medium=print&utm_campaign=summer_menu_2026&utm_content=entrance_poster

In GA4, these sessions show up in Traffic Acquisition under source qr, medium print, campaign summer_menu_2026. Break down by utm_content to see which placement drove more scans or deeper engagement.

One rule: always use lowercase

GA4 is case-sensitive for UTM parameter values. utm_source=QR and utm_source=qr show up as two different sources. Pick your values, document them, enforce them. This is far and away the most common UTM mistake in practice.

Setting up GA4 to recognize QR traffic

Even with perfect UTM tagging, GA4 will not know what to do with sessions where session_source = qr and session_medium = offline. The default channel grouping has no rule for these values, so they land in "Unassigned." You need a custom channel group.

Step 1: open channel group settings

Go to GA4 Admin and select your property. Under Data Display, click Channel Groups. Click Create new channel group.

Step 2: create the QR code channel

Name your channel group "QR Campaigns" or copy the default channel group and add a new channel. Click Add new channel and name it "QR Code." Set the rule condition:

Dimension: Session source
Condition: exactly matches
Value: qr

If your team already uses multiple source values, add multiple conditions with OR logic.

Step 3: position the rule correctly

GA4 evaluates channel rules from top to bottom and stops at the first match. Place your QR Code channel above the broad catch-all rules like "Unassigned" or "Direct" so QR sessions are claimed before they fall through to a default bucket.

Step 4: save and publish

Click Save. One caveat: this rule is not retroactive. Sessions collected before you created it stay where they are.

Verifying it works

Use GA4's Realtime report to test right away. Scan one of your tagged QR codes on your phone and watch the active users report. Within a few seconds the session should appear with the correct source, medium, and campaign. If you see direct traffic instead, a redirect probably stripped the UTM parameters.

Where UTM tags break: redirects and dynamic QR codes

URL redirect chains trip up even experienced marketers. If your tagged URL goes through a redirect that strips query parameters, the UTM values disappear before they reach the landing page.

The typical failure: you tag a URL, shorten it, and the shortener's redirect does not preserve query strings. The user lands on your page with a clean URL and GA4 records a direct session. Test every redirect in your chain before printing anything.

Dynamic QR codes sidestep this. Instead of encoding a long UTM-tagged URL directly, the QR code points to a short redirect URL managed by your QR platform. The platform redirects to your destination with UTM parameters intact and lets you change the destination URL later without reprinting. For long-running campaigns, that flexibility alone is worth the switch.

QR platform analytics vs. GA4: use both

These tools track different things, and you need both.

A QR platform captures scan-level data: total scans, unique scans, device type, OS, location by country and city, time-of-day patterns. All of this is recorded the moment someone scans, before they reach your website. It tells you how many people scanned and where.

GA4 picks up after the landing page loads. Pageviews, events, conversions, session duration, goal completions. It tells you what scanners did once they arrived and how many converted.

A QR campaign might show 400 scans in the platform dashboard but only 220 sessions in GA4. That gap is real: users who bounced before the GA4 script fired, or users on devices with JavaScript disabled. Comparing scan data against session data is the only way to understand drop-off at the scan-to-landing-page step.

Five attribution mistakes that kill QR campaign data

1. No UTM parameters at all

The most common one, and the most painful. Every QR code destination URL must be tagged. No exceptions. If you already have QR codes printed on materials without UTM parameters, that attribution data is gone. You cannot recover it.

2. Tagging internal links

Adding UTM parameters to links between pages on your own website overwrites the session source mid-visit. A user arrives from your QR code, clicks a UTM-tagged internal banner, and GA4 reassigns the session to the banner as the source. Keep UTM parameters on external-to-your-site links only.

3. One generic QR code per campaign

Same tagged URL across five different placements means five placements sharing one line item in GA4. Worth creating a unique QR code for each placement, even if it takes a few extra minutes.

4. Inconsistent naming across campaigns

Someone on your team launches a new campaign with utm_source=qr-code while every previous campaign used utm_source=qr. Now you have a separate source row in GA4 that cannot be merged after the fact. A shared UTM naming doc, reviewed before each launch, prevents this.

5. Not testing before print

Printing 10,000 flyers with a broken QR code is an expensive lesson. Scan your QR code with GA4 Realtime open before sending anything to print. Confirm the UTM parameters survive every redirect in the chain.

Building a QR attribution report in GA4

With tagging and the channel group in place, build a focused QR campaign report in Explore using a free-form exploration.

Dimensions to include:

Session campaign — separates individual campaigns
Session source / medium — confirms QR sessions are properly tagged
Session manual ad content — surfaces your utm_content placement data
Landing page + query string — useful for catching untagged QR sessions that slipped through

Metrics to include:

Sessions
Engaged sessions
Engagement rate
Key events (conversions)
User engagement duration

Filter the exploration to Session source exactly matches qr to isolate QR traffic. Save it once and revisit across campaigns without rebuilding.

Conclusion

QR code attribution in GA4 is not a platform limitation. It is a setup problem you can solve in an afternoon. Tag every destination URL with consistent UTM parameters, create a custom channel group so GA4 knows what to do with that traffic, and test before you print. Those three steps recover attribution that most marketers are losing to the direct channel bucket right now.

Originally published on QR Nova

Dynamic QR Code Redirect Architecture at the Edge

Nacho González — Fri, 24 Apr 2026 20:13:50 +0000

A dynamic QR code is a short URL baked into a static image. The "dynamic" part is a database record: a slug-to-destination mapping you can update without reprinting. The image never changes.

Everything interesting happens in the redirect layer. Every scan is a live HTTP request that has to resolve before a user moves on. What follows is what that layer looks like, how to build it right, and where it breaks.

What "dynamic" actually means

The QR image encodes a fixed string like go.yourcompany.com/r/abc123. What changes is the database record mapping abc123 to a destination URL.

The reliability of every printed QR code is exactly equal to the reliability of that redirect server. Nothing in the image acts as a fallback. Slow server = slow scan. Down server = failed scan. Cancelled account = error page. The infrastructure is the product.

The redirect chain

Full sequence from camera tap to destination:

Scan: device reads the QR pattern, decodes the short URL
DNS resolution: resolves the redirect domain to nearest IP (edge) or one fixed IP (single-origin)
TCP + TLS handshake: 50–150ms cold, depending on distance and network
HTTP GET: GET /r/abc123 hits the redirect server
Lookup: server checks cache or KV store for the destination URL mapped to that slug
Async log: queues scan event (timestamp, IP, User-Agent) without blocking the response
HTTP 302: returns Location: <destination>
Browser follows the redirect
Destination loads

Steps 3–7 are what the redirect infrastructure controls. That window is what edge computing compresses.

Single-origin: how most platforms are built

Simplest implementation: one server in Virginia or Frankfurt. Every scan in the world hits that box.

Two problems surface at scale.

Latency first. Sydney to Virginia is about 180ms round-trip just to receive a 200-byte redirect response. On a slow mobile network where TCP setup already costs 100ms, you're at 300ms before the destination even starts loading.

Then there's the single point of failure. A bad deploy, a DDoS, or a data center incident takes every QR code on the platform offline at once. No second region to fail over to.

Most small QR platforms run exactly this. Fine at low volume. Problems show up at scale, and by then codes are already printed.

Edge-first architecture

Edge-first moves redirect logic to globally distributed nodes. Cloudflare Workers and Fastly Compute run JS/Wasm at 200+ cities. DNS resolves via anycast to the nearest edge node.

TTFB for Sydney to nearest edge: 5–20ms instead of 150–200ms.

At the node, the lookup reads from an in-memory cache or distributed KV. Cloudflare Workers KV replicates writes globally within ~60s and reads with single-digit millisecond latency from any node. One KV read, not a database query with joins.

Minimal Cloudflare Worker redirect handler:

export default {
  async fetch(request, env, ctx) {
    const slug = new URL(request.url).pathname.slice(3); // strip /r/
    const destination = await env.REDIRECTS.get(slug);

    if (!destination) {
      return new Response("Not found", { status: 404 });
    }

    // fire-and-forget, doesn't block the redirect
    ctx.waitUntil(logScan(request, slug, env));

    return Response.redirect(destination, 302);
  },
};

async function logScan(request, slug, env) {
  await env.SCAN_QUEUE.send({
    slug,
    ip: request.headers.get("CF-Connecting-IP"),
    country: request.headers.get("CF-IPCountry"),
    ua: request.headers.get("User-Agent"),
    ts: Date.now(),
  });
}

Numbers

	Single-origin	Edge
TTFB (same region as server)	20–40ms	5–15ms
TTFB (opposite side of world)	150–250ms	15–30ms
P99 under traffic spike	800ms–2s+	30–60ms
Regional outage	100% of scans fail	auto-failover, zero user impact
Cost at scale	Vertical scale-out	Per-request

302, not 301

Always use 302 (temporary redirect), not 301 (permanent).

301 gets cached aggressively by browsers. If a user previously scanned and their browser cached the old destination, updating the database does nothing; they get the old URL until their cache expires. 302 tells browsers not to cache, so every scan hits the redirect server fresh.

This is the most common redirect architecture mistake. Invisible during testing, only shows up for repeat visitors in production.

Caching at the edge

Not every destination changes frequently. Cache the slug-to-destination mapping at the edge to skip the KV read on hot slugs.

TTL of 30–120s covers most use cases. Fast enough for campaign changes, cheap at scale.

Stale-while-revalidate serves the cached destination immediately and refreshes in the background:

export default {
  async fetch(request, env, ctx) {
    const slug = new URL(request.url).pathname.slice(3);
    const cacheKey = `dest:${slug}`;

    const cached = await env.CACHE.get(cacheKey);
    if (cached) {
      // return immediately, refresh cache in background
      ctx.waitUntil(
        fetchFromOrigin(slug, env).then((dest) =>
          dest ? env.CACHE.put(cacheKey, dest, { expirationTtl: 60 }) : null
        )
      );
      return Response.redirect(cached, 302);
    }

    const destination = await fetchFromOrigin(slug, env);
    if (!destination) return new Response("Not found", { status: 404 });

    ctx.waitUntil(env.CACHE.put(cacheKey, destination, { expirationTtl: 60 }));
    ctx.waitUntil(logScan(request, slug, env));

    return Response.redirect(destination, 302);
  },
};

Users never wait for cache misses. The miss penalty is invisible.

Geo-routing at the edge

Some use cases need different destinations per location. A global brand might send US users to a US landing page and EU users to a different one with localized copy and compliance language. A restaurant chain might send users to the nearest location's menu.

Edge workers get geolocation headers on every request, no external API call needed. On Cloudflare, CF-IPCountry gives you the ISO country code. Store a slug:country key in KV and do the lookup in one read.

export default {
  async fetch(request, env, ctx) {
    const slug = new URL(request.url).pathname.slice(3);
    const country = request.headers.get("CF-IPCountry") ?? "XX";

    // try geo-specific destination first, fall back to default
    const destination =
      (await env.REDIRECTS.get(`${slug}:${country}`)) ??
      (await env.REDIRECTS.get(slug));

    if (!destination) {
      return new Response("Not found", { status: 404 });
    }

    ctx.waitUntil(logScan(request, slug, country, env));
    return Response.redirect(destination, 302);
  },
};

KV key structure:

abc123 → default destination
abc123:US → US destination
abc123:DE → German destination

One KV read for geo-specific, two reads for fallback. Still single-digit millisecond latency, no round-trip to a central routing service.

It's more useful than it looks. Regional A/B tests, localized landing pages, GDPR compliance redirects: all of it becomes a KV write from the dashboard instead of a deploy.

Analytics: async or you're doing it wrong

Writing to a database synchronously before returning the redirect is the worst architecture choice here. It puts a write operation (lock contention, index updates, network round-trip to a central DB) directly in the hot path of every single scan.

Two patterns that work:

Queue-based: the Worker sends a lightweight event to Cloudflare Queues or SQS and returns the redirect immediately. A separate consumer drains the queue, enriches events with geo-lookup and device parsing, and writes to the analytics store. If the pipeline backs up or errors, scans keep working.

Edge streaming: log events go to Cloudflare Logpush, then object storage, then Kafka or Kinesis, then the analytics DB in batches. More infrastructure, but scales to millions of scans per day without per-event writes.

Same principle either way: redirect response latency stays fixed. Analytics write latency is irrelevant to users.

What to monitor in production

A redirect service has a short list of things worth tracking.

Redirect TTFB by region: track P95 and P99, not average. Average hides tail latency that shows up for users on slow mobile networks. If P99 in Asia spikes to 800ms, something is wrong with KV replication or a regional node.

Cache hit rate: a sudden drop means something invalidated the edge cache. Catch it before it becomes a latency regression.

Scan error rate: 404s are expected for deleted slugs. 500s, timeouts, and connection resets need alerting. One bad deploy should not silently fail millions of scans.

Queue depth: if the scan event queue is backing up, the analytics pipeline has a problem. The redirect still works, but lag accumulates. Left long enough, you'll either drop events or overwhelm the consumer when it catches up.

In Cloudflare Workers, Workers Analytics Engine is a time-series store built for this pattern. Push a data point per request, query with SQL-like syntax via the Analytics Engine API.

// inside fetch handler, non-blocking
ctx.waitUntil(
  env.ANALYTICS.writeDataPoint({
    blobs: [slug, country, request.headers.get("CF-Ray") ?? ""],
    doubles: [Date.now()],
    indexes: [slug],
  })
);

Query it later:

SELECT
  blob1 AS slug,
  blob2 AS country,
  count() AS scans,
  quantilesMerge(0.95)(quantilesState(0.95)(double1)) AS p95_ts
FROM SCAN_EVENTS
WHERE timestamp > NOW() - INTERVAL '1' HOUR
GROUP BY slug, country
ORDER BY scans DESC

One endpoint. No external observability stack in the hot path.

Failover

When a node goes unhealthy, anycast DNS shifts requests to the next-nearest healthy one automatically. Latency ticks up slightly; the service stays up. With single-origin, one failure is a complete outage.

The resilience pattern most people skip: stale-on-error. If the origin data store is unreachable, serve the last-cached destination instead of returning an error. Destination changes are rare; the cached value is almost always right. A slightly stale redirect beats an error page every time.

The part that's not a performance problem

The short URL encoded in a printed QR code is permanent. Once it's on packaging, signage, or business cards, you can't change it without reprinting.

If that URL is qrtiger.io/r/abc123, every printed code's operational status is permanently tied to QR Tiger. Cancel the subscription and you get error pages. Platform shuts down, error pages. Price increase, you negotiate from zero leverage.

Owning the redirect domain fixes this. go.yourcompany.com/r/abc123 can point at any infrastructure at any time. Update a DNS record to switch platforms or self-host. The printed codes never change; what's behind them does.

Most QR platforms charge a premium for custom domains or don't support them at all. That's not incidental. A platform hosting your redirect domain has permanent leverage over materials that cost real money to replace.

Build vs. buy

A self-hosted redirect on Cloudflare Workers costs about $5/month for the Workers subscription plus under $0.50/million redirect reads. The Worker is 50–100 lines. A few hours to deploy.

What a platform adds: destination management UI, analytics dashboard, QR generation tooling, reliability guarantees. For teams without dedicated infra engineers, that management layer is the actual product. That's probably why most teams should buy rather than build.

Either way: edge compute for the redirect hop, analytics out of the hot path, short-TTL caching with stale-while-revalidate, stale-on-error resilience, and a redirect domain you control.

The QR image is just the entry point. The redirect layer is the product.

I'm building QR Nova, a QR platform built on this architecture. Happy to answer questions in the comments.