gizmobench

Redirect Checker

Paste a URL and this page follows its redirects from our server, one HEAD request at a time, and shows you the chain: every status code, the Location header each hop returned, the absolute URL that header resolved to, and where the chain finally lands. It follows at most ten hops and gives the whole walk eight seconds, and when it stops early it names the reason: a loop back to a URL already requested, the hop limit, the deadline, a refused HEAD, a blocked target, a redirect with no Location header, or a connection failure part way down the chain. Relative Location headers are resolved against the hop that sent them, so a chain of bare paths reads as real URLs. No body is ever downloaded, no account is needed, and the URL you check is not written to any log.

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. Each line carries the status the server returned, the Location header it sent, and the absolute URL that header resolves to, so you can see a bare path like /new-page as the full URL the next request went to. Under the chain you get the number of hops, how many of them were redirects, how long the whole walk took, the time it was observed and the deployment region it was observed from. The readout repeats the hop count, the final status and the total time, and the Copy chain button puts the whole thing on your clipboard as plain text.
What is the difference between 301, 302, 307 and 308?
301 and 308 are permanent, 302 and 307 are temporary. The pair that matters in practice is what happens to the method: 307 and 308 preserve the method and body, so a POST stays a POST, while 301 and 302 are rewritten to GET by most clients even though the specification does not require it. 303 always makes the next request a GET, which is how a form submission ends up on a result page. This tool labels each hop with the status it got and what that status means for the request after it.
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 whole walk passed eight seconds. 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?
Some servers answer 405 Method Not Allowed, 501 Not Implemented or 403 to a HEAD request even though the same URL answers a GET normally. This tool sends HEAD and never quietly retries as GET, because a GET downloads a page you did not ask for and can trigger an action on the other end. When HEAD is refused, the page says so and stops, and that is a limit of the check rather than a fact about the URL.
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?
Every check is made when you ask for it. A URL with no query string may be answered from a five minute cache on the server, and the time beside the result is the time the check was actually made, not the time it was served, so you can always see how fresh it is. A URL that carries a query string is never cached and never stored, because query strings carry sign-in tokens and one time links. The route does not log the URL, the path or the query. Your own browser remembers the last URL in the box so the field is filled when you come back, and the Start over button at the top of the page clears it.
Is there a limit on how many redirects it follows?
Ten requests per chain, eight seconds in total, and response headers up to 8KB per hop. Those bounds are what makes it cheap enough to run for anyone without an account, and the page tells you when it hits one instead of pretending the chain ended. If a real chain is longer than ten hops, the last URL is shown so you can paste it back in and keep going.

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.