HTTP Header Checker
Read the live response headers for any URL, and what the HSTS, Cache-Control and CSP values actually commit you to. Free, no signup.
Every response your server sends carries a set of headers that decide how browsers, CDNs and crawlers treat it, all of it settled before a byte of HTML is rendered. This checker requests any URL, follows the redirect chain to the response that answers with content, and lists what came back: the full header set, plus seven security and caching headers marked present or missing.
The headers worth checking first
Present or missing is the easy half. A Strict-Transport-Security header with a two-minute lifetime is present and protects nobody, and a Cache-Control header can be present while telling every cache to throw the response away. Here is what to read in the values.
Strict-Transport-Security
HSTS tells a browser to refuse plain HTTP for this host for the next max-age seconds. The refusal is absolute: no warning page, no click-through, the request is rewritten to https:// before it leaves the machine. max-age=31536000 is a year, measured from each visit, so the clock restarts on every response that carries the header.
That commitment runs in both directions. If a certificate expires while the policy is in force, visitors who have seen the header cannot reach the host at all until it is fixed. Backing out means serving max-age=0for long enough that every cached policy expires, which is not an afternoon’s work.
includeSubDomains extends the policy to every host under the domain, including the ones nobody remembers: a staging box, an old webmail interface, an internal tool on a self-signed certificate. Inventory them before you add the directive.
preload is a separate step with a longer commitment. It submits the domain to a list compiled into Chrome, Firefox, Safari and Edge, so those browsers enforce HTTPS for you before they have ever seen a response from your server. Removal rides browser release trains and takes months.
Preload exists because of the gap at the start. A header can only travel on a response, so the first request a browser makes to a host it has never visited is unprotected. Someone who types your domain sends a plain HTTP request, and the spec requires browsers to ignore an HSTS header received over that connection anyway. Only the HTTPS response can install the policy. Preload is the one thing that covers the request before it.
Cache-Control
Cache-Control decides who may store a response and for how long. Two pairs of directives cause most of the trouble.
public and private name who is allowed to keep a copy. privatemeans the visitor’s own browser and nothing else: a CDN, a corporate proxy, a reverse proxy in front of your app must not store it. public is the opposite, and it also overrides the defaults that would otherwise keep a response out of shared caches. Anything personalized needs privateat minimum. A page rendered with one user’s name and cached as public is served to the next visitor.
max-age and s-maxage set the lifetime. max-age applies to every cache; s-maxage applies only to shared ones and overrides max-age there. That split is what lets you hold a page at the CDN for an hour while browsers revalidate every minute, which is the right shape whenever you can purge the CDN and cannot purge a browser.
no-store and no-cache are not two versions of the same idea. no-store means do not write this response anywhere. no-cache means store it freely, then revalidate with the origin before serving it again. A response marked no-cache is on disk. If what you are protecting is an account balance or a password reset page, no-cache is the wrong header and no-store is the one you meant.
Content-Security-Policy
CSP is the header where a mistake takes the page down instead of leaving it slightly less safe. An enforcing policy blocks everything it does not explicitly allow, and real pages load more than anyone remembers: analytics, an embedded video, a font host, a payment iframe, a tag manager injecting scripts nobody on your team wrote.
Start with Content-Security-Policy-Report-Only. It is the same policy under a different header name. The browser evaluates it, blocks nothing, and reports each thing it would have blocked to the endpoint you name. Run it across real traffic for a couple of weeks, read the violations, fold the legitimate ones into the policy, then rename the header to start enforcing.
Note which header the checker found. The key list looks for Content-Security-Policy exactly. If you are still in report-only mode, the value shows in the full header list under content-security-policy-report-only and the key list marks CSP as missing, which is accurate: report-only enforces nothing.
X-Content-Type-Options
One header, one value: nosniff. Without it a browser may disregard your Content-Type and guess from the bytes, which is how a file uploaded as a harmless text document ends up executed as HTML on your own origin. Set it everywhere.
The one thing to know before deploying it is that nosniff also makes browsers strict about scripts and stylesheets. A JavaScript file served as text/plain is refused rather than guessed at. That occasionally breaks something on the day the header goes out, and what it broke was a misconfigured Content-Type that had been surviving on luck.
Referrer-Policy
Referrer-Policy controls how much of the current URL travels in the Referer header when a visitor follows a link or your page loads a third-party asset. With no header set, modern browsers default to strict-origin-when-cross-origin: the full URL on same-origin requests, the origin alone across origins, nothing at all when going from HTTPS to HTTP.
That default is reasonable, which is why this header sits in the full response list rather than the key checklist. Set it explicitly when your URLs carry something worth protecting: a reset token, an invite code, an account id in the path, a search query that might contain a name. no-referrer or same-origin keeps those from leaving the site. The cost is attribution, since the sites you link to stop seeing you as the source.
Content-Encoding
Content-Encoding answers a question people usually settle by guessing: is compression actually on? A compressed response names its codec here — gzip, br for Brotli, zstd. No Content-Encoding on an HTML, CSS, JavaScript or JSON response means nothing compressed it and you are paying the full byte count on every request.
Compression is negotiated per request, so it fails in one place rather than all at once. A proxy that strips Accept-Encoding turns it off for everything behind it. CDN compression rules list MIME types, and application/json, image/svg+xml and font types are the ones routinely left off. Most servers also set a minimum size, so a very small response with no Content-Encoding is normal rather than broken.
The value shows in the full response list, not the key checklist.
Reading a header response for a page that redirects
A URL that redirects produces two responses, not one. The 301 is a response with its own headers. The 200 at the end of the chain is a different response with a different set. They are generated at different points in your stack, and they routinely disagree.
This checker follows the chain and reports the final response, because that is the page a visitor actually gets. The hops are the part you have to go looking for, and they are where security headers tend to be missing. A redirect is often emitted before your application runs at all: an edge rule at the CDN, an nginx return 301, a rewrite in .htaccess. Whatever middleware attaches your headers sits further down the road and never executes.
nginx has its own version of this. add_header directives are not inherited by a block that declares an add_header of its own, so a redirect location that sets one thing silently loses every header from the level above it. Repeat them in the block, or set them at the edge where every response passes.
To see a hop’s headers, request it without following. curl -sI https://example.com prints the first response only, since curl does not follow redirects unless you pass -L. A browser’s Network tab shows the same thing, one row per hop, each with its own response headers. The redirect chain checker maps the path first, so you know which URLs to inspect.
The case worth checking is HSTS, because it is per host and cannot be repaired by the final page. Suppose example.com only ever redirects to www.example.com, and that redirect comes from an edge rule with no headers on it. The visitor lands on a well-configured page and stores an HSTS policy for www.example.com. The bare domain stores nothing, because it never sent the header on a response of its own, and every future visit to it starts with the same unprotected request.
How it works
- 01
Enter a URL
Paste any reachable address — a page, an API endpoint, a static asset. Use the https:// form if you are checking HSTS.
- 02
Read the response
Sitewell requests the URL, follows the redirect chain, and captures every header on the response that finally answers.
- 03
Read the values
Seven key headers are marked present or missing, with the complete response listed underneath. The sections below cover what the values mean.
Frequently asked questions
- How do I check if HSTS is enabled?
- Run the https:// form of the URL through the checker and look for strict-transport-security in the key header list. Two things matter beyond present or missing. The header only counts on an HTTPS response, because browsers ignore it when it arrives over plain HTTP, so testing the http:// address tells you nothing. And the value decides how much it does: a max-age of a few minutes is technically enabled and protects nobody. Check subdomains separately unless the policy carries includeSubDomains, since HSTS is stored per host.
- What Cache-Control header should I use?
- It depends on whether the content at that exact URL can change. Static assets with a hash in the filename never change, so 'public, max-age=31536000, immutable' is correct: a new build produces a new filename. HTML that gets updated needs revalidation instead — no-cache lets caches keep a copy but forces a check with your server before reusing it, and an s-maxage in front of that lets a CDN hold the page while browsers keep checking. Personalized responses need private so shared caches stay out of them, and anything genuinely sensitive needs no-store.
- How do I check my security headers?
- Paste the URL above. The key header list reports Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and X-Frame-Options alongside Cache-Control, Content-Type and Server, and Referrer-Policy and Content-Encoding appear in the full response list underneath. Check more than the homepage. Headers are usually attached by one piece of middleware, and a static asset, an API route or a file served straight from the CDN may never pass through it, so two URLs on the same domain can return completely different sets.
- Why are my headers missing on the redirect?
- Because the redirect is a separate response, generated earlier in the stack than whatever adds your headers. An edge rule at the CDN, an nginx return 301, or a rewrite in .htaccess answers the request before your application runs, so application middleware never gets a chance to attach anything. nginx adds a second cause: add_header directives are not inherited by a block that declares its own add_header, so headers set at the server level disappear inside a redirect location. Set them where the redirect is emitted, or at the edge so every response carries them.
- Does a missing security header hurt SEO?
- Not directly. Rankings do not depend on whether you send Content-Security-Policy or X-Content-Type-Options, and no search engine has said otherwise. The cost lands elsewhere: vendor security questionnaires ask for these headers, third-party risk-rating services score domains partly on them, and any penetration test lists the ones that are absent. There is an indirect route to real ranking damage, since a site compromised through the class of attack a header would have blocked loses far more than a header audit ever could, but the header itself is a security control rather than a ranking signal.
- What are HTTP response headers?
- They are the metadata a server sends with every response, ahead of the content itself: the content type, caching rules, security directives, the server software, cookies. Browsers, CDNs and crawlers act on them before a byte of your HTML is rendered, so a wrong or missing header changes behavior you would never find by reading the page source.
- Does this checker show the redirect's headers or the final page's?
- The final page's. It follows the chain to the response that actually answers with content and lists that response's headers, which is what a visitor's browser ends up holding. To read the headers of a hop, request it without following redirects: curl -sI prints the first response only, and a browser's Network tab gives every hop its own row.