HTTP Header Inspector

What are HTTP headers?

HTTP headers are metadata sent between a client (browser) and server with every web request and response. They control caching, authentication, content type, security policies, and many other aspects of web communication. This tool lets you inspect the response headers returned by any URL, helping you debug web applications and verify security configurations.

Headers are key-value pairs sent before the actual page content. Common response headers include Content-Type (what kind of data is being sent), Cache-Control (how long to cache the response), Set-Cookie (storing session data), and various security headers like Content-Security-Policy and Strict-Transport-Security.

Important security headers

• Strict-Transport-Security (HSTS) — forces browsers to use HTTPS for all future connections.
• Content-Security-Policy (CSP) — controls which resources the page can load, preventing XSS attacks.
• X-Content-Type-Options — prevents browsers from guessing content types, blocking certain attacks.
• X-Frame-Options — prevents your page from being embedded in iframes on other sites (clickjacking protection).
• Referrer-Policy — controls how much referrer information is sent when navigating away from your site.

How to use this tool

Enter a URL and the tool fetches the page and displays all response headers. Security-relevant headers are highlighted and evaluated. Missing recommended security headers are flagged so you can improve your site's security configuration.

Cache headers explained

Cache-Control headers determine whether and how long browsers and CDNs store responses. Common directives include max-age (seconds to cache), no-cache (revalidate before using cached copy), no-store (never cache), and public/private (whether shared caches like CDNs can store it). Proper caching dramatically improves page load speed and reduces server load.

Example in practice

Run the tool against https://example.com and it returns a HEAD response. A typical result shows content-type: text/html; charset=utf-8, cache-control: max-age=3600, and a strict-transport-security line. The status panel reads 200 next to the header count and round-trip time. If strict-transport-security is missing from the security list, the site is not enforcing HTTPS at the browser level — a fixable one-line server change.

Common mistakes

The biggest surprise is an empty result even though the site loads fine in a browser. That is almost always CORS: a cross-origin fetch can only read headers the server exposes with Access-Control-Allow-Origin, so most third-party sites return an opaque response. Another mistake is treating a missing x-frame-options as harmless — without it, or a frame-ancestors CSP directive, the page can be embedded in a clickjacking frame.

Frequently asked questions

Why should I check HTTP headers?

Headers reveal security misconfigurations (missing HSTS or CSP), caching problems (incorrect max-age causing stale content), and server information leaks (Server header revealing exact software versions). Regularly checking headers helps maintain security and performance. Security audit tools and penetration testers always start with header analysis.

What is the difference between request and response headers?

Request headers are sent by the browser to the server (like Accept, User-Agent, Cookie). Response headers are sent by the server back to the browser (like Content-Type, Set-Cookie, Cache-Control). This tool shows response headers because they reveal server configuration and security settings. You can see request headers in your browser's developer tools (Network tab).

Why can't I see all the headers?

Browsers hide most response headers on cross-origin requests unless the server opts in with CORS. Server-side tools like curl -I or your hosting dashboard show the complete set. This tool reflects exactly what client-side JavaScript is permitted to read.