Redirect checker

See where a URL ends up and whether it redirects. Free, no upload. 1 GB max · Up to 1 GB · Processed locally, never sent to a server.

After a redesign, a change of domain or the removal of a whole section, the same question comes back: does this old address still lead anywhere, and where to. This tool sends a request to the address you enter and returns five rows: the URL tested, the final URL, whether or not a redirect took place, the HTTP status obtained at the destination, and the read method used.

Like the page audit, this checker works over the network: the address you enter leaves the browser in order to be queried. The direct attempt goes out from your machine; if it fails, a public relay, api.allorigins.win, takes over from its own servers. The "Method" row of the table says which of the two paths answered.

One limit comes from the technique involved. The request is set to follow redirects in a single move: the browser chains the hops and reports only the arrival. The intermediate detail, the 301 then 302 then 200 sequence, is not exposed to the code of the page, and the tool says so underneath its own result.

How to use it

  1. Enter the address to test The field expects the old address by preference, the one whose fate you want to know. The https:// prefix is added if you leave it out, and input that does not parse is rejected.
  2. Click "Check redirects" The button switches to "Checking…". The direct attempt gets ten seconds, the public relay fallback fifteen more before giving up.
  3. Compare the URL tested with the final URL The gap between the two rows says everything: a move from http to https, www added or dropped, a trailing slash, or an entirely different path in the case of a genuine redirect.
  4. Read the "Redirect" row It states in plain words whether the address ends up somewhere else or answers directly, so you do not have to interpret status codes yourself.
  5. Check the status and the method The status is annotated "OK" below 300, "redirect" between 300 and 399, "error" above that. The method says whether the read was direct or went through the relay.

The request goes out to the site being tested

There is nothing local about this tool: checking a redirect means triggering it. The first request leaves your browser, with your IP address. Plenty of servers do not return the cross-origin authorization headers that the CORS mechanism requires; when that happens the browser refuses to hand the response to the code of the page, and the attempt counts as a failure even though the site answered perfectly well.

The automatic fallback then goes through api.allorigins.win, a public third-party service. It is that service which queries the address, from a data centre, with its own IP. The consequences are concrete. A members-only page returns the sign-in screen, since no session cookie travels to another domain. An application firewall of the kind run by Cloudflare or Akamai may put a challenge page in front of a hosting provider's IP address, or refuse it outright. A staging environment protected by a password or by an allow-list stays out of reach. This tool reports on public addresses.

301, 302, 307, 308: which one, and when

A 301 announces a permanent move. It is the code for a migration: the engine replaces the old address with the new one in its index and passes on the signals accumulated. Browsers cache it with some enthusiasm, which makes a 301 issued by mistake painful to undo for visitors who have already received it. A 302 says the opposite, a temporary detour: the original address stays the reference, which suits a page under maintenance or a short-lived campaign.

The 307 and the 308 are the strict versions of the two above. Historically, a 301 or a 302 applied to a form submission could turn the request into a plain retrieval and lose the data sent with it. The 307, temporary, and the 308, permanent, both require the method and the body of the request to be preserved. For a page that is simply read, the 301 remains the usual choice and the one handled best everywhere; for a technical endpoint that receives data, the 308 avoids the unpleasant surprise.

What a chain of redirects costs

Every hop is a full round trip: DNS resolution if the host changes, connection setup, TLS negotiation, request, response. On a mobile link the bill runs into hundreds of milliseconds before the first useful byte arrives. The classic chain — http to https, then non-www to www, then old page to new page — makes three hops where a well-written rule would make one.

The cost does not fall on the visitor alone. Crawlers follow a limited number of hops before giving up, around ten in practice, and a browser stops at roughly twenty and reports a redirect loop. The useful rule fits in one sentence: point each old address straight at its final destination, rather than letting redirects stack up through one redesign after another.

Reading the result without getting it wrong

The status shown is the one at the destination, not the one on the redirect. An old page correctly redirected with a 301 therefore appears as HTTP 200, with the "Redirect" row set to yes: that is the expected outcome, not a contradiction. A status between 300 and 399 only shows up when the chain could not be followed to the end.

In relay mode, the presence of a redirect is deduced by comparing the address tested with the address arrived at, trailing slash aside; a redirect that landed back on the same address would therefore go unnoticed. And only redirects at the HTTP protocol level are visible: a jump performed by a meta refresh tag or by a script does not show up here, since the page is neither rendered nor executed.

Frequently asked questions

Why is the status 200 when my page is redirected?

Because the request follows the chain to the end and reports the code of the destination. The "Redirect" row flags the move; the 200 simply confirms that the page it lands on exists.

Can I see the 301 then 302 then 200 detail?

Not from a browser: the intermediate hops are not exposed to the code of the page. You need a server-side tool or a command-line request that prints the headers of each step.

What does the "Read via public proxy" note mean?

That direct access was refused and the request went through api.allorigins.win instead. The site saw the IP address of that service rather than yours, which can change the response it sends back.

Is a meta refresh redirect detected?

No. Only redirects at the HTTP protocol level are visible. A jump written into the HTML or triggered by a script is neither interpreted nor followed by this tool.

Should I choose 301 or 308 for a permanent change?

A 301 is enough for pages that are simply read and remains the code handled most universally. A 308 becomes necessary when the address receives data and the request method has to be preserved.

My staging site returns an error, why?

Because it is most likely filtered by password or by IP address. Neither your session nor the public relay has access to it: this tool can only check addresses that are open to the public.

How do I find out where a shortened or tracking link really leads?

Paste the short address into the field: the "Final URL" row gives the page you end up on, and the "Redirect" row confirms in plain words that a move took place. Bear in mind that the link is genuinely followed to get that answer — your browser, or the public relay api.allorigins.win when direct access is refused, actually requests it. A single-use invitation link or a click counter can therefore be consumed by the check itself.

Can I check a whole list of URLs at once after a site migration?

No. The field takes one address per check and the result table is rebuilt each time, so a migration has to be gone through URL by URL. Nothing needs to be installed, there is no account and no daily quota, which makes a list of a few dozen addresses workable; past that, a crawler or a command-line request that prints the headers of each step is the right tool.

Will the tool tell me if a URL is caught in a redirect loop?

Not by name. The request follows the chain in a single move and reports only the arrival, so a loop surfaces as a failed check rather than as a diagnosis; a browser gives up after roughly twenty hops. Crawlers are stricter still, abandoning a chain after around ten, which is why the useful rule is to point each old address straight at its final destination instead of letting redirects stack up through one redesign after another.

Similar tools

Discover other tools

Categories