Understanding Redirect Chains and How to Avoid Them
By cryptoke, developer and editor at SafeLinkWrite. Reviewed for technical accuracy. For inspecting redirect parameters as part of a link check, see the six-check routine. For links that route through a controlled intermediate, see the safelink guide.
A redirect chain is what happens when a single click causes the browser to visit a sequence of URLs before it finally reaches the destination. The visitor types one address or clicks one link. The browser, following instructions from each server in turn, ends up somewhere else entirely — often many hops later. A chain is not an error; it is the honest outcome of several servers each doing their job without coordinating with the others.
Redirects are a legitimate part of the web. They handle outdated URLs, enforce HTTPS, resolve domains that have moved, and route regional users to the correct version of a site. A single redirect is normal. A chain of four or five is a problem, and the problem is invisible from the address bar — the browser only shows the final URL, never the path it took to get there.
What Counts as a Chain
A redirect is an HTTP response with a 3xx status code — 301, 302, 307, 308 — that tells the browser to fetch a different URL instead. A chain is two or more such redirects fired in sequence during a single navigation.
| Hop count | Typical meaning | Verdict |
|---|---|---|
| 0 | Direct URL — canonical, HTTPS, no wrapper | Ideal |
| 1 | Scheme upgrade (HTTP → HTTPS), or intentional safelink forward | Normal |
| 2 | Scheme upgrade + domain migration, or shortener → destination | Tolerable |
| 3 | Something is doing more than one job — usually tracking or geo-routing | Investigate |
| 4+ | Multiple independent systems inserting their own hop | Problem |
Most well-maintained sites stay at zero or one. Anything beyond two deserves the question: who benefits from the extra hops?
How Chains Form
A chain usually starts with a well-intentioned redirect. An old blog post still points to http://, the server sends it to https://. Then the site has moved to a new domain, and the second redirect fires. Then a marketing tool inserts a tracker parameter and redirects again. Then a mobile-detection script sends the visitor to a mobile version. By the time the page loads, four hops have occurred — each one chosen by a different party, none of them wrong from that party's perspective.
The pattern is structural: every redirect is someone's fix for a problem that would otherwise be unsolvable. The chain emerges when several parties are separately fixing their own corners of the web, and nobody owns the whole path.
Why It Matters — Three Costs
Privacy
Every server in the chain sees the visitor's IP address, user agent, and referrer — the signals described in the referrer article. A four-hop chain means four parties know where the visitor came from. Even if each operator is individually careful, the aggregate creates a distribution list of everyone who clicked.
Security
A malicious operator in the middle can change the final destination without the original publisher noticing. The visible URL might look benign while the landing page is something else. This is the same open-redirect abuse described in the phishing patterns guide — the difference is that a phishing link uses one redirect; a hijacked chain uses an existing one that the visitor has no reason to suspect.
Performance
Each redirect adds round-trip time. On a typical connection, a redirect involves a full request-response cycle — DNS lookup if the new host is different, TLS handshake if the host changes, then the new request. Realistically, 150–400 milliseconds per hop is common. A five-hop chain adds a full second before the page even begins to load. On mobile networks, it is worse.
Example: Following a Five-Hop Chain
Consider a link sent through a social media platform. The visitor clicks it and lands on a product page ten seconds later. Opening developer tools and viewing the Network tab reveals the actual sequence:
[1] GET http://shop.example.com/product/9921
→ 301 → https://shop.example.com/product/9921 (scheme upgrade)
[2] GET https://shop.example.com/product/9921
→ 301 → https://www.shop-example.com/product/9921 (domain migration: shop → www.shop-example)
[3] GET https://www.shop-example.com/product/9921
→ 302 → https://social.example/out?url=https://www.shop-example.com/product/9921
(social platform removes tracking wrapper)
[4] GET https://social.example/out?url=...
→ 302 → https://www.shop-example.com/product/9921?utm_source=social
(campaign parameter added)
[5] GET https://www.shop-example.com/product/9921?utm_source=social
→ 200 (final page renders)Five requests before the page even starts rendering. Every intermediate server saw the visitor's IP. The social platform's wrapper added a hop in step 3 purely to log where the visitor came from. The shop added a hop in step 4 to attribute the traffic. Neither hop was necessary. Both were decisions made by parties other than the visitor.
The link as sent — http://shop.example.com/product/9921 — was four characters away from the cleanest version: https://www.shop-example.com/product/9921. Writing the URL correctly the first time would have eliminated all but the final 200.
How to Spot a Chain Before It Fires
Browsers do not display redirect chains by default. Three methods to see them:
- Developer tools. Open the Network tab, reload the URL, and count every entry with a 3xx status code. This shows what already happened.
- Server-side checkers. Services like redirect-checker.org follow the URL without rendering it, returning the full hop list. This shows what will happen without putting the browser in the middle.
- URL structure itself. A URL with
?url=,?goto=,?next=, or?redirect=is a redirect by design. Those parameters announce the chain instead of hiding it.
The checker is the more useful of the three for evaluating a link before sharing it. It shows the destination and the intermediate parties without committing the browser.
How to Avoid Chains
Four rules cover the majority of cases:
- Link directly to the canonical destination. If a site has moved, update the link. Do not leave it pointing at a redirect that fires every visit.
- Avoid intermediates that themselves redirect. Some URL shorteners stack additional redirects for ads, geo-detection, or A/B testing. A trustworthy shortener forwards once.
- Prefer HTTPS from the start. Sending visitors to an
http://URL guarantees an immediate redirect tohttps://— one hop that writing the link correctly eliminates. - Use tools that do not add hidden hops. A safelink forwards once, from the intermediate page to the destination. A poorly designed safelink that routes through analytics or a fallback domain forwards twice or more. If you are building one, keep the forwarding step to a single hop.
Myths vs Facts
| Myth | Fact |
|---|---|
| "Redirects are always bad." | Redirects are how HTTP handles change. A single scheme upgrade or domain migration is expected. A chain of four is a symptom, not the disease. |
| "If the final URL is HTTPS, the chain is safe." | Each hop in the chain is a separate request. A malicious middle operator can rewrite the destination before the final HTTPS host is chosen. |
| "Shorteners add at most one hop." | Some shorteners add three or four: one for geo-detection, one for ads, one for analytics, one to the destination. Count them before trusting one. |
| "The address bar shows the true path I took." | The address bar shows only the final URL. The intermediate hops are visible only in developer tools or through a server-side checker. |
| "A padlock at the destination means nothing went wrong." | The padlock applies to the last connection. It says nothing about the intermediate hops the request passed through. |
| "Safelinks always add hops and should be avoided." | A well-built safelink adds exactly one hop — the intermediate page — and forwards to the destination directly. It is the pattern's discipline that matters, not its existence. |
| "OAuth and payment redirects prove chains are harmless." | Those chains are visible, expected, and tied to a single service. A hidden chain imposed by a tracking wrapper is a different category entirely. |
When Chains Are Legitimate
Some redirects are unavoidable. OAuth flows bounce through an auth provider by design. International sites route users by country. Payment processors send users back and forth to confirm a transaction. In those cases, the chain is the product, and every hop is expected — the user typically sees the intermediate pages and understands why they appear.
The problem is not redirects in themselves. It is chains that exist to serve someone other than the visitor — where the intermediate hops are chosen by parties the visitor did not engage and cannot see.
What to Do About It
Audit the links you share, especially the ones that receive a lot of clicks. If a link goes through three hops before landing, consider replacing it with a direct URL. If a service you rely on adds hidden redirects, treat it as a warning sign, not an inconvenience. If you publish links that go through an intermediate page you control, make sure that intermediate page forwards once — not twice, not three times.
Every hop is an opportunity for a change of destination. Chains are how visitors end up on pages they did not intend to reach. The next time a page takes longer than expected to load, open the Network tab and count the 3xx responses — the number will tell you how many parties saw the click before the destination did.