Skip to content

HTTP Headers Checker

Look up live http headers checker data straight from public records.

Interactive http headers checkerQueries live public dataFree, no account
Overview

What is the HTTP Headers Checker?

The HTTP Headers Checker fetches a URL and shows every response header the server sends back, plus a specific pass/fail check against six security headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. Enter a URL and it returns the raw header block, exactly as the server sent it, alongside plain-English explanations of what each security header does and what to add if it's missing. Developers use it to verify a CDN or reverse proxy is passing headers through correctly, to check a security header change actually deployed, and to audit a site's baseline hardening before a security review.

Response headers are metadata sent alongside every HTTP response, invisible in the rendered page but read by browsers, crawlers and caching layers to decide how to handle the content. Missing security headers don't usually break a site visibly, which is exactly why they get missed — nothing looks wrong until someone runs a check like this one, or until the gap gets exploited.

Benefits

Why use a free http headers checker?

The full raw header block

See every header the server actually returned — caching, server identification, cookies, content type — not just the security subset.

Six security headers checked automatically

HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy are each checked for presence and shown with a specific fix if missing.

A sane default value for every missing header

Each fix suggestion includes a real header value you can copy into your server config, not just the header name.

Copy the raw headers in one click

Copy the full header block as text to paste into a support ticket, a bug report or a security audit document.

Reads what the server actually sends

This is a live HTTP request to the URL you enter, so it reflects your current CDN, proxy and origin server configuration exactly as a browser would see it.

Guide

How do you use the HTTP Headers Checker?

  1. 1

    Enter the URL

    Paste the full URL you want to inspect, including the page path if it matters — headers can differ between pages on the same domain.

  2. 2

    Review the raw header table

    Every header name and value returned by the server is listed, sorted alphabetically.

  3. 3

    Check the security header summary

    Each of the six checked headers is marked Pass or Missing, with an explanation of what it does and a fix if it's absent.

  4. 4

    Copy or act on the results

    Copy the header block for documentation, or apply the suggested fix values directly to your server or CDN configuration.

Accuracy

How accurate is it?

Headers are read from a real, live HTTP request made to the URL you enter at check time — this is exactly what a browser or crawler receives, not a static analysis of your server config. If a CDN, WAF or reverse proxy modifies headers before they reach a visitor, this check reflects the final, modified version, which is the version that actually matters.

  • Some headers can differ between an initial page load and subsequent requests due to caching layers — a cached response may carry different headers than an uncached one.
  • Headers can also differ by page path, HTTP method, or whether the request includes cookies, none of which this simple GET-based check exercises.
  • A header being present does not guarantee it is configured correctly — a CSP header with an overly permissive value still passes the presence check here, since evaluating policy strictness is a separate, more involved analysis.
Details

What should you know before using it?

The six security headers checked, what each does, and a sane default value:

HeaderWhat it does — and a safe default
Strict-Transport-SecurityForces browsers to only ever connect over HTTPS, closing a downgrade-attack window. Default: max-age=31536000; includeSubDomains
Content-Security-PolicyRestricts which scripts, styles and other resources a page is allowed to load, limiting the damage a successful XSS injection can do. No universal default — scope it to the origins your page actually needs.
X-Content-Type-OptionsStops the browser guessing a file's type from its content instead of trusting the declared Content-Type, which can be abused to run a disguised script. Default: nosniff
X-Frame-OptionsBlocks the page from being embedded in an iframe on another site, preventing clickjacking. Default: SAMEORIGIN (or DENY if it should never be framed at all)
Referrer-PolicyControls how much of the referring page's URL is sent to the next site when a user clicks a link, limiting leakage of sensitive paths or query parameters. Default: strict-origin-when-cross-origin
Permissions-PolicyRestricts which browser features — camera, microphone, geolocation and others — the page and any embedded frames may use. Default: disable anything unused, e.g. camera=(), microphone=(), geolocation=()
Applications

When should you use a http headers checker?

The http headers checker queries live public records, so it suits checks where a stale answer would be misleading — during a migration, after a DNS change, or before you commit to a domain. These are the situations people reach for it in most often.

Security hardening review

Check a site against a baseline set of security headers before a penetration test or compliance audit, and fix gaps ahead of time.

CDN and proxy debugging

Confirm a CDN, load balancer or reverse proxy is passing origin headers through correctly, or check whether it is stripping or overwriting them unexpectedly.

Post-deploy verification

After adding a new header to your server config, confirm it actually reached production and is set to the value you intended.

Vendor and third-party site checks

Quickly check the security posture of a partner or vendor site's headers without needing access to their infrastructure.

FAQs

Frequently asked questions

What are HTTP response headers?
Metadata a server sends alongside every response, before the actual page content — things like content type, caching rules, cookies and security policies. Browsers, crawlers and intermediate proxies read these headers to decide how to handle the response; they are invisible in the rendered page itself.
What is the most important security header to add first?
Strict-Transport-Security (HSTS) and X-Content-Type-Options are usually the fastest wins — both are a single line, apply site-wide, and have essentially no compatibility risk. Content-Security-Policy delivers the most protection but needs careful scoping to your actual scripts and resources, so it is usually added after the simpler headers.
Why is my security header missing even though I added it to my server config?
A CDN, reverse proxy or caching layer in front of your origin server can strip or overwrite headers before they reach the visitor. Check the header at the edge (what this tool sees) as well as directly against your origin server to isolate where it's being dropped.
Does adding these headers affect SEO directly?
Not as a direct ranking factor, but HTTPS enforcement via HSTS supports the HTTPS signal Google has confirmed it uses, and a hardened site is less likely to be compromised and later flagged as unsafe in search results or browsers — an indirect but real effect.
Can I check headers for a page that requires a login?
No — this tool makes an anonymous request with no cookies or authentication, so it will show whatever headers a logged-out visitor receives, not what an authenticated session would see.
What is the difference between X-Frame-Options and CSP frame-ancestors?
They solve the same clickjacking problem, but frame-ancestors is a Content-Security-Policy directive that is more flexible (it can allow specific origins) and is the modern recommended approach. X-Frame-Options is older, simpler, and still widely supported by browsers that don't fully implement the CSP directive.
Security

Is the http headers checker safe to use?

This tool sends the URL you enter to our server, which makes a live HTTP request to that address and returns the response headers to your browser. Do not enter internal or private URLs — the request originates from our server, not your browser, so it cannot reach anything on your local network, but it can reach any public address you provide.

No account required No file storage HTTPS everywhere
Sources

Where do these figures come from?

Every method, threshold and standard this page relies on, with a link to the document that defines it. Check them — a tool that will not show its sources is asking you to take its word for it.

  1. 1
    HTTP Strict Transport Security (HSTS)

    IETF, RFC 6797 · 2012

    Supports: The description and default value of Strict-Transport-Security, and the claim that it forces browsers to only connect over HTTPS.

  2. 2
    Content-Security-Policy

    MDN Web Docs

    Supports: The description of CSP restricting which scripts and resources a page may load to limit XSS damage.

  3. 3
    X-Frame-Options

    MDN Web Docs

    Supports: The description of X-Frame-Options blocking a page from being framed to prevent clickjacking, and its SAMEORIGIN/DENY values.

  4. 4
    X-Content-Type-Options

    MDN Web Docs

    Supports: The description of the nosniff value stopping the browser from MIME-sniffing a declared Content-Type.

  5. 5
    Permissions-Policy

    W3C, Permissions Policy specification

    Supports: The description of Permissions-Policy restricting which browser features a page and embedded frames may use.

Get in touch

Need something this tool can’t do?

If you need a feature added, spotted something wrong, or want a custom tool or website built for your business, tell us. We read every message and we build what people actually ask for.