HTTP Header Checker

How to Use This Tool

1. 1

   Enter the URL

   Use the exact URL you want to inspect, including http or https if you are testing a redirect. Typing the bare domain will not show you the redirect that a browser follows before it arrives.

2. 2

   Read the redirect chain first

   If there is one, it explains everything after it. The headers you care about belong to the final response, and a chain that is longer than expected is often the actual finding.

3. 3

   Check the security grade

   Each of the six headers is graded separately, so you can see whether a header is missing, present but weak, or doing its job.

4. 4

   Look at caching

   This is where the performance wins usually are. A page with no cache headers re-downloads everything on every visit, including for people who were just there.

5. 5

   Switch to all headers when something is odd

   The notable set covers the usual questions. The full list is where you find the CDN header, the framework fingerprint, or the stray header a plugin added.

What Headers Are, and Why They Are Invisible

Every response a server sends has two parts: the content, and a set of headers describing it. The browser reads the headers first and they decide almost everything about how the content is treated — whether it can be cached, whether scripts from other domains may run, whether the page can be placed inside a frame, and what a search engine is allowed to do with it.

None of this appears on the page. You can look at a site all day and learn nothing about its headers, which is why they drift out of correctness without anyone noticing. A CDN configuration changes, a plugin adds a directive, a migration drops one, and nothing visible breaks.

This is also why headers are worth checking as a routine step after any infrastructure change rather than only when something has gone wrong. By the time a header problem is visible, it has usually been in place for a while.

The Six Security Headers

This tool grades each of these rather than reporting present or absent, because the distinction matters. A Content-Security-Policy that allows everything is technically present and doing no work, and a checklist that ticks it off is telling you something untrue.

• Content-Security-Policy — controls which sources scripts, styles and images may load from. The strongest defence against cross-site scripting, and also the hardest to get right. A policy containing unsafe-inline gives back most of what it was protecting.
• Strict-Transport-Security — tells browsers to use HTTPS for this domain from now on, so the first insecure request never happens. Worth a max-age of at least a year; a short max-age is barely better than nothing.
• X-Content-Type-Options — a single value, nosniff, that stops browsers guessing a file's type and running something as a script that was not meant to be one. There is no reason not to set it.
• X-Frame-Options — stops your pages being loaded inside someone else's frame, which is what clickjacking depends on. The frame-ancestors directive in CSP supersedes it, but sending both costs nothing.
• Referrer-Policy — decides how much of the current URL is passed on when someone clicks away. Values like unsafe-url leak full URLs including any parameters in them, which is a privacy problem on any page with an identifier in the address.
• Permissions-Policy — declares which browser features the page may use: camera, microphone, geolocation. Mostly relevant if you embed third-party content, since it constrains what an embed can ask for.

Caching, Where the Speed Actually Is

Cache-Control is the header that decides whether a returning visitor downloads your assets again. Getting it right is one of the largest performance improvements available, and it costs nothing at runtime.

The main directives worth knowing: max-age sets how long a response stays fresh in seconds; no-cache means the browser may store it but must revalidate before using it; no-store means do not keep it at all; public and private decide whether shared caches such as a CDN may hold a copy.

The common mistake is no-store on things that could safely be cached forever. It is often applied broadly out of caution, and it means every image, stylesheet and script is fetched again on every single page view.

The pattern that works: long max-age for anything with a hash or version in its filename, since a changed file gets a new name anyway, and short or revalidating caching for HTML, which changes in place. ETag and Last-Modified give you the cheap middle ground — the browser asks whether anything changed and gets a small 304 back when nothing has.

Caching affects repeat visits rather than the first one, so it does not show up in a single cold performance test. Our Core Web Vitals Checker measures the first load; headers are where the second one is decided.

Redirect Chains

Each hop in a redirect chain is a full round trip before anything starts rendering, and on a mobile connection that is a real cost paid before the page has begun.

Chains accumulate rather than being designed. A site adds HTTPS, then www, then changes a URL structure, and each rule is added on top of the last. The result is a request that goes from http to https, then to the www version, then to the new path — four requests where one would do.

The status codes matter too. A 301 is permanent and tells search engines to update their index; a 302 is temporary and tells them to keep the old URL. Using 302 for a permanent move is common and quietly keeps the wrong URL in the index for a long time.

The fix is to collapse the chain so the first request lands on the final URL directly. Our Redirect Chain Checker is the focused version of this if the chain is the only thing you are looking at.

Headers That Affect Search Engines

• X-Robots-Tag — the header equivalent of a robots meta tag, and the only way to set noindex on a PDF or an image. Because it is invisible in the page source, a noindex here is one of the more difficult ranking problems to diagnose.
• Link with rel=canonical — a canonical declared in the header rather than the HTML. Also used for non-HTML files, and easy to miss when it disagrees with the one in the page.
• Content-Type — includes the character set. A mismatch here is what produces the mangled apostrophes and question marks that appear in search results.
• Vary — tells caches which request headers change the response. Getting it wrong on a site that serves different content to mobile is how the wrong version ends up cached.

What Headers Cannot Tell You

A good security grade means the headers are configured well. It does not mean the site is secure — headers are one layer, and they do nothing about an unpatched dependency, an exposed admin route or a database that trusts its input.

Equally, a missing header is not automatically a vulnerability. X-Frame-Options matters if being framed would let someone trick your users into clicking something; on a static documentation page it is close to irrelevant. Grades are a prompt to think, not a defect list to clear.

And headers describe the response, not the page. For what is actually in the HTML, our SEO Analyzer covers the on-page side, and the Open Graph Preview checks the social tags that decide how a link looks when it is shared.

Frequently Asked Questions

Related Tools