# 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.

Source: https://useqr.app/docs/troubleshooting/qr-code-redirect-loop · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## How the chain gets built

Nobody designs a redirect loop. It accretes. A typical QR destination in the wild is a
[short URL](/glossary/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](/scan) so you know the exact entry URL — not the
URL you think you encoded. Then trace the chain:

```bash
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](/validate) 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](/docs/how-to/how-to-track-qr-code-scans), 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](/docs/troubleshooting/qr-code-link-shortener-expired) before choosing another one. If
you are [shortening a URL before encoding it](/docs/how-to/how-to-shorten-a-url-before-making-a-qr-code),
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.

### Why does the link work in Chrome but not when scanned?
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

- https://useqr.app/url
- https://useqr.app/scan
- https://useqr.app/validate