Skip to main content

HTTP Headers Checker

See every response header a URL sends, follow the redirect chain hop by hop, and check the security headers with an explanation of each.

Related tools

All Webmaster tools →
New
SSL Certificate Checker Inspect the live TLS certificate a domain serves: when it expires, who issued it, and exact…
New
URL Parser Break a URL into its parts, list its query parameters, strip tracking codes to get the cano…
New
Port Checker Check whether a TCP port on a public host accepts connections from outside your network, an…
New
User Agent Parser Paste a user-agent string to identify the browser, engine, operating system and device, and…
New
Robots.txt Generator Build a robots.txt, then test any URL against it to see exactly which rule applies and why.…
New
Meta Tag Generator Generate title, description, canonical, Open Graph and X card tags, with a live search prev…

This tool needs our server to process your file. It is sent over an encrypted connection, stored only while it is being processed, and deleted automatically within 60 minutes. We never read the contents or keep a copy.

About the HTTP Headers Checker

Fetch a URL from outside your own network and see exactly what comes back: the status code, every response header, the full redirect chain, and how long it took.

Checking from outside matters. A header set by a CDN, a reverse proxy or a security appliance appears in the response a visitor gets and not in the one your application produces — which is why "we set that header" and "the header is not there" are both routinely true at the same time.

Redirects are followed one hop at a time and each is listed. A chain of three redirects is three round trips before anything renders, and it is usually two more than intended — the classic being http to https, then non-www to www, then a trailing slash, each added by a different person over several years.

The security headers are reviewed with an explanation of what each one does and why it might matter to you. The grading is deliberately conservative: a missing header is reported as missing, not as a vulnerability. Several of these are unnecessary for some sites and actively wrong for others, and a checker that paints every absence red teaches people to add directives they do not understand — which is how a Content-Security-Policy ends up breaking a site.

How to use the HTTP Headers Checker

  1. Enter a URL

    With or without the scheme — https is assumed. Only public hosts can be checked, on the standard web ports.

  2. Read the status and timing

    The final status code, the address that answered, and how long the whole chain took including every redirect.

  3. Follow the redirect chain

    Each hop is listed with the status it returned and where it pointed, so a chain that could be one redirect is obvious.

  4. Review the security headers

    Each is explained in terms of what it prevents. Headers that do not apply — HSTS on a plain HTTP response — are marked as such rather than counted against you.

Frequently asked questions

Why do the headers here differ from what my server config says?

Because what a visitor receives is what leaves the last thing in the chain, not what your application produced. A CDN, a reverse proxy, a load balancer or a WAF can each add, replace or strip headers. Checking from outside is the only way to see the response that actually gets delivered.

How many redirects is too many?

One is normal, two is worth looking at, three or more is worth fixing. Every hop is a full round trip before anything renders, which on a mobile connection is easily a quarter of a second each. The usual cause is layers added over the years — http to https, then non-www to www, then a trailing slash — where one rule could do all three.

Which security headers do I actually need?

Strict-Transport-Security and Content-Security-Policy do the most work, and CSP is the hardest to add later. X-Content-Type-Options is a single value with no downside. X-Frame-Options is superseded by the frame-ancestors directive in a CSP, so it is only needed for older browsers. Permissions-Policy matters mainly if you embed third-party frames.

Why does it say HSTS is not applicable?

Because a Strict-Transport-Security header on a plain HTTP response is ignored by every browser, deliberately — otherwise an attacker on the network could inject one and lock a visitor out of a site. If you saw that message, check the HTTPS URL instead.

What do you log about my check?

That a check happened, so we can spot abuse. Not the URL, not your address. The fetch itself sends nothing about you to the site being checked beyond our own user agent — no referrer and no cookies.