📑 HTTP Headers Checker
Check any site response headers, follow the redirect chain and audit security headers. No extension needed.
🔐 The check is performed by a 0Appz server request to the public URL you provide, with rate limiting and no storage of responses. Never check internal or private addresses.
How to use this tool
Overview
HTTP Headers Checker shows exactly what a web server sends back. Enter any public URL or domain and get the full picture: the final status code, every hop of the redirect chain with its own status, the server IP, the negotiated HTTP protocol, and the complete list of response headers, server software, caching, compression, cookies, content type and more. A built-in audit checks the eight headers that matter for security hardening: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the two Cross-Origin policies, with a score you can act on. The whole report can be copied with one click for bug reports and audits. Private and internal addresses are blocked by design (anti-SSRF), results are rate-limited and cached for five minutes.How the header check works
The checker performs a real request from a 0Appz server, follows the redirect chain hop by hop, and records the final status code, the resolved server IP and the negotiated HTTP protocol and headers. The security audit scores the headers that harden a site: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the two Cross-Origin policies. Missing or weak values are called out with what to set, which makes the report usable as a quick hardening checklist.
Capabilities and constraints
| Property | HTTP headers checker behavior |
|---|---|
| Input | Any public URL or domain |
| Reports | Final status, redirect hops, server IP, protocol, all response headers |
| Security audit | Eight hardening headers with a score and guidance |
| Export | Copy the full report in one click |
| Safety | Private/internal addresses blocked (anti-SSRF) |
| Limits | Rate-limited, results cached five minutes |
| Cost | Free, no account |
Privacy: requests run from our server
A server-side request is required to read headers that browsers hide from JavaScript. 0Appz connects to the URL you enter; the target sees our server, not your browser or IP, and nothing about your own connection is shared with the target.
Reading the security score
- Enable HSTS with a long max-age once HTTPS is stable everywhere.
- Deploy a Content-Security-Policy in report-only mode first.
- X-Content-Type-Options: nosniff prevents MIME confusion attacks.
- Cross-Origin policies matter for sites embedding sensitive resources.
- Re-check after deploys, a CDN or proxy can strip headers.
Related: browse the developer tools for SSL, DNS, meta tags and whois.
Security headers worth checking
HTTP response headers tell the browser how to treat a page, and a handful of them carry most of the security weight. Strict-Transport-Security forces future requests over HTTPS and prevents downgrade attacks; without it, a first visit over an insecure connection remains possible. Content-Security-Policy is the strongest defence against cross-site scripting because it declares which scripts may run; a missing policy is common and a permissive one with unsafe-inline is little better. X-Content-Type-Options with the value nosniff stops the browser from reinterpreting a file as a different type. X-Frame-Options or the frame-ancestors directive prevents clickjacking by controlling who may embed the page. Referrer-Policy limits how much URL information leaks to third parties, and Permissions-Policy disables APIs such as camera and geolocation that the site does not use. Cache-Control deserves attention too: a page containing personal data should not be cached by shared proxies. CORS headers decide which origins may read responses, and a wildcard combined with credentials is a red flag. Finally, Server and X-Powered-By headers reveal software versions and are best removed or minimised. Checking a site is also useful for diagnosing why an embedded resource fails or why a login redirect loops. The check runs from your browser, and nothing about the URLs you test is stored.
Frequently asked questions
How does the headers check work? +
A 0Appz server makes a controlled request to the public URL you provide, resolving the hostname, verifying it is not a private address, following up to five redirects and reading the response headers. The body is capped at 64 KB because this is a headers tool, not a proxy. Results are cached for five minutes.
Why do some security headers show as missing? +
The audit checks eight common hardening headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the two Cross-Origin policies. A missing header is not always a vulnerability, but HSTS and X-Content-Type-Options are recommended for every site.
Can I check internal or localhost addresses? +
No, private, loopback and reserved IP ranges are blocked by design to prevent server-side request forgery (SSRF). Only publicly reachable hosts can be checked.
Does it show the redirect chain? +
Yes. Every hop is listed with its status code and URL, including relative and cross-domain locations, up to five redirects. The final status, IP and protocol are shown in the summary.