HCODX/HTTP Header Viewer
Full response headers · Security checks

HTTP Header Viewer: inspect any URL's response headers

Free in-browser HTTP header viewer. The security-header grade comes from Mozilla HTTP Observatory — they run a real scan from their servers and return the official A+ → F grade plus per-test details. Raw headers and status are also displayed.

Use cases

When to inspect HTTP response headers

Security audit

Get a securityheaders.com-style A+ → F grade for any URL — instantly see which headers are missing and which are present.

CSP debugging

Parse the Content-Security-Policy directive list and flag 'unsafe-inline', 'unsafe-eval', wildcards and missing frame-ancestors.

Cache & CDN review

Read Cache-Control, ETag, Age, X-Cache and CDN-specific headers (cf-cache-status, x-vercel-cache) to verify caching is working.

Redirect debugging

See the final URL after redirects, the status code (301 / 302 / 307 / 308) and confirm your www → apex or http → https rules work.

Compliance & cookies

Inspect cookie attributes (where the proxy doesn't strip them), Permissions-Policy declarations, and Referrer-Policy for GDPR audits.

Server fingerprinting

Identify the web server (nginx, Apache, Caddy, Cloudflare) and runtime (x-powered-by) — and flag information leakage that should be hidden.

Step by step

How to use the HTTP header viewer

1

Paste a URL

Any public HTTPS URL. The protocol is added if missing.

2

Pick GET or HEAD

GET fetches the body too (heavier). HEAD asks the server only for the headers — faster but a handful of servers block HEAD with 405.

3

Click Fetch headers

The request goes through a chain of three public CORS proxies — if one is rate-limited, the next picks it up automatically.

4

Read the grade and details

The big A+ / A / B / C / D / F tile is your headline. The Security Header Health card shows which headers contributed points; the CSP Analysis card lists directives and warnings.

About

About HTTP response headers and the security score

Every HTTP response carries a set of headers — small key-value pairs that the server adds before the page body. They tell the browser how to cache the response, what scripts may execute, whether to force HTTPS, how to control cookies and dozens of other things. Most are invisible in the browser's address bar but shape every aspect of how your site is rendered and how secure it is. This HTTP header viewer exposes the full list for any URL plus a colour-graded security score modelled on Scott Helme's securityheaders.com.

The eight security headers that matter

Strict-Transport-Security (HSTS) forces HTTPS for repeat visitors. Content-Security-Policy (CSP) declares which sources scripts, styles, fonts and images may load from — the single most effective defence against XSS. X-Frame-Options (or CSP frame-ancestors) blocks clickjacking. X-Content-Type-Options: nosniff blocks MIME sniffing. Referrer-Policy controls how much of the URL leaks via the Referer header. Permissions-Policy restricts which Web APIs (camera, mic, geolocation, USB, payment) the page may use. COOP + COEP enable cross-origin isolation, required for SharedArrayBuffer and high-resolution timers.

How the A+ → F grade is calculated

Each header is worth points (HSTS 20, CSP 25, X-Frame 20, Permissions-Policy 20, X-Content-Type-Options 5, Referrer-Policy 5, COOP 5, COEP 5 — total 110). Penalties apply for 'unsafe-inline' or 'unsafe-eval' in CSP, wildcards, and information leakage (x-powered-by, server-version strings). The total maps to A+ (≥100), A (≥85), B (≥65), C (≥45), D (≥25), E (>0), F.

CSP analysis

The tool parses each Content-Security-Policy directive into a table and surfaces the most common weaknesses: 'unsafe-inline' and 'unsafe-eval' (defeat most XSS protection), * wildcards (allow any origin), missing default-src or script-src, and missing frame-ancestors. Fixing all of these typically jumps a B grade straight to A or A+.

Why the tool needs a CORS proxy

Browsers block JavaScript from reading response headers across origins unless the server explicitly allows it via the Access-Control-Allow-Origin header. Almost no public website sets that header, so we route the request through one of three public CORS proxies (corsproxy.io, allorigins.win, corsfix.com). The proxy fetches the target URL server-side and re-emits the response with CORS open, so the browser is allowed to read the headers.

Limits of what proxies can show

Cookies (Set-Cookie) are usually stripped by CORS proxies because they're per-origin secrets. The exact redirect chain is condensed into "final URL" for the same reason. If you need the raw redirect history including 3xx hops, use a real HTTP client like curl -v. The request meta card always tells you which proxy succeeded so you can reproduce the call.

FAQ

HTTP Header Viewer — frequently asked questions

Browsers block reading response headers from cross-origin requests unless the server allows it via CORS. A public CORS proxy (corsproxy.io) sits between us and the target so we can read every header.

The request originates from the corsproxy.io infrastructure with a normal browser user agent. Server logs will show the proxy's IP, not yours.

Servers and CDNs may strip headers for proxied requests, especially Set-Cookie. The proxy passes through what the target returned to it.

Related

Related tools