HTTP Headers Checker
Inspect response headers when the target permits browser CORS, including content type and other accessible HTTP metadata.
Your result will appear here.
HTTP Headers Checker online
Fetch a URL from your browser and inspect the response headers it returns — server, caching, content type and security headers — when the target site allows cross-origin reads.
How to use this tool
- Enter a full URL starting with http:// or https://.
- Click Run Tool. Your browser fetches the URL and lists the response headers it is permitted to show.
- Look for cache-control, content-type, server and the security headers (strict-transport-security, content-security-policy, x-content-type-options).
Common uses
Auditing a site you run for missing security headers, checking cache headers after a deploy, verifying a CDN is in the path (cf-cache-status and friends), and confirming content-type and encoding before debugging a rendering bug.
How it works
Headers are the metadata a server sends ahead of every response: what the content is, how long it may be cached, which server and CDN handled it, and a set of security directives. This tool fetches the URL with your browser and reads the response headers — subject to CORS: the target must allow cross-origin reads, and even then the browser only exposes a safelisted subset unless the server explicitly exposes more. Your own sites can be made readable by adding Access-Control-Expose-Headers; strangers' sites mostly cannot be inspected this way.
Worked example
Fetch a well-configured site and you might read back: content-type: text/html; charset=utf-8, cache-control: max-age=3600, strict-transport-security: max-age=31536000. Fetch a typical third-party site with no CORS grant and the request fails outright — the headers exist, but your browser will not show them to a page from another origin. That boundary is the tool's main limitation and it is the browser's rule, not the site's verdict.
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 can I not read most sites' headers here?
Cross-origin reads need the target's permission (Access-Control-Allow-Origin) and header exposure is opt-in beyond a small safelist. For arbitrary sites, use curl -I or browser DevTools on the site itself, where no cross-origin boundary applies.
Which security headers should my site send?
The working set: strict-transport-security (HTTPS only), content-security-policy (tailored, not copied blindly), x-content-type-options: nosniff, referrer-policy, and a frame-ancestors or x-frame-options policy. Presence is a start; values are where the protection lives.
What does cf-cache-status / x-cache tell me?
Whether a CDN served the response from cache (HIT), fetched it from your origin (MISS/DYNAMIC) or revalidated it. After a deploy, a stubborn HIT with a long cache-control explains "my change is not live" better than any redeploy.
Are request headers shown too?
No — the tool reports what the server answered. The request headers your browser sent (user agent, accept-language) are visible in tools like User Agent Parser and your browser's DevTools network tab.
Is the URL I check sent anywhere?
Your browser fetches it directly; the target sees an ordinary request from your connection. Nothing is proxied or stored by this site.