HTTP Header Checker

The HTTP Header Checker fetches the response headers for any http or https URL and lays them out in a scannable table, which is the fastest way to audit how a server is configured on the wire. Type a URL or press Enter to run the check, and the tool returns the status code and text color-coded by class — green for 2xx, blue for 3xx, amber for 4xx, and red for 5xx. Every response header is sorted alphabetically, and a small shield badge marks the nine security headers the tool tracks: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and the three cross-origin policy headers. Four stat cards summarize the status, the total header count, the number of security headers present, and whether the request followed a redirect. When a redirect happens, the final URL appears under the results heading so you can trace the chain. The underlying request runs server-side with a 15-second timeout, which avoids the mixed-content blocks and CORS rules that would otherwise stop a purely client-side fetch from reading another site's headers.

1. 1

   Paste the target URL into the URL field; the hint reminds you the value must begin with http:// or https://.

2. 2

   Click Check headers or press Enter in the URL field to issue the request through the server-side API.

3. 3

   Read the Status stat and its colored badge, using green, blue, amber, and red to classify 2xx, 3xx, 4xx, and 5xx results.

4. 4

   Scan the sorted response tables for rows carrying the shield security badge; those are the nine headers the tool watches for.

5. 5

   Check the Redirected stat and the Final URL line whenever a request bounced, then drill into each hop of the chain if needed.

• Security baselines — inventory which of the nine core security headers a site sends before you recommend hardening changes.
• Client-site audits — run the checker against a prospect's homepage during onboarding and hand the missing-header list to the ops team.
• HSTS rollout verification — confirm max-age, includeSubDomains, and preload are present after enabling Transport Security.
• CDN and WAF checks — compare headers on the same origin behind different providers to verify caching and filtering differences.
• Redirect troubleshooting — spot redundant hops and cross-origin bounces that slow navigation before you redesign the URL layout.
• Staging versus production — diff the header sets of preview and live deployments to catch a proxy stripping important policies.

• Verify headers on both the apex root and the www hostname, since many sites harden one and forget an alias.
• Treat a missing Content-Security-Policy as the first hardening priority; it contains the damage of injected scripts at the browser.
• Confirm HSTS carries includeSubDomains and preload only when every subdomain truly serves TLS, or you can lock users out.
• Cross-check header values against those in your browser's DevTools, remembering the checker reads the server response without client-side changes.
• Re-run the check after every CDN or proxy change; filters and edge nodes frequently strip or rewrite security headers silently.
• Expect path-dependent headers, so test the page, an API route, and a static asset if you administer a server with mixed handlers.

• Pair this tool with the DNS Lookup immediately after deploying a site; resolving the records first confirms the target answers before headers are checked.
• Bookmark the missing-header output as a hardening checklist and re-check monthly, since CDN edits routinely wipe policies without notification.
• Include one header check over an HTTP-only URL in your audit scripts to catch sites that never enforced the HTTPS redirect chain.
• Record the Security count before and after deploying changes so regressions are visible as a number dropping, not a vague memory.