Cross-origin diagnostics

CORS Header Checker

Enter any URL and see exactly which response headers your browser's JavaScript is actually allowed to read across origins — and an honest explanation of why the rest stay hidden.

Enter a URL and run a real cross-origin fetch() from your browser. Nothing is sent to My Panda Toolbox.

Headers visible to JavaScript

0 headers
HeaderValue

This is not the server's full header list — it is what your browser lets script see. By default only the CORS-safelisted response headers (Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma) are readable cross-origin. Anything else, including custom headers, only shows up here if the server adds it to an Access-Control-Expose-Headers response header. To see everything the server actually sent, open DevTools → Network tab, or make the request server-side with curl.

Reachability result

Requests go straight from your browser to the URL you enter — nothing passes through our servers.

⇄

Real cross-origin fetch

Runs an actual fetch() against the URL from your browser, not a simulated result.

👁

Honest about limits

Explains exactly which headers browsers hide by design, instead of pretending to see more than JavaScript can.

🛡

Reachability fallback

A no-cors check tells you if a host is even reachable when a CORS-mode fetch fails outright.

How to use the CORS header checker

Point this tool at any API endpoint or page to see the real, browser-enforced view of its response headers.

  1. Enter a URLPaste the full URL of the endpoint you want to test, including the protocol.
  2. Check CORS headersClick Check to run a cross-origin fetch() and list every header your script can actually read.
  3. Fall back to reachabilityIf that fails, use the no-cors check to confirm the host is reachable at all.

Why browsers hide response headers

Cross-origin resource sharing (CORS) is a browser security mechanism, not a server-side firewall. It decides what a web page running JavaScript from one origin is allowed to read back from a request to a different origin. Even when a server responds successfully, the browser itself strips almost every header from the JavaScript-visible Headers object unless the server explicitly opts back in. That is why two tools hitting the exact same URL — one from a browser, one from curl — can report a completely different set of headers.

Safelisted response headers

Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma are always readable, no matter the CORS policy.

Access-Control-Expose-Headers

Any other header the server wants script to see — like X-RateLimit-Remaining — must be named explicitly in this response header.

A blocked request looks like any other failure

fetch() throws the same generic TypeError for a CORS block, a DNS failure or a dropped connection, by design.

DevTools sees more than script does

The Network tab shows the true response headers because it is not bound by the same JavaScript-facing restrictions.

CORS header checker FAQ

Common questions about what this tool can and cannot see.

Why can't I see every response header?

Browsers only expose a small set of CORS-safelisted response headers to JavaScript for cross-origin requests: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma. Any other header, such as a custom X-Request-Id, stays hidden unless the server explicitly lists it in an Access-Control-Expose-Headers response header.

Why does the check fail with an error instead of showing headers?

A fetch() call throws a generic TypeError when the browser blocks the response for CORS reasons, when the host does not exist, or when the connection fails outright. Browsers deliberately do not distinguish between these cases in script, since revealing more would itself leak information across origins.

What does the no-cors reachability check actually prove?

A request sent with mode: 'no-cors' resolves as an opaque response for almost any reachable server, regardless of its CORS policy. If that request also fails, the problem is very likely DNS, network connectivity or the server being down, rather than CORS.

Can this tool show me the full response like a server-side request would?

No, and it deliberately does not fake that. Everything here runs in your browser, which enforces the same-origin policy. For the complete, unfiltered set of response headers, use your browser's DevTools Network tab or a server-side request with curl.

Is any of this sent to your servers?

No. The request goes directly from your browser to the URL you enter. My Panda Toolbox never sees the URL or the response.

Explore more free tools: HTTP Request Header BuilderUser-Agent String ParserBrowser Feature DetectorAll Features