Skip to content
UseQR
ESC

Jump to

MOVEOPEN50 places

Troubleshooting

QR code stuck in a redirect loop

A QR redirect loop is almost always a chain (shortener to consent page to app link and back) that a mobile or in-app browser cannot complete. Diagnose it with curl -IL to list every hop, then flatten the chain so the code points at one direct HTTPS destination.

View as MarkdownPaste this page into any AI assistant. It is plain, portable Markdown.

How the chain gets built

Nobody designs a redirect loop. It accretes. A typical QR destination in the wild is a short URL that 301s to a tracking interstitial, which redirects to a cookie-consent page, which redirects back once a cookie is set, which then tries an app deep link, which falls back to a web URL, sometimes back through the shortener. Five hops, each one a place to fail.

Browsers give up after roughly 20 hops (Chrome's hard limit is 20 redirects), and show ERR_TOO_MANY_REDIRECTS. But QR chains usually break well before that limit, for three specific reasons.

The three loop patterns

The consent-wall bounce. The consent page sets a cookie and redirects back to the original URL. QR scans frequently open in in-app browsers (Instagram, Facebook, WhatsApp, some camera apps) that restrict third-party cookies. No cookie sticks, so the destination bounces back to the consent page, forever.

The app-link bounce. The landing page immediately redirects to an app scheme (myapp://…). The app is not installed, so the OS returns to the browser, which loads the page, which redirects to the app scheme again. To the user this looks like a flickering page that never settles.

The rewrite loop. Misconfigured http → https or apex → www rules where each variant redirects to the other. This one affects every visitor, but a QR code is often the first place anyone notices, because printed codes tend to carry the oldest form of the URL.

Diagnose it with curl

First decode the code with our scanner so you know the exact entry URL, not the URL you think you encoded. Then trace the chain:

curl -sIL -o /dev/null \
  -w '%{num_redirects} redirects -> %{url_effective}\n' \
  'https://example.com/your-qr-link'

Or run curl -IL 'https://…' to print every response and its Location: header, hop by hop. A healthy chain terminates in a single 200 OK. A loop shows the same URLs cycling. Note that curl does not run JavaScript or set cookies by default, so a consent-wall bounce appears as a redirect to the consent page that never progresses, which is exactly what an in-app browser with cookies blocked experiences.

Our validator confirms the code itself decodes cleanly, which separates a scanning problem from a destination problem before you start.

The fix is to flatten the chain

Point the code at the final HTTPS destination, directly. Every hop you remove is a failure mode you delete and 100–500 ms of mobile latency you save. The working maximum is one redirect, and only if you genuinely need it for scan counting, where a single self-hosted redirect is the honest pattern.

If the loop lives inside a third-party shortener you cannot fix, reprint with a direct link, and read what happens when a shortener retires a link before choosing another one. If you are shortening a URL before encoding it, shorten to a domain you control.

For the app-link case: use the platform's official mechanisms (Universal Links on iOS, App Links on Android) rather than a JavaScript redirect to a raw scheme. They fall back to the web URL cleanly instead of bouncing.

FAQ

Why does my QR code say too many redirects?

The destination URL enters a cycle: commonly a consent page that cannot set a cookie in an in-app browser, or an http/https rewrite that points at itself. Browsers abort after about 20 hops. Trace the chain with curl -IL to see the cycle.

How many redirects should a QR code destination have?

Zero, ideally. One is acceptable when you run your own redirect for scan counting. Each additional hop adds mobile latency and another failure point, and chains through third-party services add an outage risk you do not control.

Scans often open in an in-app browser with third-party cookies restricted, where cookie-dependent redirect chains bounce forever. Your desktop Chrome, with the consent cookie already set, sails through the same chain.

How do I see where a QR code actually redirects?

Decode the code to get the exact encoded URL, then run curl -IL against it and read each Location header. That lists every hop, including ones added by shorteners and tracking layers you had forgotten were there.

Try it: free, no signup

  • QR code not scanning: the checklist, Work through these in order, because they are ranked by how often they are the actual cause: quiet zone, contrast, size for distance, glare, blur from…
  • QR code opens the wrong link or a 404, Decode the code first to see the string it actually contains. If the string is right, the problem is the destination: a deleted page, a retired shortener,…
  • QR code link shortener expired, When a free shortener retires or paywalls old links, every printed QR code through it dies at once. Recovery options ranked, and how to avoid a repeat.
  • QR code goes to a dead domain, A lapsed domain can be re-registered by anyone, including an attacker who inherits your printed codes. Rescue timelines, monitoring and prevention.
  • How to shorten a URL before making a QR code, A 78-char URL needs version 5; a 28-char link needs version 3: modules 27% bigger at print size. But a shortener in your ink is a dependency forever.