HTTP Header Checker Online Free

Q: Why does HEAD sometimes return different headers than GET?

Per RFC 9110 §9.3.2 (Fielding/Nottingham/Reschke, June 2022), the HEAD method returns the same response headers as GET would for the same target, but with no message body. In practice some servers and CDNs differ between the two: caching layers may serve a stale HEAD response from cache while regenerating GET; some application servers skip Set-Cookie and Content-Length on HEAD because there's no body to size; rate-limit middleware may treat HEAD differently than GET. When HEAD returns 405 Method Not Allowed (common on legacy CGI scripts and some CMS endpoints), the tool falls back to GET with Range: bytes=0-0, which fetches the first byte and reads the same headers a real GET would produce — accurate without downloading the full body.

Q: Which security headers are critical, and what should they be set to?

OWASP Secure Headers Project recommends a baseline of five: (1) Strict-Transport-Security (RFC 6797 Hodges/Jackson/Barth, 19 November 2012) — set max-age=31536000 (1 year) + includeSubDomains + preload, then submit to hstspreload.org; (2) Content-Security-Policy (W3C CSP Level 3 Working Draft, latest April 2026 revision) — at minimum default-src 'self' + a nonce-based script-src 'strict-dynamic', avoid 'unsafe-inline' and 'unsafe-eval'; (3) X-Content-Type-Options: nosniff — prevents MIME-sniffing attacks; (4) Referrer-Policy: strict-origin-when-cross-origin — leaks fewer URL details to third parties; (5) Permissions-Policy (W3C Working Draft, replacing Feature-Policy) — disable sensitive APIs you don't use (camera=(), microphone=(), geolocation=()). X-Frame-Options (RFC 7034) is obsoleted by CSP frame-ancestors and only kept for legacy browser support.

Q: Should I still set X-Frame-Options if I have CSP frame-ancestors?

X-Frame-Options (RFC 7034 Ross & Gondrom, October 2013) and CSP frame-ancestors directive (introduced in CSP Level 2, carried into Level 3) both control whether your page can be embedded in a frame. When both are present, modern browsers (Chrome, Firefox, Safari, Edge) honour CSP frame-ancestors and ignore X-Frame-Options per the W3C spec. The HTML Living Standard explicitly notes X-Frame-Options as obsolete. Practical advice: set frame-ancestors as primary policy (more flexibility — allows multiple specific domains, supports 'self' + scheme + port), keep X-Frame-Options: DENY or SAMEORIGIN as legacy fallback only if you must support browsers older than ~2015 (which is rare for security-sensitive contexts).

Q: How do CSP nonces work, and why are they preferred over 'unsafe-inline'?

CSP Level 3 supports a nonce-based workflow that allows controlled inline scripts without falling back to 'unsafe-inline'. The server generates a fresh per-request random value (≥128 bits, base64-encoded) and emits it both in the CSP header (script-src 'nonce-r4nd0m...') and on every legitimately inline tag. The browser only executes inline scripts whose nonce attribute matches the header value; injected scripts from XSS won't have the nonce and are blocked. Adding 'strict-dynamic' to the script-src directive (CSP Level 3) extends trust transitively to scripts loaded by nonced scripts, eliminating the need to allowlist host sources. This combination ('nonce-X' + 'strict-dynamic') is the modern best-practice CSP, aligned with the OWASP Secure Headers Project recommendations.

Q: How can I verify HTTP/2 or HTTP/3 is actually being used?

Modern browsers and curl --http2 / curl --http3 negotiate the highest protocol version both ends support via ALPN (Application-Layer Protocol Negotiation) during the TLS handshake. The response itself doesn't include a protocol version header, but several signals reveal what was used: (1) curl with -v shows ALPN result and the protocol used in connection setup; (2) the alt-svc response header tells clients about HTTP/3 (h3) availability for future requests, e.g. 'alt-svc: h3=":443"; ma=2592000'; (3) browser DevTools (Network panel) shows protocol per-request — h2 for HTTP/2, h3 for HTTP/3; (4) some CDNs add diagnostic headers like cf-ray (Cloudflare). RFC 9114 (HTTP/3, June 2022) requires QUIC transport; RFC 9113 (HTTP/2, June 2022) replaced RFC 7540 with the same wire format. This tool detects the protocol via the underlying fetch() implementation when available.

HTTP Header Checker — Security Headers, OWASP Baseline & Protocol Detection

HTTP response headers carry metadata about the server's response: content type, caching rules, security policies, and protocol negotiation. The current core HTTP semantics specification is RFC 9110 (Fielding, Nottingham & Reschke, June 2022), an Internet Standard (STD 97) that obsoletes RFC 7231-7235 and updates portions of RFC 7230 (HTTP/1.1 messaging is split into RFC 9112). Caching is governed by RFC 9111. Security headers form a defence-in-depth layer: Strict-Transport-Security (HSTS) per RFC 6797 (Hodges, Jackson & Barth, 19 November 2012) forces HTTPS and prevents downgrade attacks; Content-Security-Policy Level 3 (W3C Working Draft, latest revision April 2026) restricts what scripts, styles, frames, and connections the page may load; Permissions-Policy (W3C Working Draft) controls access to sensitive browser APIs like camera, microphone, and geolocation, replacing the deprecated Feature-Policy after the 2020 split into Permissions-Policy and Document-Policy; X-Frame-Options (RFC 7034 Ross & Gondrom, October 2013) is obsoleted in favour of CSP frame-ancestors. The OWASP Secure Headers Project recommends a baseline including HSTS with includeSubDomains + preload, CSP with no unsafe-inline, X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin. This tool fetches the URL, displays every response header, and flags missing security headers against that baseline.

How to inspect HTTP headers

Enter a URL. The tool issues a HEAD request (or falls back to GET with Range: bytes=0-0 if HEAD is rejected with 405).
All response headers are displayed with parsed values; security headers are scored against the OWASP Secure Headers baseline.
Missing security headers (CSP, HSTS, X-Content-Type-Options, Permissions-Policy) are flagged with the recommended directive value.
Redirects are traced — every hop shows status code, Location target, and its own response headers per RFC 9110.

Common use cases

Auditing security headers (HSTS, CSP, Permissions-Policy) before a production release — catches regressions when nginx/CDN config drifts.
Verifying Cloudflare or another CDN actually serves your content (cf-ray, server, x-cache headers visible).
Debugging caching issues by inspecting Cache-Control, Age, ETag, and Vary on a production response.
Confirming a server uses HTTP/2 or HTTP/3 — alt-svc header signals upgrade availability; ALPN negotiation completes during the TLS handshake.

Frequently asked questions

Why does HEAD sometimes return different headers than GET?

Per RFC 9110 §9.3.2, HEAD returns the same headers as GET would, but with no body. In practice some servers skip Set-Cookie/Content-Length on HEAD; some CDNs cache HEAD differently. When HEAD returns 405, the tool falls back to GET with Range: bytes=0-0 — same headers, no full body download.

Which security headers are critical, and what should they be set to?

OWASP baseline: HSTS (RFC 6797, max-age=31536000 + includeSubDomains + preload), CSP Level 3 (default-src 'self' + nonce-based 'strict-dynamic'), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy disabling unused APIs. X-Frame-Options is obsoleted by CSP frame-ancestors.

Should I still set X-Frame-Options if I have CSP frame-ancestors?

Modern browsers prioritise CSP frame-ancestors and ignore X-Frame-Options when both are present (per W3C spec). frame-ancestors is more flexible (multiple domains, schemes, ports). Keep X-Frame-Options: DENY only as legacy fallback for browsers older than ~2015.

How do CSP nonces work, and why are they preferred over 'unsafe-inline'?

CSP Level 3: server generates fresh per-request random nonce (≥128 bits, base64), emits in CSP header (script-src 'nonce-X') + on each <script nonce='X'> tag. Browser only runs scripts with matching nonce. Adding 'strict-dynamic' extends trust to scripts loaded by nonced scripts. Modern best-practice CSP.

How can I verify HTTP/2 or HTTP/3 is actually being used?

Negotiated via ALPN during TLS handshake; protocol not in response headers directly. Signals: curl -v shows ALPN result; alt-svc header advertises HTTP/3 (h3) availability for future requests; browser DevTools Network panel shows protocol per request. RFC 9114 = HTTP/3 over QUIC; RFC 9113 = HTTP/2 over TCP.

Anatomy of HTTP response headers — and why security headers matter

Server responses carry dozens of headers that browsers, CDNs, and intermediaries inspect to render content correctly and enforce security boundaries. Core semantics live in RFC 9110 (June 2022), which restructured RFC 7231-7235 into a single document defining methods, status codes, and field semantics independent of any specific HTTP version (1.1, 2, or 3). Headers split into four functional groups: representation (Content-Type, Content-Encoding, Content-Length), validation/conditional (ETag, Last-Modified, If-None-Match per RFC 9110 §13), caching (Cache-Control, Age, Vary per RFC 9111), and security policy. The security stack matters because browser default behaviour is permissive: without explicit policy, scripts execute from any origin, frames embed freely, and sensitive APIs are available to any document. Strict-Transport-Security (RFC 6797, November 2012) forces HTTPS for a configurable duration; the preload list at hstspreload.org gives apex protection for new visitors before any HTTP request happens. Content-Security-Policy Level 3 (W3C Working Draft, April 2026 revision) replaces 'unsafe-inline' vulnerabilities with nonce/hash workflows and the strict-dynamic source. The frame-ancestors directive within CSP supersedes X-Frame-Options (RFC 7034 Ross & Gondrom, October 2013, now obsoleted) — modern browsers prioritise frame-ancestors when both are present, per the W3C spec. Permissions-Policy (W3C Working Draft, replacing Feature-Policy after the 2020 split into Permissions-Policy + Document-Policy) restricts access to camera, microphone, geolocation and other sensitive APIs at the document level. The OWASP Secure Headers Project synthesises these into an audit baseline: HSTS preload, CSP nonce-based, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy disabling unused APIs. This tool reads every response header, parses values, and flags missing items against that baseline.

All response headers displayed with parsed values
Security audit against OWASP baseline (HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
HSTS preload eligibility check (max-age ≥ 1 year, includeSubDomains, preload directive)
CSP Level 3 directive parser with deprecation warnings (frame-ancestors > X-Frame-Options)
Cache-Control / Age / Vary parsing per RFC 9111; ETag / Last-Modified per RFC 9110 §8.8
Protocol detection for HTTP/1.1, HTTP/2 (RFC 9113), HTTP/3 (RFC 9114) via alt-svc + ALPN signals

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (7)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — Internet Standard STD 97; obsoletes RFC 2818 + 7231-7233 + 7235 + 7538/7615/7694 + portions of 7230; RFC 7234 → RFC 9111; RFC 7230 messaging → RFC 9112).
Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Caching. RFC 9111, IETF (June 2022 — obsoletes RFC 7234).
Hodges, J., Jackson, C., & Barth, A. (2012). HTTP Strict Transport Security (HSTS). RFC 6797, IETF (19 November 2012 — Strict-Transport-Security header field).
West, M. (Ed.) (2026). Content Security Policy Level 3. W3C Working Draft (latest revision April 2026; supersedes CSP Level 2; frame-ancestors directive — introduced in CSP Level 2 (W3C Recommendation December 2016) and carried forward in Level 3 — supersedes X-Frame-Options RFC 7034).
W3C Web Application Security WG (2025). Permissions Policy. W3C Working Draft (replaces deprecated Feature-Policy after 2020 split into Permissions-Policy + Document-Policy).
Ross, D., & Gondrom, T. (2013). HTTP Header Field X-Frame-Options. RFC 7034, IETF (October 2013, Informational; obsoleted by CSP frame-ancestors directive introduced in CSP Level 2).
OWASP (2025). OWASP Secure Headers Project. owasp.org/www-project-secure-headers — recommended baseline: HSTS preload + CSP + X-Content-Type-Options nosniff + Referrer-Policy strict-origin-when-cross-origin + Permissions-Policy.

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

HTTP Status Codes in Monitoring — Which Trigger Alerts, Which Don'tNot every non-200 is an outage. A practical guide to which HTTP status codes should page you and which are just noise.

By Marco B. · Last verified June 2026 — runs in your browser