Web Dev Helpers
URL Redirect & Status Checker
Trace a URL's redirects - status code and response time per hop.
Input
One URL per line, up to 10. Follows 3xx redirects up to 10 hops per URL. HEAD is faster but some servers reject it or send different headers; GET is closest to what a browser sees. Runs via a rate-limited server-side fetcher on this domain.
About this tool
Paste up to 10 URLs and see the full redirect chain for each: every hop with its HTTP status code (color-coded 2xx / 3xx / 4xx / 5xx), the Location header, response time in milliseconds, Server header, Content-Type and Set-Cookie count. Handy for auditing 301 vs 302 use, catching redirect loops, verifying HTTPS upgrades, tracking down slow hops or seeing where a shortened URL actually points. Uses a small server-side fetcher on this domain (rate-limited to 200 checks per browser per day) because browsers can't observe intermediate redirect statuses from JS.
FAQs
GET or HEAD - which should I use?
GET is closest to what a browser sees and works everywhere; use it if you want the full picture. HEAD is faster and cheaper (no body downloaded), but some servers return a different status for HEAD than for GET, or reject HEAD outright with a 405. If GET and HEAD disagree, the browser-visible result is GET.
Why does it stop after 10 redirects?
That's the same cap most browsers enforce (Chrome / Firefox refuse to follow more than around 20; 10 is a practical safety net that still surfaces long chains). If your chain is legitimately longer than 10 hops, something is wrong - fix it rather than raise the limit.
Does this handle meta-refresh or JavaScript redirects?
No - only HTTP-level redirects (3xx with a Location header). meta http-equiv="refresh" and window.location.href are ignored, because they require rendering the page. For those, use the browser DevTools Network tab.
Why do I sometimes see a 200 for a URL that clearly redirects?
That URL is probably serving a soft redirect - HTML with a meta-refresh or JS window.location - not an HTTP 3xx. The server returns 200 and the browser navigates client-side. This checker only reports what the server sends over HTTP.
Can I check private / localhost URLs?
No. The server-side fetcher rejects private IPs, localhost hostnames, non-standard ports and reserved TLDs to prevent SSRF. If you need to check an internal URL, use curl -IL from a shell on that network.