Network Header Checker

What HTTP response headers actually tell you

Every time a server answers a request, it sends back a block of response headers before the page content. These key–value lines describe the response: what type of content it is (Content-Type), how long the browser may cache it (Cache-Control), which software served it (Server), and — most importantly for an audit — which security policies the site enforces. A surprising amount about a site's posture is visible from the headers alone, without ever looking at the HTML. This tool fetches those headers and grades them against a checklist of the six headers that matter most for browser security.

The security headers this tool checks

A green check means the header is present; a red cross means it is missing, which is a finding worth investigating. Here is what each one does and why its absence matters:

A worked example

Suppose you enter https://example.com. The tool requests that URL through a proxy, reads the returned header block, and lowercases every header name so matching is case-insensitive (HTTP header names are case-insensitive by spec). It then walks the checklist: if it finds strict-transport-security: max-age=63072000, that line gets a green check and the value is shown beside it; if there is no content-security-policy key at all, that row turns red. Below the checklist, every header the server returned is listed in full, and a status line shows the HTTP status code (for example HTTP 200 OK). You read the result top-down: fix the red rows first.

Why a proxy is involved — and what that means for privacy

Browsers enforce the same-origin policy: JavaScript on this page cannot directly read the headers of a request to another domain unless that domain explicitly allows it with CORS. To work around that, this tool routes your request through a public CORS proxy (corsproxy.io, with allorigins.win as a fallback). That means the URL you check is sent to a third-party proxy service, not kept entirely on your device. Do not use it to probe internal or authenticated URLs that contain secrets in the path or query string. For public sites you are auditing, this is harmless; for anything sensitive, run a server-side tool like curl -I instead.

Common use cases

• Auditing your own deployment. After adding security headers in your web server or CDN config, confirm they actually reach the browser — a typo in an Nginx or Cloudflare rule often means the header silently never ships.
• Learning from well-configured sites. Check a major bank or tech company and study how they set Content-Security-Policy and HSTS max-age values.
• Debugging caching. The full header list shows Cache-Control, ETag, and Age, which explains why a stale asset keeps loading.
• Verifying HTTPS enforcement. A present HSTS header with a long max-age and includeSubDomains is the gold standard.

Common mistakes and limitations

• Reading absence as a vulnerability. A missing header is a weakness, not an active exploit. Context matters: a static brochure site needs less than a banking portal.
• Trusting the proxy's view blindly. A proxy can add, drop, or rewrite headers. If a result looks wrong, confirm with curl -I https://yoursite.com from a terminal, which talks to the origin directly.
• Forgetting that some sites block proxies. Sites with strict bot protection or their own CORS rules may refuse the proxy request entirely, producing an error rather than a header list. That is a property of the target, not a flaw in your configuration.
• Confusing request and response headers. This tool shows what the server sends back. Headers your browser sends (like User-Agent or Cookie) are a separate thing and are not displayed here.