HTTP Headers Checker Guide: Read What a Server Really Sends

Every web response carries two parts: the content, which is the page, image, or data itself, and the headers, which are metadata describing that content and instructing the browser how to handle it. Headers are invisible in normal browsing, but they decide whether a page is cached or refetched, whether scripts from other sites may run, whether the browser treats a response as a page or a download, and whether a connection must use HTTPS. The HTTP Headers Checker reads a header set you paste and explains it: which headers are present, which important ones are missing, and which values look wrong. It works on pasted text, and that boundary matters: it analyses the headers you show it, it does not fetch your live site, so the headers you paste must be the ones your server actually sends.

Headers fall into families, and learning the families makes a long header list readable. Security headers tell the browser how to protect the page: Strict-Transport-Security forces HTTPS, Content-Security-Policy limits where scripts and styles may load from, X-Content-Type-Options stops the browser guessing a content type, and X-Frame-Options or frame-ancestors control whether the page may be embedded in another site. Caching headers tell the browser and intermediaries how long a response may be reused: Cache-Control with a max-age, and validators such as ETag and Last-Modified that let the browser ask whether a cached copy is still fresh. Content headers describe the response itself: Content-Type names the format and character set, Content-Length gives its size, and Content-Encoding names any compression applied. A healthy response has sensible entries from each family; a response missing a whole family is a finding, even if the page itself looks fine.

How to read a header set

Read the set in three passes. First, check identity and content: the status line, Content-Type, and Content-Length. A page served with the wrong content type, or with no character set declared, can be misinterpreted by browsers in ways that range from garbled text to security issues. Second, check security headers: is HSTS present with a sensible max-age, is a content security policy present, and are framing controls set? Missing security headers do not break a page, which is exactly why they go unnoticed: the page works, and the protection is simply absent. Third, check caching: does Cache-Control allow reuse of static files for a sensible period, and does it prevent caching of private or dynamic pages? A page that should be cached but is not wastes bandwidth on every visit; a private page that is cached may be shown to the wrong visitor. Note the exact spelling of each header name as you read: a misspelled header, such as Conten-Security-Policy, is silently ignored, and the checker is the safety net that catches what the eye skips.

Worked example

Take a sample header set, with values clearly labelled as an illustration. It contains 14 headers, of which 2 are security headers, 3 are caching headers, and the rest describe content and server details. A reasonable target for a public page might be 4 security headers, so the set is short by 2, which is half the target, since 2 divided by 4 is 0.5. Its Cache-Control reads max-age of 3600, which is 1 hour, since 3600 divided by 60 is 60 minutes, and 60 minutes is 1 hour. For a stylesheet that changes rarely, raising that to 604800, which is 7 days, since 604800 divided by 86400 is 7, would cut repeat downloads substantially: a visitor returning daily would download the file once a week instead of once an hour, saving 6 downloads out of 7, or about 86 percent, since 6 divided by 7 is roughly 0.857. The sample set also contains a header spelled X-Content-Type-Option, missing its final s: browsers ignore it entirely, so the page has no content-type protection despite the apparent entry. The checker flags all three findings, missing security headers, short cache life, and the misspelling, and each has a different fix: add the headers, lengthen the cache for static files, and correct the spelling. None of them would have been visible from the page itself.

Mistakes to avoid

The first mistake is pasting headers from documentation, a tutorial, or another site and treating the result as a report on your own server; always paste headers copied from your server's real response. The second is pasting headers without redacting private values: Set-Cookie headers and authorisation headers can carry tokens, so strip them before pasting. The third is adding security headers without testing: a strict content security policy can break legitimate scripts, and a framing ban can break legitimate embeds, so test in a staging environment first. The fourth is caching dynamic or private pages aggressively, which can serve one visitor's content to another. The fifth is treating a checker pass as a security guarantee: headers are one layer, and they do not fix insecure application code, weak authentication, or an invalid certificate.

Putting it into practice

Make header checks part of deployment: copy the real response headers for the homepage and one dynamic page, paste them into the checker, and review the three families before every release. Keep a short list of the headers your site should send, with their intended values, so a missing or changed header is a visible deviation rather than a vague feeling. Re-check after server, CDN, or platform changes, which are the moments headers most often disappear. For related checks, the HSTS Checker examines the transport security header in depth, the CSP Checker examines content policy, and the HTTP Compression Checker examines compression headers. The companion guide on CSP Checker covers one of the most powerful headers in detail, and the HSTS Checker post in this series covers another.

Key points

• Headers are metadata a server sends with every response, separate from the page content
• Security headers, caching headers, and content-type headers each protect a different thing
• A misspelled header is silently ignored by browsers, not reported to visitors
• A checker reads pasted headers, it does not fetch a live site or prove the server configuration

In short: headers are the server's instructions to the browser, and they are invisible until something goes wrong. Read them in families, watch for missing security headers and misspellings, set caching deliberately, and re-check after every change to the server that sends them.