HTTP Headers Checker
Fetch and inspect the HTTP response headers of any public URL in a clean, readable view.
This tool fetches response headers by making a server-side request to the URL you provide. Only use it for public URLs you are authorised to inspect. Header checks are useful diagnostic signals but do not constitute a full security audit.
Overview
HTTP response headers are metadata that a web server sends back alongside a response. They tell the browser — and any intermediate layer like a CDN or proxy — how to handle the response: whether to cache it, which origins can embed it, what content type to expect, whether to enforce HTTPS, and much more. Inspecting headers is a fast, non-invasive way to diagnose configuration issues and verify that security and caching directives are in place.
This tool fetches the response headers for any public URL via a server-side request, then presents them in a categorised, searchable view. Headers are grouped into three categories: Security headers (like Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options), Cache & Freshness headers (like Cache-Control, ETag, and Vary), and General headers covering everything else.
After the header table, a missing security headers panel flags which of the ten key security headers are absent from the response. This is a practical first step when reviewing a site's security posture, especially after a deployment or configuration change.
Use cases
When to use it
- Post-deployment verificationconfirm that security headers and cache directives are correctly set after a deployment or CDN configuration change.
- Security header reviewcheck whether HSTS, CSP, X-Frame-Options, and other protective headers are present and correctly configured.
- Caching troubleshootinginspect Cache-Control, ETag, and Vary values to understand why content is or is not being cached as expected.
- Redirect debuggingconfirm that a redirect chain resolves correctly and that the final URL is what you expect.
- Technical SEO checksverify that canonical URLs, noindex directives, and status codes are returning expected values for public pages.
When it's not enough
- Private or internal endpointsonly use this tool for public URLs. Do not use it to inspect internal APIs, admin endpoints, or anything that should not be accessible from outside your network.
- Deep security auditingheader presence is a useful signal, but it does not confirm that headers are correctly configured. CSP directives, for example, can be present but ineffective. Use a dedicated security scanner for a full audit.
- Assuming one endpoint reflects the whole siteheaders can differ by endpoint, CDN edge, region, or request type. Check the specific URL that matters, and test multiple representative paths if coverage is important.
How to use it
- 1
Enter a public URL
Type or paste a full URL including the scheme (https://). You can also click one of the example URLs to load a sample.
- 2
Click Check Headers
The tool makes a server-side fetch to the URL and returns the HTTP response headers. This may take a moment for slower servers.
- 3
Review the status and summary
The three stat cards show the HTTP status code, total number of headers returned, and how many of the ten key security headers are present.
- 4
Filter by category
Use the category pills to focus on Security, Cache & Freshness, or General headers. This makes it easier to review a specific concern without scrolling through all headers.
- 5
Check missing security headers
If any of the ten key security headers are absent, they appear in the Missing Security Headers panel below. Use this as a checklist for your server or CDN configuration.
Common errors and fixes
Request fails with a network error
The URL may be unreachable, require authentication, block server-side requests, or return a connection error. Confirm the URL is publicly accessible and includes the full scheme (https://). Some servers block requests from unknown user agents or IP ranges.
Headers look different from what you see in DevTools
This tool makes a server-side fetch, which may follow redirects, miss browser-injected headers, or receive a different response than a browser does (different User-Agent, no cookies, no session state). For browser-specific headers, use your browser's DevTools Network panel instead.
Expected security headers are missing
Security headers must be set by the server or CDN, not by the page content. Check your web server configuration (nginx, Apache, Cloudflare, Vercel, etc.) for the correct header directives. Missing headers are expected on servers that have not been explicitly configured to add them.
Redirected to an unexpected URL
If the tool reports a redirect, the final URL shown is where the server ultimately responded. Check your redirect rules if the destination is not what you expect. A redirect from http:// to https:// is normal — others may need investigation.
Cache-Control is set but pages are still stale
Cache-Control headers are instructions, not guarantees. CDNs and proxies may have their own override rules, and browsers may cache aggressively. Check whether your CDN is respecting origin headers and whether the Vary header is correctly set for content negotiation.