Redirect Checker
Paste HTTP response headers to trace Location hops, resolve relative redirects, compare request-method behavior, and spot loops, protocol downgrades, ambiguous destinations or an incomplete chain.
Collect response headers
Enter a valid HTTP or HTTPS URL to generate a cURL command.
GET/HEAD commands follow redirects and print every response header block. For POST/PUT/PATCH/DELETE the generated command intentionally captures only the first response: automatically following a method-sensitive request without its real body, authentication and headers can produce misleading behavior.
Paste one or more response header blocks. HTTP/1.0, HTTP/1.1, readable HTTP/2 and HTTP/3 status lines are accepted.
Redirect hops, resolved destinations, method behavior, loops and deployment findings will appear here.
A Redirect Check Needs Response Evidence, Not a Guess From the URL
Nothing about https://example.com/old proves whether the server returns 200, 301, 404, a JavaScript redirect or a login challenge. The useful evidence is the actual HTTP response status plus its Location field.
Pasted response headers keep those two questions separate: what the server actually returned, and how that response changes the next request. Relative Location values can then be resolved one hop at a time without claiming that the live server was contacted.
301/302 and 307/308 Solve Different Method Problems
For historical compatibility, clients may turn a POST into GET when following 301 or 302. HTTP 307 and 308 exist specifically so an automatic redirect does not change the request method. A 303 intentionally points to a separate retrieval, normally GET.
That distinction can be invisible on a normal page navigation and critical on login, checkout, webhook or API endpoints. HTTP 300 is different again: a Location value can identify a preferred choice, but a client is not required to automatically follow that choice.
Relative Location Values Are Valid
Location is a URI reference; a redirect can say Location: /docs/ rather than repeating the complete origin. The destination must be resolved against the request URL of that hop, not always against the original URL.
Resolution therefore has to advance one URL at a time. A second relative Location is resolved from the first redirect destination, not from the URL where the chain originally started.
HTTPS → HTTP Is More Than an SEO Cleanliness Issue
Downgrading a redirect destination from HTTPS to HTTP changes the transport security of the next request. Depending on HSTS, browser state and infrastructure, the user may be upgraded again or may briefly enter an insecure path.
During migrations, prefer a direct HTTPS destination when the target supports it rather than relying on a later redirect to repair the scheme.
Loops Are Compared Without URL Fragments
The fragment after # is not sent as part of an HTTP request. Therefore /page#one and /page#two still request the same HTTP resource. Treating those as different network hops could hide a self-redirect loop.
A Cross-Origin Redirect Can Change Authentication and Cookie Behavior
Redirecting from one origin to another can change which cookies are sent, whether Authorization is retained by a client, how CORS applies and which caches/CDNs participate. A cross-origin hop is not automatically wrong, but it deserves visibility in API and login flows.
Migration Chains Should Usually Collapse Toward the Final URL
Old HTTP → old HTTPS → new HTTPS → canonical new URL can accumulate over years of migrations. Browsers may still reach the page, but every avoidable hop adds latency and another place where cache, method or hostname rules can diverge.
When you control the redirect map, update old sources to point directly to the intended canonical destination while preserving any necessary method semantics.