HTTP Security Headers Analyzer
or paste headers manually

What does this tool do?

Analyze your HTTP response headers for security best practices. The tool evaluates 10 critical security headers, checks for information leakage, and provides a weighted score with actionable recommendations. You can paste headers manually or fetch them from a URL.

Which headers are analyzed?

  • Content-Security-Policy (25 pts) — XSS and injection prevention

  • Strict-Transport-Security (15 pts) — HTTPS enforcement

  • X-Content-Type-Options (10 pts) — MIME sniffing prevention

  • X-Frame-Options (8 pts) — clickjacking protection

  • Referrer-Policy (8 pts) — referrer information control

  • Permissions-Policy (8 pts) — browser feature restrictions

  • Cross-Origin-Opener-Policy (8 pts) — browsing context isolation

  • Cross-Origin-Resource-Policy (8 pts) — resource loading control

  • Cross-Origin-Embedder-Policy (7 pts) — embedding control

  • X-XSS-Protection (3 pts) — legacy XSS filter (should be disabled)

Additionally, the tool checks for information leakage via Server, X-Powered-By, and X-AspNet-Version headers.

Grading Scale

  • A+ (90-100) — Excellent security posture

  • A (80-89) — Strong, minor improvements possible

  • B (70-79) — Good, some headers missing

  • C (50-69) — Fair, several important headers missing

  • D (30-49) — Poor, major gaps

  • F (0-29) — Critical, most headers missing

How do I use it?

  1. Enter a URL and click Fetch, or paste headers from browser DevTools / curl

  2. Click Analyze to see the security score and recommendations
  3. Fix missing headers in your server configuration and re-analyze

Is my data private?

All analysis happens entirely in your browser: the headers in the text box are parsed, scored and graded on your own machine, and nothing about them is sent anywhere. The Fetch button is the exception. CORS stops a browser from reading another site’s response headers, so the URL you submit goes to a small proxy on this domain that requests them for you. That proxy has its access log switched off, so the URL you inspect is never written beside your address, and the site being inspected sees this server rather than you. To keep even that request off the network, paste headers captured with curl -sI instead of using Fetch.

Linux Command Reference

You can inspect HTTP headers from the terminal using these tools:

curl — Headers Only

curl -sI https://example.com
HTTP/2 200date: Thu, 12 Feb 2026 07:37:48 GMTcontent-type: text/htmlcf-ray: 9cca6c3e7e52ddef-MADlast-modified: Wed, 11 Feb 2026 23:52:30 GMTaccept-ranges: bytescf-cache-status: HITserver: cloudflare

curl — Filter Security Headers

curl -sI https://jmrp.io | grep -iE '^(strict-transport|x-content-type|x-frame|referrer|cross-origin|permissions|content-security)'
strict-transport-security: max-age=63072000; includeSubDomains; preloadx-content-type-options: nosniffx-frame-options: DENYreferrer-policy: strict-origin-when-cross-origincross-origin-embedder-policy: require-corpcross-origin-opener-policy: same-origincross-origin-resource-policy: same-origincontent-security-policy: default-src 'self'; script-src 'self' ...

curl — Verbose (TLS + Headers)

curl -sv https://example.com -o /dev/null 2>&1 | grep '< '
< HTTP/2 200< date: Thu, 12 Feb 2026 07:37:48 GMT< content-type: text/html< server: cloudflare

wget — Spider Mode

wget -S --spider https://example.com 2>&1 | grep '^\s'
HTTP/1.1 200 OKDate: Thu, 12 Feb 2026 07:37:52 GMTContent-Type: text/htmlcf-cache-status: HITserver: cloudflare

Check Specific Header

# Check if HSTS is present
curl -sI https://jmrp.io | grep -i strict-transport
# Check CSP policy
curl -sI https://jmrp.io | grep -i content-security-policy
strict-transport-security: max-age=63072000; includeSubDomains; preloadcontent-security-policy: default-src 'self'; script-src 'self' ...

Compare Multiple Sites

for site in example.com jmrp.io github.com; do
echo "=== $site ==="
curl -sI "https://$site" | grep -ci '^\(strict-transport\|x-content-type\|x-frame\|referrer-policy\|permissions-policy\|content-security-policy\|cross-origin\)'
echo "security headers found"
done
=== example.com ===0 security headers found=== jmrp.io ===9 security headers found=== github.com ===5 security headers found

Learn More

See

Implementing CSP in Nginx

for a detailed guide on configuring security headers.

Frequently asked questions

Which HTTP security headers does this tool check?

It evaluates 10 critical headers including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and the three Cross-Origin policies. It also flags information leakage from "Server", "X-Powered-By" and "X-AspNet-Version" headers.

How is the security score calculated?

Each header carries a weight reflecting its impact, with Content-Security-Policy worth the most (25 points) and X-XSS-Protection the least (3 points). The weighted total maps to a letter grade from A+ (90-100) down to F (0-29).

Why are some headers missing when I fetch them from a URL?

Fetch asks this site's own proxy for the headers, and that proxy issues a HEAD request with its own User-Agent and no cookies. Headers a server only sends on GET, only to a signed-in session, or only after content negotiation will not appear, and if the site sits behind a CDN you see the edge's headers rather than the origin's. For an exact capture, paste the output of curl -sI or the response headers from browser DevTools.

Is my data sent to a server when I analyze headers?

The analysis never leaves your browser: whatever is in the text box is parsed, scored and graded on your own machine. The optional Fetch button is the exception, because a browser is not allowed to read another site's response headers — CORS forbids it — so the URL you submit goes to a small proxy on this domain, which requests the headers and hands them back. That proxy has its access log switched off, so the URL you inspect is never written beside your address, and the site being inspected sees this server rather than you. Paste headers instead of fetching and nothing is sent at all.

Should I still set X-XSS-Protection?

No. X-XSS-Protection is a legacy filter that modern browsers ignore or that can introduce vulnerabilities; the recommended value is "0" to disable it, and a strong Content-Security-Policy is the proper XSS defense.