HTTP Header Viewer

HTTP Header Viewer - Check and Analyze HTTP Headers Online

HTTP headers are the metadata that travels with every web request and response — the part you never see in the browser address bar but that controls how caching works, which scripts can load, whether your cookies survive page reloads, whether the site can be embedded in an iframe, what compression is used, and how the browser interprets the response body. This tool exposes both sides of that conversation: in one panel you see YOUR browser's own request headers (User-Agent, Accept, Accept-Encoding, Cookie, Sec-Fetch-*, Sec-CH-UA — the new Client Hints that are gradually replacing User-Agent), and in the other panel you can fetch any HTTP/HTTPS URL and inspect its response headers (status code with the standard reason phrase, Content-Type with charset, Cache-Control rules, Set-Cookie with all the security flags, Strict-Transport-Security policy, Content-Security-Policy directives, X-Frame-Options for clickjacking protection, Access-Control-Allow-Origin for CORS configuration, server software fingerprint). Useful for debugging API integrations, validating security hardening (check that your site sends HSTS and a strict CSP), reverse-engineering caching behaviour, or learning how the web protocol layer actually behaves. CORS-blocked targets are common — the message will tell you exactly when this happens, and in those cases the browser DevTools Network tab remains your fallback.

What are HTTP Headers?

HTTP headers are metadata sent between a client (browser) and server in HTTP requests and responses. They contain important information about:

- Request details (browser type, accepted formats, authentication)
- Response details (content type, caching rules, cookies)
- Security policies (CORS, CSP, X-Frame-Options)
- Content encoding and compression
- Connection management

Headers are essential for proper web communication and affect how browsers handle content.

How do I use this HTTP Header Viewer?

Using the tool is straightforward:

1. View your current request headers in the 'Your Request Headers' section
2. To check a URL's headers, enter it in the URL field
3. Click 'Check Headers' to fetch the response headers
4. Review the status code, headers, and values

Note: Due to CORS (Cross-Origin Resource Sharing) restrictions, some websites may block header requests from browsers. This is normal security behavior.

What are Request Headers?

Request headers are sent by the browser to the server and include:

- User-Agent: Browser and OS information
- Accept: Content types the browser can handle
- Accept-Language: Preferred languages
- Accept-Encoding: Compression methods supported
- Cookie: Stored cookies for the domain
- Referer: Previous page URL
- Authorization: Authentication credentials

These headers help servers understand the client's capabilities and preferences.

What are Response Headers?

Response headers are sent by the server and include:

- Status Code: Result of the request (200 OK, 404 Not Found, etc.)
- Content-Type: Type of content being returned
- Content-Length: Size of the response body
- Set-Cookie: Cookies to store
- Cache-Control: Caching instructions
- Access-Control-*: CORS permissions
- Server: Web server software

Response headers tell the browser how to handle the received content.

What does CORS error mean?

CORS (Cross-Origin Resource Sharing) is a security mechanism that prevents browsers from making requests to domains other than the one serving the page. When you see a CORS error:

- The target server doesn't allow cross-origin requests
- This is intentional security behavior
- It's not a problem with this tool or your browser
- Many websites block CORS for security

To work around CORS:
- Use browser extensions that disable CORS (for testing only)
- Test URLs that have CORS enabled
- Use server-side tools for production testing
- Check the actual website's headers using browser DevTools (F12 → Network tab)

Which security headers should every modern website send?

The minimum baseline in 2026 includes seven headers. (1) Strict-Transport-Security (HSTS): forces HTTPS for the next year — 'max-age=31536000; includeSubDomains; preload'. (2) Content-Security-Policy: whitelist of allowed script/style/image sources — start with 'default-src 'self'' and tighten from there. (3) X-Content-Type-Options: 'nosniff' — prevents MIME-sniffing attacks where the browser tries to guess if a .txt is actually JS. (4) X-Frame-Options: 'DENY' or 'SAMEORIGIN' — blocks your site from being framed by attackers (clickjacking). (5) Referrer-Policy: 'strict-origin-when-cross-origin' — limits how much referrer info leaks to third parties. (6) Permissions-Policy: opt-out of features you don't use (camera, microphone, geolocation, USB). (7) Cross-Origin-Opener-Policy: 'same-origin' — enables Spectre-class side-channel protection and crossOriginIsolated APIs. Mozilla Observatory (observatory.mozilla.org) grades these for you; aim for an A+.

Why does a 200 OK only show about 6 headers?

This is the single most confusing behaviour of any browser-only header viewer, and it is not a bug. When the fetch succeeds with CORS but the server does NOT send an Access-Control-Expose-Headers response header, the browser only lets JavaScript read the CORS-safelisted set: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma. Everything else — Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Set-Cookie, Server, and the rest — is still sent over the wire and still applied by the browser, but it is hidden from script for privacy/security reasons. So a perfectly healthy site can return a 200 OK yet expose only ~6 readable headers here. When we detect this case we show an info note. To inspect the full set (including the security headers the scorecard needs), open browser DevTools (F12 → Network), click the request, and read the Response Headers panel — DevTools is not bound by the Expose-Headers rule.

What does my security grade mean and how do I fix a failing header?

After a successful fetch the Security Header Scorecard audits seven baseline headers and assigns an overall letter grade from A+ to F (each header counts equally; a 'warn' is worth half a pass). A+/A means you meet or nearly meet the 2026 hardening baseline; B is acceptable but improvable; C and D mean important protections are missing; F means most security headers are absent. Each failing or warning row shows a one-line remediation hint with the exact directive to add. Typical fixes: HSTS — send 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' (a shorter max-age only earns a warn); CSP — start with "default-src 'self'" and tighten; X-Content-Type-Options — 'nosniff'; framing — 'X-Frame-Options: DENY' or a CSP 'frame-ancestors' directive; Referrer-Policy — 'strict-origin-when-cross-origin'; Permissions-Policy — disable unused features; Cross-Origin-Opener-Policy — 'same-origin'. Note: if CORS hides the response headers (see the previous question) the scorecard can only grade what it can read, so verify against DevTools for an authoritative result. This mirrors Mozilla Observatory's grading, inline and instant.

Why do I get a different IP/server when checking from this tool vs my server logs?

Because the request from your browser passes through several layers before reaching the origin server. (1) Your ISP's outbound NAT translates your local IP to a public one — your server sees the NAT'd public IP, not your home address. (2) CDN edges (Cloudflare, Fastly, Akamai) terminate the TLS connection at the closest geographic point — your server sees the CDN's edge IP, not the visitor. The real visitor IP, if forwarded at all, lives in X-Forwarded-For or CF-Connecting-IP headers that the CDN inserts. (3) Reverse proxies (nginx, HAProxy) in front of your app obscure the client similarly. (4) The Server response header on most modern sites is intentionally fake or removed — security through obscurity. To see the actual chain, request a debug endpoint on your own server that echoes the full headers it receives, then compare with what this tool shows leaving the browser.

Is my data safe?

Yes, your data is completely safe:

- All header checking happens in your browser
- Your request headers are read from the browser itself
- When checking URLs, requests go directly from your browser to that URL
- No data is sent to our servers
- No logging or tracking of URLs you check
- Works offline for viewing your own headers

The tool is completely client-side, ensuring your privacy.

Key Features

• View your current HTTP request headers
• Check response headers from any URL
• Display HTTP status codes
• Show all header key-value pairs
• Analyze CORS headers
• Check cache headers
• View cookies and authentication headers
• Dark mode support
• 100% client-side processing - data never leaves your browser
• No registration required
• Works with any HTTP/HTTPS URL
• Clean, easy-to-read header display
• Copy headers to clipboard
• Security header scorecard with letter grade
• Mobile-friendly responsive design