Server Header Checker
Enter a URL and view the HTTP response headers your browser is allowed to read.
Example
Input URL:
https://httpbin.org/get
Output (CORS-enabled endpoint):
Status: 200 OK
Final URL: https://httpbin.org/get
Type: cors
Readable response headers:
access-control-allow-origin: *
content-type: application/json
How it works
The tool runs a fetch() from your browser and lists the response status plus every readable header. Because of the browser same-origin policy, only same-origin or explicitly CORS-exposed headers are visible.
Good to know
The Server Header Checker fetches a URL straight from your browser and prints the HTTP response status, the final (post-redirect) URL, the response type, and every header your browser is permitted to expose to JavaScript. It is aimed at web developers, QA testers, and anyone debugging an API or static endpoint who wants a quick header peek without installing anything or opening DevTools.
Reach for it when you are checking whether your own site or API returns the right content-type, caching, or CORS headers, or when you want to confirm a redirect chain resolves to the expected final URL. Because the request runs client-side, it is especially handy for inspecting same-origin endpoints or APIs you have deliberately configured with permissive CORS, where it shows exactly what an in-page fetch() call would see.
Read the output top-down: the Status line is the numeric code plus reason phrase, Final URL reveals where redirects landed you, and Type tells you whether the response was basic (same-origin), cors, or opaque. Under "Readable response headers" the list is alphabetically sorted. An empty or short list does not mean the server sent nothing; it means the browser is hiding fields it is not allowed to surface.
The key caveat: this is a browser tool bound by the same-origin policy, so for most third-party URLs you will see few or no headers, or a fetch error. To inspect every header for an arbitrary URL, pair this with a server-side checker or a terminal. The built-in 15-second timeout will abort slow requests, and a "Type: opaque" result signals a cross-origin response with no CORS allowance.
Frequently asked questions
Why do most sites show no headers or a fetch error?
Browsers enforce the same-origin policy: unless the server sends Access-Control-Allow-Origin (and Access-Control-Expose-Headers for specific fields), JavaScript cannot read a cross-origin response's headers, and the request may fail outright. This is a browser security restriction, not a bug in the tool.
How can I see all headers for any URL?
Use a server-side checker or a command line, e.g. curl -I https://calccafe.com, since servers are not bound by the browser's CORS rules. This client-side tool only sees what the browser is permitted to expose.
Is my data uploaded anywhere?
No — this tool runs entirely in your browser. Your input never leaves your device and it works offline once loaded.
Is it free?
Yes, completely free with no sign-up and no limits.
People also ask
What is an HTTP response header?
An HTTP response header is a name-value pair the server sends back with a response to describe it, such as content-type, cache-control, or set-cookie. Headers carry metadata about the content, caching, security, and the connection rather than the page body itself.
What does the response type 'opaque' mean?
An opaque response comes from a cross-origin request made without CORS, typically a no-cors fetch. The browser deliberately hides its status, headers, and body from JavaScript, so the tool can confirm the request happened but cannot read any details.
Why can't JavaScript read all response headers even for CORS requests?
For cross-origin responses, browsers only expose a short safelist of headers (like content-type and cache-control) plus any the server explicitly lists in Access-Control-Expose-Headers. Other fields stay hidden unless the server opts to reveal them.
How do I check security headers like Content-Security-Policy or X-Frame-Options?
These headers are usually not on the CORS safelist, so a browser-based checker often will not display them for third-party sites. A server-side header checker or a curl -I command will show them regardless of CORS rules.
What is the difference between checking headers in the browser versus with curl?
A browser fetch is constrained by the same-origin policy and CORS, so it sees only permitted headers. curl and other server-side tools make the request directly without those restrictions, so they return the complete set of response headers for any URL.
How can I read request headers instead of response headers?
This tool only reports response headers the server sent back. To inspect the request headers your browser sent, open the browser's developer tools Network tab and select the request, or use a server-side endpoint that echoes them.
Does following a redirect change which headers I see?
Yes. With redirect set to follow, the tool reports the headers of the final destination, and the Final URL line shows where the chain ended. Headers from intermediate redirect hops are not displayed.
Why did my header check time out or fail?
The tool aborts requests after 15 seconds, so a timeout points to a slow or unreachable server. A fetch failure usually means a CORS block or network error, since the browser refuses to read cross-origin responses the server has not allowed.
Related tools