What does this actually show me?

One line per request shows the status and the absolute URL that its Location header resolves to. A relative Location such as /new-page is also shown as received. The summary gives the hop count, redirect count, final status, elapsed time, observation time and deployment region. Copy chain puts the status sequence, resolved destinations, hop count, elapsed time, observation time and any stop explanation on your clipboard as plain text; it does not include the raw Location headers.

What is the difference between 301, 302, 307 and 308?

301 and 308 indicate permanent redirects; 302 and 307 indicate temporary redirects. Clients may change POST to GET after 301 or 302, while 307 and 308 preserve the method and body. A 303 directs a retrieval using GET or HEAD. This checker always sends HEAD at every hop, including after a 303. These status codes describe HTTP behavior; they do not prove which URL a search engine indexes or selects as canonical.

Why did my check stop before the end of the chain?

The page names the way the walk ended and keeps every hop it observed before that. A loop means the chain returned to a URL it had already requested, and it tells you which hop it went back to. The hop limit means the chain was still redirecting after ten requests, and it gives you the next URL so you can carry on from there. The deadline means the configured eight-second request budget was exhausted. A refused HEAD means the server answered 405 or 501 to the method this tool uses. A blocked target means the next URL is one this tool will not request: a host that resolves to an address off the public internet, a scheme other than http or https, a port other than 80 or 443, or a URL carrying a user name or password. A redirect with no Location header means a hop answered with a redirect status and sent nowhere to go next. A connection failure means a name stopped resolving part way down the chain, a connection could not be made, or the response headers were larger than the 8KB this tool reads. When the very first request is the one that fails there is no chain to show, so the page gives you the reason on its own.

Why does it say the server refused HEAD, and why not just use GET?

A 405 Method Not Allowed or 501 Not Implemented response stops the chain as a refused HEAD. A 401 or 403 ends the chain with that status and a note that HEAD may differ from GET. The checker never retries with GET, so it cannot determine whether the same URL would load normally in a browser.

Why will it not check localhost, an internal host name or an odd port?

Because a server that follows a URL you give it will also follow a redirect somebody else chose, and the classic abuse of that is pointing it at the machine it runs on or at a cloud metadata address. Every host name is resolved and every address it answers with is checked before a connection is made, at the first URL and again at every hop, and anything private, loopback, link local, multicast, reserved or IPv4-mapped is refused by name. Connections are made on ports 80 and 443 only, and a URL carrying a user name or password is refused rather than sent.

Why does my browser end up somewhere else?

Because a browser does more than follow HTTP redirects. A page can redirect with JavaScript or a meta refresh after it loads, a site can route you by cookie, by sign-in state or by the country your address sits in, and none of that is visible in a response header. This page shows the HTTP redirects a plain HEAD request received from our deployment region at the time shown, which is a smaller and more exact thing. It is not a statement about what a search engine indexes or which URL it treats as canonical.

Is the result live, and do you keep the URL I check?

A result may reuse the server's five-minute cache only when the starting URL and every value in the observed chain contain no query string. The result shows when the observation was made. Query strings in later Location headers or unrequested destinations also exclude the whole result from caching; live results and Copy chain keep their observed values. The checker code does not log requested URLs, paths or queries. Your browser remembers the last input in local storage; Start over clears it.

Is there a limit on how many redirects it follows?

The checker follows at most ten requests, uses an eight-second deadline for the whole chain including DNS lookups, and accepts response headers up to 8KB per hop. A DNS lookup that outlasts the deadline cannot start another connection. The browser stops waiting for the server response after fourteen seconds. When the hop limit is reached, the stop explanation includes the next URL that was not requested.

Can I check HTTP-to-HTTPS and www redirects?

Yes. Enter a full starting URL such as http://example.com/path to inspect an HTTP-to-HTTPS redirect, or https://www.example.com/path to inspect a www redirect. A bare domain defaults to HTTPS. The chain shows changes of scheme, host and path that the server returns to HEAD. It checks one starting URL, without comparing every www and non-www variant or auditing TLS certificates.

Can a redirect chain end with a 404?

Yes. A 404 Not Found is shown as the final status of that HEAD request. It is not itself a redirect, and the checker does not create redirects or repair missing pages.

Can I use this redirect checker in Chrome?

You can use the URL form in Chrome without installing an extension. Your browser submits the check to our server and displays the observed HTTP chain. An internet connection is required; the result does not reproduce your browser cookies or sign-in state.

Can I check URLs in bulk or download a report?

The form accepts one starting URL per check. It does not accept a batch of URLs or provide file, PDF or ZIP downloads. Copy chain is the available text output.

Redirect Checker

Paste a public URL to see its HTTP redirect chain, status codes, Location headers and final requested URL. The check sends HEAD requests from our server, without reading page bodies or requiring an account. It follows at most ten hops and names early stops: a loop, the hop limit, the deadline, a refused HEAD, a blocked target, a redirect with no Location header, or a connection failure.

HEAD only10 hops max8 s deadlineports 80 and 443

Enter a URL and press Check redirects. Nothing is requested until you do.

Hops: not yet
Final: not yet
Time: not yet
Method: HEAD

301 then 308 then 200a chain of two redirects
every hop, its status and the URL its Location resolved to
A redirect loopA sends you to B, B sends you back
the loop is named, with the hop it returns to, and the walk stops
HEAD answered 405the server refuses the method
shown as a limit of this check, with no retry as GET

What this observes. Observed server HTTP redirects only, by HEAD request from our deployment region at the time shown. JavaScript and meta-refresh redirects, cookie or geography specific routing and authenticated flows are outside what this can see. Each check is one HEAD request per hop, made from this deployment with the standard Node.js HTTP and TLS runtime. Every address a host resolves to is checked before the connection is made, and a redirect into a private, loopback or link local address is refused rather than followed.

Common questions

What does this actually show me?: One line per request shows the status and the absolute URL that its Location header resolves to. A relative Location such as /new-page is also shown as received. The summary gives the hop count, redirect count, final status, elapsed time, observation time and deployment region. Copy chain puts the status sequence, resolved destinations, hop count, elapsed time, observation time and any stop explanation on your clipboard as plain text; it does not include the raw Location headers.
What is the difference between 301, 302, 307 and 308?: 301 and 308 indicate permanent redirects; 302 and 307 indicate temporary redirects. Clients may change POST to GET after 301 or 302, while 307 and 308 preserve the method and body. A 303 directs a retrieval using GET or HEAD. This checker always sends HEAD at every hop, including after a 303. These status codes describe HTTP behavior; they do not prove which URL a search engine indexes or selects as canonical.
Why did my check stop before the end of the chain?: The page names the way the walk ended and keeps every hop it observed before that. A loop means the chain returned to a URL it had already requested, and it tells you which hop it went back to. The hop limit means the chain was still redirecting after ten requests, and it gives you the next URL so you can carry on from there. The deadline means the configured eight-second request budget was exhausted. A refused HEAD means the server answered 405 or 501 to the method this tool uses. A blocked target means the next URL is one this tool will not request: a host that resolves to an address off the public internet, a scheme other than http or https, a port other than 80 or 443, or a URL carrying a user name or password. A redirect with no Location header means a hop answered with a redirect status and sent nowhere to go next. A connection failure means a name stopped resolving part way down the chain, a connection could not be made, or the response headers were larger than the 8KB this tool reads. When the very first request is the one that fails there is no chain to show, so the page gives you the reason on its own.
Why does it say the server refused HEAD, and why not just use GET?: A 405 Method Not Allowed or 501 Not Implemented response stops the chain as a refused HEAD. A 401 or 403 ends the chain with that status and a note that HEAD may differ from GET. The checker never retries with GET, so it cannot determine whether the same URL would load normally in a browser.
Why will it not check localhost, an internal host name or an odd port?: Because a server that follows a URL you give it will also follow a redirect somebody else chose, and the classic abuse of that is pointing it at the machine it runs on or at a cloud metadata address. Every host name is resolved and every address it answers with is checked before a connection is made, at the first URL and again at every hop, and anything private, loopback, link local, multicast, reserved or IPv4-mapped is refused by name. Connections are made on ports 80 and 443 only, and a URL carrying a user name or password is refused rather than sent.
Why does my browser end up somewhere else?: Because a browser does more than follow HTTP redirects. A page can redirect with JavaScript or a meta refresh after it loads, a site can route you by cookie, by sign-in state or by the country your address sits in, and none of that is visible in a response header. This page shows the HTTP redirects a plain HEAD request received from our deployment region at the time shown, which is a smaller and more exact thing. It is not a statement about what a search engine indexes or which URL it treats as canonical.
Is the result live, and do you keep the URL I check?: A result may reuse the server's five-minute cache only when the starting URL and every value in the observed chain contain no query string. The result shows when the observation was made. Query strings in later Location headers or unrequested destinations also exclude the whole result from caching; live results and Copy chain keep their observed values. The checker code does not log requested URLs, paths or queries. Your browser remembers the last input in local storage; Start over clears it.
Is there a limit on how many redirects it follows?: The checker follows at most ten requests, uses an eight-second deadline for the whole chain including DNS lookups, and accepts response headers up to 8KB per hop. A DNS lookup that outlasts the deadline cannot start another connection. The browser stops waiting for the server response after fourteen seconds. When the hop limit is reached, the stop explanation includes the next URL that was not requested.
Can I check HTTP-to-HTTPS and www redirects?: Yes. Enter a full starting URL such as http://example.com/path to inspect an HTTP-to-HTTPS redirect, or https://www.example.com/path to inspect a www redirect. A bare domain defaults to HTTPS. The chain shows changes of scheme, host and path that the server returns to HEAD. It checks one starting URL, without comparing every www and non-www variant or auditing TLS certificates.
Can a redirect chain end with a 404?: Yes. A 404 Not Found is shown as the final status of that HEAD request. It is not itself a redirect, and the checker does not create redirects or repair missing pages.
Can I use this redirect checker in Chrome?: You can use the URL form in Chrome without installing an extension. Your browser submits the check to our server and displays the observed HTTP chain. An internet connection is required; the result does not reproduce your browser cookies or sign-in state.
Can I check URLs in bulk or download a report?: The form accepts one starting URL per check. It does not accept a batch of URLs or provide file, PDF or ZIP downloads. Copy chain is the available text output.

Observed server HTTP redirects only, by HEAD request from our deployment region at the time shown. JavaScript and meta-refresh redirects, cookie or geography specific routing and authenticated flows are outside what this can see.