The short answer
A dynamic QR code does exactly one redirect: the phone scans a short URL, the redirect server replies with a 301 to the destination, and the phone follows it. That single hop is the whole mechanic — it is what makes a dynamic code editable and countable, and on its own it is fast and reliable.
A redirect chain is something different, and it is not a feature of the QR code at all. It happens when the destination you point the short URL at itself redirects somewhere else — short URL to A, A to B, B to the final page. The QR is still doing one redirect; the chain lives downstream of it, in the destinations you chose. Chains are almost always a mistake to avoid, and the fix is simple: point the dynamic short URL directly at the final destination, not an intermediate that redirects. Our qr code redirect guide covers the single-hop mechanic; here we go one level deeper into the multi-hop edge case.
A dynamic QR does one redirect by design
The redirect a dynamic QR performs is a single, well-defined hop. The printed code encodes a short URL like r.example.com/abc. The phone opens it, your redirect server looks up the slug, replies with a 301 pointing at the real destination, and the phone follows it. From the scanner’s point of view there is one short URL and one final page; the redirect happens in roughly the time it takes to load any web page.
That single hop is the entire basis of every dynamic power: editable destination, scan analytics, expiry, password gating, and multi-URL routing all live on that one server-side lookup. Nothing in the dynamic QR spec asks for, or benefits from, a second redirect after the first. See our dynamic qr code guide for the full mechanic; the chain problem is what happens when the destination you point at is not the final page.
When one redirect becomes a chain
A chain forms when the destination you configure on the redirect server is itself a URL that redirects. The classic ways this happens by accident: pointing the short URL at an old domain that 301s to the new domain, pointing at a URL shortener that then redirects again, pointing at a landing page that redirects by geography or device, or pointing at a page that has moved and now replies with a redirect to its new location. Each of those adds a hop after the QR’s own redirect.
So a scan becomes short URL to A (the QR redirect), A to B (the destination’s own redirect), B to final. The QR still did one redirect; the chain is the destination doing additional redirects the QR has no control over. A two-hop chain is usually harmless; a five- or ten-hop chain is where the real costs show up.
Why redirect chains are bad
Every extra hop adds latency before the scanner reaches content. Each redirect is a round trip — a DNS lookup, a TLS handshake, and a server response — so a five-hop chain can take several seconds before the final page even starts loading. On a flaky mobile connection the scan-to-content delay is the difference between a code that feels instant and one the user gives up on.
Each hop is also a failure point and a privacy leak. If any intermediate goes down, retires, or rate-limits, the whole chain breaks and the scanner lands on an error instead of your content. Each hop can also log the request and add its own tracking parameters, so the destination that finally loads may see a referrer and parameters that did not come from you. Worst of all, chains amplify link rot: a single stale hop anywhere in the chain bricks the entire path, even if the final destination is perfectly healthy.
The redirect-loop failure mode
A redirect loop is the degenerate case of a chain: A redirects to B, B redirects back to A, and the browser bounces between them forever. Browsers eventually give up after a set number of hops (commonly around 20) and show an “too many redirects” error, so the scanner never reaches any content. The QR code itself is fine — the loop lives entirely in the destination configuration.
Loops usually come from a misconfigured canonical/HTTPS rule, a www-vs-non-www redirect fighting a force-HTTPS redirect, or two shorteners pointing at each other. They are easy to create by accident and hard to notice from inside your dashboard, because the QR scans “fine” — the failure only appears on the scanner’s phone after the chain runs. The fix is to test the destination URL directly in a browser before pointing a dynamic code at it.
How to avoid chains
The rule is simple: point the dynamic short URL directly at the final destination, not at an intermediate that redirects. If the real page has moved, update the redirect server’s mapping to the new URL rather than letting the old destination redirect on its own. If you use a URL shortener inside a dynamic QR, you are stacking two redirect layers for no benefit — the dynamic QR already gives you a short printed URL, so shorten once, not twice.
Before you point a dynamic code at a destination, paste the URL into a browser and check that it loads the final page with no redirect bar hops, or use a redirect-checking tool that reports the chain. If it redirects, follow it to the final URL and configure that final URL as the destination. Keep the chain at one hop — the QR’s own — and the scan stays fast, private, and resilient. This is the same link-rot discipline our do QR codes expire guide recommends for keeping dynamic codes healthy.
Redirect hops at a glance
The table below summarizes the common redirect scenarios a dynamic QR can land in, what happens at each, and why it matters for the scanner.
| Scenario | What happens | Why it matters |
|---|---|---|
| Single redirect (normal) | Short URL to destination in one hop — the dynamic QR’s own redirect. | Fast, editable, countable; this is the design intent. |
| Two-hop chain | Short URL to A, A redirects to the final page. | Small latency cost; usually harmless but unnecessary. |
| Five-plus-hop chain | Short URL to A to B to C to D to final — stacked redirects. | Seconds of delay, a failure point at every hop, link-rot amplification. |
| Shortener on top of a shortener | Dynamic short URL points at another URL shortener that redirects again. | Two redirect layers for no benefit; double the rot surface. |
| Redirect loop | A redirects to B, B redirects back to A until the browser gives up. | Scanner lands on a “too many redirects” error and never reaches content. |
| Direct to final (the fix) | Short URL points straight at the final, non-redirecting destination. | One hop, minimal delay, single failure point, easy to maintain. |
How QRForge handles it
The free generator produces static codes by default — no redirect at all, so no chain is possible. When the planned paid dynamic tier ships, the redirect server will let you point each short URL directly at a destination you control, and the guidance above (point at the final page, test before you configure) keeps every code at a single hop.
Because a chain lives in the destination rather than the QR, the best defense is configurational: keep the dynamic tier’s destination list pointed at final, non-redirecting URLs, and audit them when a destination moves. Paired with the link-rot habits in our qr code redirect and do QR codes expire guides, a dynamic QR stays a single fast hop for the life of the print. Start with a static code to prove placement, and step up to dynamic only when editability or analytics is the actual lever.
Frequently asked questions
How many redirects can a QR code have?
A dynamic QR code performs one redirect of its own — short URL to destination. A redirect chain happens when that destination itself redirects, adding more hops. The QR always does one redirect; the chain is caused by the destination URLs you point at, not by the code.
What is a QR redirect chain?
It is when the destination a dynamic QR points at redirects to another URL, which may redirect again — short URL to A to B to final. Each hop adds latency and a failure point, so chains are best avoided by pointing the short URL directly at the final, non-redirecting destination.
Can a QR code cause a redirect loop?
Not the code itself. A loop (A redirects to B, B redirects back to A) lives in the destination configuration, not the QR. The browser gives up after many hops and shows an error, so the scanner never reaches content. Test the destination URL in a browser before pointing a dynamic code at it.
How do I avoid QR redirect chains?
Point the dynamic short URL directly at the final destination, not at an intermediate that redirects. Avoid stacking a URL shortener on top of a dynamic QR, and whenever a destination moves, update the redirect mapping to the new final URL instead of letting the old page redirect on its own.