HTTP Header Checker

Inspect the HTTP response headers a server sends. Headers carry the security and caching instructions a browser follows, and missing ones are a common, easily fixed weakness. Enter a URL to see every header returned, a checklist of the important security headers, and the caching headers that control how long pages may be stored.

Security headers

These headers tell the browser to apply extra protections. They are cheap to add and defend against whole classes of attack, yet they are often forgotten.

• Strict-Transport-Security (HSTS) — after the first visit, the browser only connects over HTTPS for the given time and refuses to let you click through certificate warnings. Critical for any HTTPS site.
• Content-Security-Policy (CSP) — declares which sources scripts, styles, fonts and frames may load from. It is the strongest mitigation for cross-site scripting; start in report-only mode if needed.
• X-Content-Type-Options — set to nosniff it stops browsers guessing content types, which otherwise lets an uploaded file be treated as script.
• X-Frame-Options — blocks clickjacking by controlling framing, or use the CSP frame-ancestors directive instead.
• Referrer-Policy — limits how much of your URL is leaked to other sites through the referrer header.
• Permissions-Policy — restricts access to features like the camera, microphone and geolocation.
• Cross-Origin-Opener-Policy — isolates the page's browsing context against cross-origin attacks.

Caching headers

Caching headers decide whether and for how long a response may be reused, which is the difference between a fast site and one that re-downloads assets on every page view.

• Cache-Control — the master switch: max-age, public/private, no-cache, no-store, immutable.
• ETag and Last-Modified — validators that let a browser ask "has this changed?" and receive a cheap 304 Not Modified if not.
• Expires — the older absolute-time equivalent of max-age.
• Age — how long a shared cache has held the response.
• Vary — which request headers change the cached response (for example Vary: Accept-Encoding).

Reading the results

The checklist shows whether each security header is present and its value. A missing header is not automatically a vulnerability — some sites rely on equivalent settings elsewhere — but each one you add narrows the attack surface. For caching, look at Cache-Control first: static assets should usually carry a long max-age with a hashed filename, while HTML should be revalidated so updates appear promptly.

Adding headers

1. Configure them at the edge. A reverse proxy or CDN (nginx, Caddy, Cloudflare) is the simplest place to set these for every response.
2. Start CSP safely. Deploy Content-Security-Policy-Report-Only, watch the reports, then enforce.
3. Enable HSTS carefully. Only after HTTPS works everywhere, and consider includeSubDomains and preload once you are ready.
4. Separate caching by content. Long-lived, immutable caching for fingerprinted assets; short or revalidated caching for HTML and APIs.
5. Re-check after changes. Load the URL again and confirm the header you added is actually being served.

Privacy and security

We request the URL you enter, follow its redirects and read the response headers. Only http and https are allowed and every hop is re-checked so the request can never reach private, loopback or reserved addresses (SSRF protection). Timeouts are 5 seconds, responses are capped, and the chain is limited to a few hops. Results are cached briefly and requests are rate-limited per IP.