URL redirect checker

URL redirect checker is a free tool that identifies 301 and 302 redirects for a specific URL and follows a redirect chain for up to 10 steps.

What is a URL redirect?

A URL redirect is an HTTP response that tells a browser, search engine crawler or other client to request a different address. The response normally contains a 3xx status code and a Location field whose value is a URI reference, which may be relative.

A 301 status code means the resource has moved permanently. It is commonly used after changing a page address, moving from HTTP to HTTPS or consolidating duplicate URLs. A 302 status code means the resource has been found elsewhere, but the move is generally treated as temporary.

HTTP also defines other redirect codes, including 303, 307 and 308. The distinction can affect how clients repeat requests, particularly for methods such as POST. For routine web page redirects, 301 and 302 remain common and are the codes this checker is intended to identify.

How do I check a URL redirect?

The Status code field expects an HTTP status code, such as 301 or 302. The checker works on the server and checks up to 10 redirect steps.

The input travels to the server over HTTPS and is not stored.

Which redirects does the checker identify?

The checker identifies 301 and 302 redirects. A 301 indicates a permanent redirect and a 302 indicates a temporary redirect.

A sequence that alternates between two addresses is a redirect loop. A long sequence of changes between HTTP, HTTPS, www, non-www and trailing-slash variants is a redirect chain. This tool stops after no more than 10 steps, so it cannot establish the eventual destination of a longer chain.

Troubleshooting common redirect problems

Redirect checks are useful when the browser's final address hides the intermediate responses. They can separate an HTTP configuration fault from a DNS, application or caching problem.

• A migrated page still opens at its old address. Check the old URL directly. A 301 should point towards the intended replacement rather than a generic home page or another obsolete address.
• HTTP and HTTPS keep switching. Test both versions. Conflicting rules in a web server, content delivery network or application can send HTTPS back to HTTP while another layer immediately reverses it.
• An email link does not reach the expected landing page. Check the full URL copied from the message, including its query string. Tracking services often add one or more redirects before the final page, and a broken intermediate destination can stop the chain.

For domain moves, test representative page paths rather than checking only the home page. A correct home-page redirect does not prove that product pages, articles and uploaded files have equivalent destination rules.

Punctuation and spaces also matter. Raw spaces are not valid in a URL and normally need percent-encoding, such as %20. A fragment beginning with # is handled by the browser and is not sent in the HTTP request, so changing the fragment alone does not select a different server-side redirect. Internationalised domain names may be represented in their ASCII Punycode form, while non-ASCII path characters are encoded into bytes, normally using UTF-8, and the relevant bytes are percent-encoded during transmission.

Why does a correct redirect still look wrong?

A correct redirect can appear wrong because browsers, DNS resolvers, proxy servers and content delivery networks may use cached information. Permanent redirects are especially likely to remain visible in a browser cache after the server rule has changed.

A server-side checker does not share your browser's local redirect history, although the target website or its CDN may still return a cached response.

DNS changes introduce a separate delay. Recursive resolvers may retain the previous IP address until the record's time to live expires. During that period, different networks can reach different servers and receive different redirect rules. The phrase "DNS propagation" describes this uneven cache expiry rather than a single worldwide update event.

If the domain has recently moved, compare the DNS record, CDN configuration and origin server rules. A Google Cache Checker may provide context about an older indexed or cached page, while a Website hosting checker can help identify where the domain currently appears to be hosted. Neither replaces an HTTP redirect check.

Frequently asked questions

Can a 301 redirect be changed later?

Yes, the server configuration can be changed, but clients may continue using a cached 301 response for some time. Test in a fresh browser profile and clear relevant CDN caches where you control them. Avoid using 301 during early testing if the destination is still likely to change.

Does a redirect pass the URL query string to the destination?

Only if the redirect rule and its generated Location value preserve it. Some systems copy the original query string automatically, while others replace or remove it. Check a realistic URL containing harmless test parameters rather than assuming all variants behave alike.

How is my input handled?

The work is done on the server. The input travels to the server over HTTPS and is not stored.

Will this check JavaScript or meta refresh redirects?

The checker identifies 301 and 302 HTTP redirects, checking up to 10 redirects.

Can I check redirects from the command line?

Yes. The curl command can display response headers, and its redirect-following option can request subsequent locations. This is useful when you need repeatable checks from a particular machine or network, especially after changing DNS or firewall rules.