Free HTTP Header Checker
Inspect all HTTP response headers, analyse security headers, and get a security grade for any website.
What This Tool Inspects
Every HTTP response header your server sends — security-graded and explained in plain language.
How to Read the Headers You Get Back
A typical response carries fifteen to thirty headers, and most of them answer one of a few questions: what is this, may it be cached, who served it, and what should the browser remember. These are the ones worth reading first.
| Header | What it tells you |
|---|---|
| Content-Type | What the body is and how its text is encoded: text/html; charset=utf-8 for a page, application/json for an API. A wrong type is behind many "it downloads instead of opening" bugs. |
| Cache-Control | Whether browsers and CDNs may store the response and for how long. no-store forbids caching, no-cache allows storing but forces a check with the server first, and max-age gives a lifetime in seconds. |
| Age | Seconds since a shared cache fetched this copy from your server. Present means you are reading a cached copy; a large number means an old one. |
| ETag / Last-Modified | Validators that let a browser ask "has this changed?" and get a small 304 Not Modified instead of the full body again. |
| Vary | Which request headers produce a different response, so caches keep separate copies. Vary: Accept-Encoding is normal; Vary: Cookie or Vary: User-Agent can split the cache into so many copies that a CDN rarely gets a hit. |
| CF-Cache-Status, X-Vercel-Cache, X-Cache | Cloudflare, Vercel, and CloudFront or Fastly respectively, reporting HIT or MISS — whether the CDN answered from its own cache or went back to your server. |
| Content-Encoding | The compression applied, such as br or gzip. It only appears when the client said it accepts compression, so test with the Accept-Encoding curl command below. |
| Server, X-Powered-By, Via | Who produced or relayed the response. Useful for knowing which layer to debug; a version number here is information an attacker can use and you gain nothing from publishing. |
| Set-Cookie | A cookie the browser should store, with flags such as Secure, HttpOnly and SameSite that limit how it can be sent and read. A response can set several. |
| Location | Where a 3xx redirect sends the browser next. Browsers follow it only on a redirect status. |
Security headers are a separate reading exercise, because the question there is whether the value is strong enough, not just what it says. The Security Headers Checker grades them, and the reference pages explain each value in full — start with Strict-Transport-Security and Content-Security-Policy, the two that matter most.
Checking HTTP Headers with curl
Every header check comes down to the same request, and curl is the quickest way to make it yourself, from your own network, against any path. These are the commands worth keeping:
# Response headers only (sends a HEAD request) curl -sI https://example.com # The same headers from a real GET, body discarded curl -s -D - -o /dev/null https://example.com # Every hop of a redirect chain, with each hop's headers curl -sIL http://example.com # One header, matched case-insensitively curl -sI https://example.com | grep -i '^cache-control' # As a browser that accepts compression would see it curl -s -D - -o /dev/null -H 'Accept-Encoding: br, gzip' https://example.com
Prefer the GET form when an answer looks odd. -I sends a HEAD request, and some applications and frameworks answer HEAD differently from GET — a different status, missing cookies, or no caching headers at all. On Windows, curl.exe ships with the system and takes the same flags; use -o NUL in place of -o /dev/null. Call it as curl.exe in Windows PowerShell, where plain curl is an alias for Invoke-WebRequest.
What This Checker Actually Requests
Knowing exactly what was sent explains most surprising results. The checker makes a single GET request to https:// plus the hostname you enter, at the root path — anything after the hostname is dropped. It follows up to five redirects and shows the status, final URL and headers of the last response. It identifies itself with its own User-Agent rather than a browser's, and sends no cookies.
Three consequences follow. Headers set only on particular paths, such as an API route or a static asset, will not appear — use curl against that URL. A firewall or bot filter that blocks unfamiliar clients can return a 403 here that a browser never sees, which says more about the filter than the site. And the plain-HTTP hop is not shown, so if you need to confirm that http:// redirects straight to HTTPS, the Redirect Checker traces every hop.
Problems a Header Check Diagnoses
Many bugs that look like application faults are visible in the response headers before you open a line of code:
Visitors still see the old version after a deploy
Look at Cache-Control and Age. A long max-age on a URL that does not change between deploys lets browsers and CDNs keep the old copy until it expires, and a large Age with a cache status of HIT means you are reading the CDN's copy, not your server's. Give HTML a short lifetime or no-cache, reserve long lifetimes for files with a content hash in the name, and purge the CDN after a deploy.
A file downloads instead of displaying, or a script is blocked
Check Content-Type. A page served as application/octet-stream is treated as a download. With X-Content-Type-Options: nosniff set, browsers also refuse to run a script or apply a stylesheet whose declared type does not match, so a JavaScript file served as text/plain stops working. Fix the MIME mapping on the server rather than removing nosniff.
The same header appears twice
Usually the application and a proxy in front of it both set it. What happens next depends on the header: a browser that receives two Strict-Transport-Security headers honours only the first, so the stronger one may be the one ignored. For Content-Security-Policy it is worse: every policy delivered is enforced, so two policies allow only what both allow, and a resource permitted by one can still be blocked by the other. Decide which layer owns each header and remove it from the other.
A session cookie is missing its protections
Each Set-Cookie header lists its own flags. A session cookie without Secure can travel over plain HTTP, without HttpOnly it is readable by any script on the page, and without SameSite it relies on browser defaults. The Cookie Security Checker reviews each cookie's flags in turn.
A browser reports a CORS error but no CORS header appears here
That can be correct. Many servers send Access-Control-Allow-Origin only in reply to a cross-origin request, which carries an Origin header this checker does not send. Test it with the origin set, using the CORS Checker or curl -sI -H 'Origin: https://app.example.com' https://api.example.com.
Frequently Asked Questions
What is an HTTP response header?
Every time a server answers a request it sends a block of key-value pairs before the page itself. They carry the content type, how long the response may be cached, which cookies to set, and dozens of other instructions the browser acts on without showing you. Reading them is the quickest way to understand what a server is actually telling visitors.
What does Cache-Control tell me?
It decides how long browsers and CDNs may reuse a response. "max-age=31536000, immutable" means a year with no revalidation, which is right for a hashed asset and wrong for anything whose URL stays the same across deploys — that combination is why a changed file can keep serving its old version to returning visitors.
Should the Server header be hidden?
It names the software and often the version, which tells an attacker which exploits are worth trying. Hiding it is not a fix on its own and no substitute for patching, but there is rarely a reason to publish your exact version number either.
Why are the headers different from what my browser shows?
A browser usually shows the final response after redirects, while the first URL may have returned a 301 or 308 with its own headers. Checking the whole chain matters because a redirect that drops HSTS, or lands on a different host than you expect, is invisible if you only read the last hop.
Can I check the headers of a specific page or path?
Not with this checker: it requests the root of the hostname you enter and drops anything after it. Headers that only some paths set, such as on an API route or a static file, need a direct request — curl -s -D - -o /dev/null followed by the full URL shows exactly what that path returns.
Why does curl -I show different headers from the page itself?
curl -I sends a HEAD request, and some servers and frameworks answer HEAD differently from GET, with a different status code or missing caching and cookie headers. When the two disagree, trust the GET: curl -s -D - -o /dev/null with the URL makes a real GET and prints only the headers.
How is this different from the Security Headers Checker?
This tool shows you every response header as it is, for reading and debugging. The Security Headers Checker looks only at the headers that affect security — CSP, HSTS, X-Frame-Options and friends — and grades them A+ to F with specific fixes. Use this one to see what a server sends; use that one to find out whether it is sending the right things.
Re-check Your Security Headers Every Day
On paid plans, CertNotify re-checks the security headers on each monitored domain once a day and flags HSTS, CSP, X-Frame-Options or X-Content-Type-Options going missing after a deployment; a missing HSTS or CSP header is also sent as an alert. It does not compare header values, so a weakened policy is not flagged.