Redirect Chain Checker
Reconstruct redirect hops from captured headers, resolving locations and surfacing loops, method changes, and origin shifts.
Paste the actual response-header blocks in order. No destination is fetched from this page, so browser CORS restrictions cannot hide a hop after the response headers have already been captured.
curl -sS -D - -o /dev/null -L --max-redirs 20 --proto '=http,https' --proto-redir '=http,https' 'https://example.com/'
Redirect hops, method changes, loop warnings, and final response details will appear here.
The Redirect Chain Is the Behavior—Not Just the Final URL
A browser may eventually land on the correct page while hiding several avoidable requests along the way. An old HTTP URL might redirect to HTTPS, then to www, then add a trailing slash, then finally reach the page. The destination looks correct, but every intermediate response is still part of the request path.
The path is reconstructed from the captured response headers. Relative Location: /docs values are resolved against the URL that produced them, so you can see the effective target rather than guessing what the header means.
A Three-Hop Canonicalization Chain Usually Means Several Rules Are Solving the Same Problem
http://example.com/page 301 → https://example.com/page 301 → https://www.example.com/page 301 → https://www.example.com/page/ 200
That can happen when the CDN enforces HTTPS, the application enforces the preferred hostname, and a framework independently normalizes trailing slashes. None of the individual rules is necessarily wrong, but combining the decisions into one redirect reduces round trips and makes internal links easier to reason about.
301, 302, 303, 307, and 308 Do Not Mean the Same Thing to a POST Request
For ordinary GET navigation, developers often focus on whether a redirect is permanent or temporary. With forms and APIs, the request method matters too. HTTP 307 and 308 explicitly preserve the request method when automatically followed. HTTP 303 is designed to direct the client to retrieve another resource, normally with GET.
HTTP 301 and 302 have historical user-agent behavior that can change POST to GET. The initial method therefore matters: the same status chain can have different consequences for an API call than for a normal page visit. The analysis follows RFC 9110's explicit 307/308 preservation rules and its permitted historical POST-to-GET behavior for 301/302.
HTTPS → HTTP Is More Than an Extra Hop
A secure URL that redirects to plain HTTP downgrades the next request's transport security. Modern browsers, HSTS policy, mixed-content rules, and product-specific behavior can alter what happens next, but the redirect itself deserves investigation.
The reverse path—HTTP to HTTPS—is common during migration, but internal links and canonical URLs should normally point directly at the HTTPS destination once it is established.
A Redirect Loop Is About Requests, So Fragments Do Not Rescue It
URL fragments such as #pricing are processed by the client and are not sent as part of the HTTP request target. If a chain appears to alternate only by fragment while returning to the same request URL, that is not a meaningful server-side escape from a loop.
RFC 9110 also says a redirect target inherits the previous fragment when Location does not provide one. Resolved targets here follow that rule, while loop detection strips fragments because they are not part of the server request target.
Why the Browser Does Not Directly “Check the URL” for You
Browser Fetch can automatically follow redirects, and cross-origin response access is constrained by CORS and redirect behavior. A simple fetch() request can report the final URL while leaving intermediate response headers unavailable, even though the redirects happened.
A command-line HTTP client can expose each response block without requiring the destination site to grant this page cross-origin access. A captured trace therefore gives a more honest basis for reconstruction than pretending browser-only Fetch can always reveal every intermediate response.
Do Not Replay Unsafe Methods Just to Inspect Redirects
GET and HEAD are designed around retrieval semantics, so the page can safely offer a generic curl capture command for those methods. POST, PUT, PATCH, and DELETE requests can create or modify server state. Replaying them against a production endpoint merely to collect headers can trigger real actions.
For an API or form redirect, capture the response trace from the actual request you are already debugging and paste the headers here.
A Trace That Ends on 301 Is Not Proof of the Final Destination
A redirect response can point at a target that itself redirects, fails TLS, returns 404, requires authentication, or never responds. If the pasted trace ends on a redirect block, the last target remains unresolved rather than being presented as a successful final response.