Free Tool

Free HTTP Header Inspector

Inspect HTTP response headers for any URL. Cache headers, security policies, CORS, server info. Detects missing security headers (HSTS, CSP, X-Frame-Options) and grades your hardening. Free, instant, no signup.

Follows up to 5 redirects, returns headers from the final destination. SSRF-protected, 5s timeout.

No signup required
Free forever
GDPR compliant
Powered by U2L

Quick Answer

An HTTP header inspector fetches a URL and surfaces its response headers. The U2L Header Inspector groups headers by category (Security, Cache, CORS, Server, Content), highlights missing security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), and runs SSRF-protected fetches at the Cloudflare edge. Useful for SEO audits, security reviews, and CDN debugging.

Quick Facts

  • Inspects response headers for any public HTTP / HTTPS URL. Follows redirects up to 5 hops, returns the final destination's headers.
  • Categorizes headers: Security (HSTS, CSP, X-Frame-Options), Cache (Cache-Control, ETag, Vary), CORS (Access-Control-*), Server (CF-Ray, X-Vercel-ID), Content (Content-Type, Encoding).
  • Flags missing security headers and grades severity (high / medium / low). HSTS and CSP missing is a high-severity finding.
  • 5s timeout, SSRF-protected (loopback, RFC1918, link-local, cloud-metadata IPs blocked).
  • Edge-cached for 60 seconds. Repeat checks on the same URL return instantly.
  • Useful for: SEO audits (proper Cache-Control), security reviews (HSTS, CSP), CDN debugging (server identification), CORS troubleshooting.
  • For ongoing security-header monitoring, sign up free for U2L Pro to schedule daily checks with alerting on changes.

How to inspect HTTP headers

Two steps. URL in, headers out.

  1. 1

    Enter the URL to inspect

    Paste any public HTTP / HTTPS URL. The inspector follows redirects up to 5 hops; the headers shown are from the final destination.

  2. 2

    Review headers and security findings

    Headers grouped by category. The Security panel flags missing headers with severity (high / medium / low). Hover for explanations of each header.

  3. 3

    Copy or export specific headers

    Click a header value to copy. Useful for copying Cache-Control values into your CDN config, or pasting CORS settings into your backend.

What is a HTTP Header Inspector?

HTTP Header Inspector is a tool that fetches a URL and reports its HTTP response headers. Every HTTP response from a server includes headers - metadata describing the response (Content-Type, Cache-Control, Set-Cookie, Server identification, etc.). Inspecting headers tells you how a site is configured: whether it caches correctly, how it handles security, whether it's behind a CDN, and what server tech is in use.

Headers are the source of truth for a lot of web behavior that's invisible in HTML. Cache-Control determines how long browsers and CDNs cache the page. Strict-Transport-Security forces HTTPS for all future visits. Content-Security-Policy restricts which scripts and resources can load. X-Frame-Options blocks the page from being framed by attackers. Without inspecting headers, you can't audit any of this.

Beyond the security side, headers are also where SEO audits begin. Cache-Control values determine whether Google crawls your pages efficiently. Vary headers determine how Google handles different versions (mobile vs desktop, language-specific). X-Robots-Tag headers can deindex content even when the HTML says 'index'. Headers are silent and hard to debug without a dedicated inspector.

The U2L Header Inspector adds a security analysis layer. We compare your response against the OWASP recommended security header set (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) and flag missing ones with severity. High-severity gaps (no HSTS, no CSP) are common attack vectors; mid-severity gaps (no X-Frame-Options, X-Content-Type-Options) protect against specific threat classes; low-severity gaps (no Referrer-Policy) are best-practice nice-to-haves.

How does a HTTP Header Inspector work?

When you submit a URL, the request hits Cloudflare's edge Worker. The Worker validates the URL (HTTPS or HTTP, public IP via SSRF guard - localhost, RFC1918 private ranges, link-local, and cloud-metadata IPs are blocked) and starts a manual-redirect-following GET request with a 5-second timeout.

Each redirect hop is also SSRF-checked - prevents an attacker-controlled redirect from causing the server to fetch internal URLs. After up to 5 hops, the final response's headers are captured. Body is cancelled (we don't need it) to keep memory usage low.

Headers are sorted into 6 categories using a curated map of known header names. Anything unmatched falls into 'Other'. Within each category, headers sort alphabetically. The output is easy to scan visually and copy individual values.

Security analysis runs against a 6-header recommended set: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Each missing header gets flagged with severity (high / medium / low). The descriptions explain what each header does and why missing it is a problem.

Use Cases

How marketers, businesses, and developers use http header inspector.

Pre-launch security audit

Before launching a site, check your headers. Missing HSTS / CSP is common and trivially fixable; the inspector surfaces gaps in seconds.

SEO cache-policy audit

Slow indexing? Check Cache-Control headers. 'no-cache' or 'private' on pages that should be public hurts crawl efficiency.

CORS troubleshooting

API call failing with 'CORS error'? Inspect the API's response headers. Missing Access-Control-Allow-Origin is the usual culprit.

CDN identification

Is your customer behind Cloudflare? Vercel? Fastly? Server / CF-Ray / X-Vercel-ID headers tell you. Useful for support and partnership conversations.

Vendor due diligence

Evaluating a SaaS vendor? Check their security headers. Missing HSTS / CSP suggests poor security posture; present + tight CSP suggests good hygiene.

Compliance evidence collection

SOC 2 and ISO audits often require evidence of security headers. Header inspector output is publicly verifiable evidence (no server access needed).

Post-deploy verification

After deploying a security-header change (CSP update, HSTS rollout), inspect production immediately to confirm the new headers are live.

Cache-rule debugging

Pages serving stale content? Check Cache-Control + ETag + Last-Modified. The inspector reveals what your CDN is honoring vs. ignoring.

X-Robots-Tag indexing audit

Pages not appearing in search? Check X-Robots-Tag headers. 'noindex' set in headers overrides HTML meta robots tags silently.

Brand-protection vendor monitoring

Track security-header changes on critical vendor pages. Sudden drop in HSTS suggests configuration regression or compromise.

HTTP Header Inspector vs Alternatives

Side-by-side feature and pricing comparison with the top alternatives.

FeatureU2Lsecurityheaders.comMozilla Observatorycurl -I
Free unlimited inspections
Headers grouped by categoryManual
Security-header gap analysis
Severity grading per headerLetter gradeLetter grade
Browser-only (no install)
Edge-cached responses60sMixedMixed
JSON / API outputPaidManual
Follows redirects5 hops-L flag

HTTP Header Inspector vs securityheaders.com (Scott Helme)

securityheaders.com is the most-recognized security-header analyzer. Letter-grade scoring (A+ to F), detailed explanations, links to documentation. Industry standard since 2015.

U2L's inspector is broader - includes non-security headers (Cache, CORS, Server) in the same view, useful for SEO and CDN debugging beyond pure security. Both are free; use securityheaders.com for the letter-grade summary, U2L for the full header dump.

HTTP Header Inspector vs Mozilla Observatory

Mozilla Observatory does deeper security analysis - cookies, TLS, redirects, plus security headers. Letter-grade with a numeric score, public-history view. Free; takes 30-60 seconds for a full scan.

U2L's inspector is faster (sub-second) and more focused on the headers themselves. For a full security report, run Observatory. For 'what headers does this URL serve?', U2L is faster.

Best Practices

Set HSTS with at least 1-year max-age

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Submit to the HSTS preload list at hstspreload.org once you're sure all subdomains are HTTPS-ready.

Use CSP with nonce-based script approval

Modern CSP uses nonce= or strict-dynamic to allow only your approved scripts. Block 'unsafe-inline' and 'unsafe-eval' to defeat XSS.

Set X-Content-Type-Options: nosniff everywhere

Prevents browsers from MIME-sniffing responses. Single line in your server config; reduces a class of XSS vulnerabilities.

Use Referrer-Policy: strict-origin-when-cross-origin

Default for modern browsers but explicit is better. Sends the full URL on same-origin requests, only the origin on cross-origin requests, nothing on HTTPS->HTTP downgrade.

Audit Cache-Control on dynamic pages

Pages with user-specific content should be Cache-Control: private. Pages that change often should have short max-age (60-300s). Missing Cache-Control = browsers heuristically cache (bad).

Don't expose Server / X-Powered-By headers

Server: nginx/1.24.0 tells attackers your stack version. Strip Server and X-Powered-By in your reverse proxy config. Reduces attack surface for known-CVE exploitation.

Use Permissions-Policy to disable unused features

Permissions-Policy: camera=(), microphone=(), geolocation=() blocks third-party scripts from accessing those APIs. Cheap defense against compromised dependencies.

Re-audit after every CDN config change

Cloudflare, Fastly, Vercel can override or strip headers. After any CDN config change, re-inspect to confirm your headers still arrive at the browser.

Common Mistakes to Avoid

Setting HSTS without testing all subdomains first

If you set HSTS with includeSubDomains, every subdomain (including dev / staging) must be HTTPS. Otherwise, those subdomains break for all users who visited the parent. Test before deploying.

Using 'unsafe-inline' in CSP

CSP with 'unsafe-inline' (for scripts) is essentially no CSP at all - it allows any inline script, defeating XSS protection. Use nonce= or strict-dynamic.

Caching personalized pages

Pages with user-specific content (logged-in dashboards) should be Cache-Control: private, no-store. Public Cache-Control on these = data leakage between users via shared CDN cache.

Forgetting to handle CORS preflight (OPTIONS)

CORS-fetched APIs need OPTIONS responses with Access-Control-Allow-* headers. Missing preflight = browsers reject the actual request. Inspector flags missing CORS headers.

Trusting CDN-set headers without verification

Cloudflare 'auto-injects' some headers in some configs. Verify with the inspector that the headers actually arrive at the browser; CDN dashboard says one thing, real response can differ.

Forgetting Vary: Accept-Encoding for compressed content

Without Vary: Accept-Encoding, CDNs may serve gzipped content to clients that don't support gzip. Always include Vary on any response that depends on request headers.

Setting X-Frame-Options without considering CSP

Modern best practice is CSP frame-ancestors instead of X-Frame-Options. CSP frame-ancestors is per-page; X-Frame-Options is global. Pick one (CSP preferred); setting both is fine but redundant.

Technical Specifications

EndpointGET /api/tools/http-headers?url=...
Required paramsurl (HTTP or HTTPS)
Redirect handlingFollows up to 5 hops; returns final destination's headers
SSRF protectionPer-hop check: loopback, RFC1918, link-local, cloud-metadata blocked
Timeout5 seconds total
User-AgentChrome 124 desktop UA
Cache TTL60 seconds at the Cloudflare edge
Categories returnedSecurity, Cache, CORS, Server, Content, Other
Security headers checkedHSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
OutputJSON with categories + security findings + final URL + status

Industry-Specific Use Cases

DevOps and SRE

Post-deploy header verification, CDN config validation, cache-policy debugging.

Security and compliance

Security-header audits, SOC 2 / ISO evidence collection, vendor security assessments.

Web developers

Frontend developers debugging CORS, cache, redirect issues. Backend developers verifying server configs.

SEO professionals

Cache-policy audits for crawl efficiency, X-Robots-Tag debugging, canonical-header verification.

Brand protection

Periodic security-header monitoring on critical assets. Catches config regressions and rogue changes.

Vendor due diligence

Pre-purchase security assessment of SaaS vendors. Header inspector is publicly verifiable evidence.

Frequently Asked Questions

What HTTP headers should every site have?

Minimum security baseline: HSTS, X-Content-Type-Options: nosniff, Referrer-Policy. Stronger: also CSP, X-Frame-Options (or CSP frame-ancestors), Permissions-Policy. Operational: Cache-Control on every response, Vary on responses that vary by request header.

Why does HSTS matter?

Without HSTS, a user's first-ever HTTP request to your site is vulnerable to SSL stripping (an active network attacker downgrading to HTTP). HSTS tells browsers 'always use HTTPS for this domain', removing the vulnerability after the first HSTS-enabled visit.

What's the difference between HSTS preload and dynamic HSTS?

Dynamic HSTS: browser learns the policy after the first HTTPS visit. Preload: browser ships with your domain on a hardcoded list, so even the first visit uses HTTPS. Submit to hstspreload.org for max protection.

Is X-Frame-Options still needed?

Modern browsers prefer CSP frame-ancestors. X-Frame-Options is the older equivalent; both work. If you're already setting CSP frame-ancestors, X-Frame-Options is redundant but harmless. If you're not setting CSP, X-Frame-Options is the cheap fallback.

What about CSP with 'unsafe-inline'?

CSP with script-src 'unsafe-inline' provides essentially no XSS protection. Use nonce-based CSP (nonce=random-value on each <script> tag) or strict-dynamic. The inspector doesn't grade CSP quality - look at the value yourself.

Why is my site missing CSP?

Most sites ship without CSP because retrofitting CSP onto an existing site breaks inline scripts and event handlers. Plan a CSP rollout: start with Content-Security-Policy-Report-Only to log violations without blocking, fix violations one-by-one, then switch to enforcing CSP.

How do I add these headers to my site?

Depends on your stack. Cloudflare / Fastly / Vercel: dashboard + worker / function. Nginx: add_header directives. Apache: Header set lines in .htaccess or the config. Express: helmet npm package. Django: SECURE_HSTS_SECONDS settings.

Can I check headers for a non-public URL?

No. The U2L inspector blocks loopback, private (RFC1918), link-local, and cloud-metadata IPs to prevent SSRF abuse. For internal URLs, use curl -I from inside your network.

Why follow redirects?

Headers on the redirect response (which you might land on first) are different from headers on the final destination. Most security headers matter on the final destination. The inspector follows up to 5 redirects to surface the headers users actually interact with.

What's CORS?

Cross-Origin Resource Sharing. The browser security mechanism that controls which sites can fetch from your APIs via JavaScript. Set Access-Control-Allow-Origin: * for fully public APIs; specific domains for restricted ones.

Why does the Server header matter?

It identifies your tech stack to anyone hitting your site - including attackers running CVE scans. 'nginx/1.24.0' tells an attacker exactly which CVEs to try. Strip Server and X-Powered-By in your reverse proxy.

How often should I re-check security headers?

After every CDN config change. Periodically (monthly) on production. Set up automated monitoring (U2L Pro or a stack like Datadog Synthetics) for continuous coverage.

What does the severity grading mean?

High = direct attack vector if missing (HSTS, CSP). Medium = protects against specific threats (X-Frame-Options for clickjacking, X-Content-Type-Options for MIME sniffing). Low = best-practice nice-to-haves (Referrer-Policy, Permissions-Policy).

Will the inspector see Set-Cookie headers?

Yes - they appear in the 'Other' or 'Content' category. The inspector doesn't deep-analyze cookies (Secure, HttpOnly, SameSite); for cookie analysis, look at the Set-Cookie value or use a dedicated tool like Mozilla Observatory.

Is there an API I can call programmatically?

Yes. GET https://u2l.ai/api/tools/http-headers?url=... returns JSON. Cached for 60 seconds. No auth required. Be polite - don't loop more than 1 request per second per URL.

Why does my site show Cache-Control: no-store?

Common on dynamic pages (logged-in dashboards, e-commerce checkout). Tells browsers and CDNs 'never cache this'. Correct for personalized content. Wrong for static marketing pages (where you want long max-age for performance).

What's a 'bad' header value?

Headers with overly-permissive values: CSP with 'unsafe-inline', CORS Access-Control-Allow-Origin: * for authenticated APIs (allows any site to read responses), Cache-Control: no-cache on static assets (slows everyone down). The inspector shows values; judging good/bad requires context.

What about Strict-Transport-Security with includeSubDomains?

Stronger HSTS that applies to all subdomains. Required for HSTS preload list. CAREFUL: every subdomain (dev, staging, internal) must be HTTPS-ready, otherwise they break for users who visited the parent.

Key Terms

HTTP header
Metadata attached to every HTTP request and response. Headers describe content type, caching policy, security policies, server identification, etc. Unrelated to the page body.
HSTS (HTTP Strict Transport Security)
A response header that tells browsers to use HTTPS exclusively for future requests to the domain. Defends against SSL stripping attacks.
CSP (Content Security Policy)
A response header that restricts which sources can serve scripts, styles, images, etc. Defends against XSS by blocking attacker-injected resources.
CORS (Cross-Origin Resource Sharing)
Browser security mechanism controlling which origins can read responses from your APIs via JavaScript. Configured via Access-Control-Allow-* response headers.
Cache-Control
A response header controlling how the browser and CDNs cache the response. Common values: max-age=N (cache for N seconds), no-cache (revalidate every time), private (no shared cache), public (any cache).
X-Frame-Options
A response header preventing the page from being framed by other sites. Defends against clickjacking. Modern equivalent: CSP frame-ancestors.
Referrer-Policy
A response header controlling what's sent in the Referer header on outbound requests. 'strict-origin-when-cross-origin' is a safe default.
Permissions-Policy
A response header restricting browser features (camera, microphone, geolocation, etc.) on the page. Reduces attack surface for compromised third-party scripts.

Want continuous security-header monitoring?

Sign up free for U2L Pro to schedule daily header checks across your domains, receive alerts when security headers regress, and integrate with PagerDuty / Slack for incident routing. No credit card; takes 30 seconds.

Sign up free