HTTP Headers Checker
Inspect browser-visible response headers, final status and URL, caching, content type, and security-related fields.
Header Results
HTTP response headers will appear here after checking a URL.
The target site receives a real browser request
Checking a URL sends a GET request from your browser to that site. CORS decides whether page JavaScript may read the response, and a failed cross-origin check does not prove that the site is down or missing a header. Avoid testing confidential internal URLs from a shared screen or environment.
A browser can see only part of an HTTP response
Fetch exposes the final response only when the browser permits the page to read it. On cross-origin requests, CORS-safelisted response fields are available by default and other fields generally needAccess-Control-Expose-Headers. Some response fields are never exposed to frontend JavaScript.
Set-Cookie is a forbidden response header name in the Fetch model, so its absence here says nothing about whether the server sent cookies. Repeated field lines may also be combined by the browser's Headers interface.
Read status and final URL together
Fetch follows redirects in this check. A changed final URL confirms that at least one redirect was followed, but the intermediate hops, status codes, and Location fields are not preserved in the result. Use a redirect-chain trace when those hops matter.
Headers make more sense in groups
Read Cache-Control with Age, Expires, ETag, Last-Modified, and Vary; read Content-Type with Content-Encoding; and review CSP, HSTS, framing, referrer, and permissions policies as separate security controls rather than a single pass/fail score.
Missing from the table does not always mean missing on the wire
CORS can hide non-safelisted fields from JavaScript even when the server returned them. Mixed-content rules, private-network policies, extensions, authentication, and redirects can also change what a browser request can reach. Confirm uncertain cases with DevTools, curl, or a server-side HTTP client you control.
What the check can and cannot establish
- Shows the browser-exposed fields from the final GET response.
- Shows the final status and URL after browser-followed redirects.
- Does not prove a hidden security header is absent.
- Does not show request headers, TLS certificate details, DNS, or the complete redirect chain.
- Does not validate whether a present security policy is appropriate for the application.
Protocol and browser references
RFC 9110 defines HTTP field and status semantics. MDN documents the browser-side CORS exposure rules and the special treatment of Set-Cookie in Fetch. Those browser boundaries are why a frontend header check cannot replace a server-side trace.