HTTP Status Checker
Check an HTTP response status when the target permits browser CORS, useful for troubleshooting accessible web endpoints.
Your result will appear here.
HTTP Status Checker online
Fetch a URL from your browser and see the HTTP status it ultimately returns — after redirects — to distinguish "site down" from "site moved" from "browser blocked".
How to use this tool
- Enter a full URL starting with http:// or https://.
- Click Run Tool. Your browser requests the URL, following redirects, and reports the final status code.
- Read the code: 2xx reached, 3xx redirected, 4xx refused the request, 5xx server error — with the caveat below.
Common uses
Checking whether a link you are about to share is alive, verifying a redirect after a site migration, confirming a URL returns 200 before submitting it to a search engine, and first-pass triage when users report a page "not working".
How it works
The check is a real fetch made by your own browser, which shapes what it can see. It follows redirects and reports the final status — but browsers enforce CORS: most sites do not grant other pages permission to read their responses, so the fetch may fail entirely even though the site is fine. In that case the tool can only report the failure mode, not a status. A reported 200 or 404 is trustworthy; a blocked fetch means "unverifiable from a browser", not "down".
Worked example
Point the checker at an http:// address of a site that has moved to HTTPS and the result typically comes back 200 — the browser followed the 301 to the secure version and reports the destination. Point it at a URL on a server that sends no CORS headers and the request errors out despite the server being healthy: the two outcomes look opposite to the site's real state, which is why the tool describes the fetch, not just a number.
Privacy and browser processing
Your browser requests the URL directly; no intermediary service is used and nothing is stored by this site.
Frequently asked questions
Why does it fail on sites that open fine in a tab?
CORS. Reading a response from another origin requires that origin's permission headers, which most sites do not send to random pages. Opening a tab needs no such permission. Server-side checkers (curl -I from a terminal) bypass this entirely.
Does it show the redirect chain?
The browser collapses redirects into the final response, so you see the destination status, not each hop. For hop-by-hop chains, curl -IL or your host's tooling shows every step.
What does a 403 here usually mean?
Either the server genuinely refuses (bot protection, geo rules, hotlink defence) or it refused this cross-origin read. Both are reported as failures of the fetch; distinguishing them needs a direct request from a terminal or the server's logs.
Can I check pages behind a login?
The fetch carries your browser's cookies for that site in some configurations, but CORS still gates reading the answer. In practice, treat this as a public-URL checker.
Is the URL I check sent anywhere?
Your browser requests the URL directly — the target site sees a normal visit from your IP. No third-party service is involved and nothing is stored here.