HTTP Headers Check: Inspect Response Headers
What headers reveal
HTTP response headers describe how a server is responding and how browsers should handle the content. They control caching, content type, redirects, and security behavior.
Security headers reduce risks like XSS (Content-Security-Policy), clickjacking (X-Frame-Options), MIME sniffing (X-Content-Type-Options), and protocol downgrade (Strict-Transport-Security). This tool highlights when common security headers are missing so you can harden your setup.
After checking headers, you may want to verify that the site is reachable and the port is open with our port checker, or run a DNS lookup if the host does not resolve.
How to use this tool
Enter a URL (e.g. https://example.com) and run the check. The tool follows redirects and returns the final URL, status code, and the full list of response headers.
It also compares the response against a set of recommended security headers and lists which are missing. That gives you a quick audit list for your reverse proxy or application server.
A sample curl command is included so you can reproduce the request from the command line or scripts.
Common security headers and fixes
Strict-Transport-Security (HSTS) tells browsers to use HTTPS only. Add it at your reverse proxy (e.g. Nginx) or app server with a sensible max-age.
Content-Security-Policy (CSP) restricts where scripts, styles, and resources can load from. It is one of the strongest mitigations for XSS. Start with a strict policy and relax only where needed for trusted third-party scripts.
X-Frame-Options (or CSP frame-ancestors) prevents your site from being embedded in iframes, reducing clickjacking risk. X-Content-Type-Options: nosniff prevents browsers from guessing MIME types. Referrer-Policy and Permissions-Policy control what information and features are exposed.
If you use third-party scripts (analytics, payment, etc.), update CSP to include their domains. Many guides and security headers check resources exist to tune these.
Where to add headers
Headers can be set at the reverse proxy (Nginx, Apache, Caddy), at the application server (e.g. middleware in your framework), or via a CDN. Prefer setting them in one place to avoid duplication and confusion.
Once headers are correct, monitoring uptime and response times helps you keep the site healthy and catch regressions after deployments.