🔗 Redirect Chain Checker
Trace URL redirects — see the full redirect chain from start to final destination
About this tool
Paste a URL and the tool follows every redirect hop from the starting address to the final destination, showing the status code and full URL at each step. It catches HTTP→HTTPS upgrades, www→bare-domain consolidations, short-link expansions, and old-path→new-path rewrites — the kind of thing you need to verify after a migration or when debugging why a link lands somewhere unexpected.
Example: trace http://google.com and you typically see
301 → https://www.google.com/ — an HTTP-to-HTTPS upgrade
plus a www. prepend, all in one hop. Trace an old blog post URL and you can watch
it bounce through a shortener, a canonical redirect, and finally land on the live article.
The first probe goes directly from your browser; if the target server does not send CORS headers (most don't), the tool automatically retries through a public proxy so the trace still completes. Each step shows the status code (301, 302, 307, 308) and the destination URL with a copy button. A loop detector flags chains that revisit the same URL, and a hop counter warns when a chain runs long.
FAQ
Why does the chain sometimes show only the start and end URL? ›
Browsers cannot read the Location header of a cross-origin response, so when a site blocks CORS the tool follows the redirect through a public proxy that reports only the final URL. Intermediate hops that the proxy collapsed are still reflected in the hop count and the start→end diff. Sites that send permissive CORS headers expose every hop individually.
What is the difference between 301, 302, 307, and 308? ›
301 and 308 are permanent redirects (search engines replace the old URL). 302 and 307 are temporary. The odd/even split is about method preservation: 301 and 302 may turn a POST into a GET; 307 and 308 preserve the original method. For SEO, a chain of 301s should ideally be collapsed into a single hop.
The tool says "redirect loop detected" — what does that mean? ›
The trace hit the same URL twice, which means the server is sending the browser back and forth between two (or more) addresses forever. This is a server-side misconfiguration — often a trailing-slash conflict, an http→https rule that fights an app-level redirect, or a CDN misconfiguration. Browsers break the loop after ~20 hops.
Can I trace a URL that requires cookies or authentication? ›
No. The probe is unauthenticated and cookie-less, so URLs behind login walls will redirect to a login page rather than the protected resource. This is by design — the tool traces the publicly visible redirect chain, not a personalized session.