Browser DevTools -- the Network tab's Headers panel -- shows the raw response
headers for a request you've already made, for free, with nothing to install. It is a fine first
look at what a server actually sent, and for a page you're already inspecting it is often the
fastest option there is. What it does not do is apply the fallback rules that decide whether those
headers actually protect anything: that a CSP frame-ancestors directive does
not inherit from default-src the way script-src does, so
a policy of default-src 'self' alone gives zero clickjacking protection, or that an
X-Frame-Options: ALLOW-FROM value looks like frame protection in the panel and is
silently ignored by every current browser engine. Reading raw headers in a panel and knowing which
combinations quietly fail are two different skills.
This tool sends one request to a URL you name and classifies the response's
frame-protection, CSP-strength, and HSTS headers into named patterns -- missing clickjacking
protection, the dead ALLOW-FROM value, a CSP script-src allowing
'unsafe-inline' with nothing overriding it, a wildcard script source, CSP shipped only
as report-only, and a missing Strict-Transport-Security header -- stating in plain
English which header proves each one. It does not replace DevTools -- for a page open in your
browser right now, the Network tab is still the quickest way to glance at a response. It automates
the fallback-rule reasoning a person would otherwise have to redo by eye, every time, and it runs
from a terminal or CI job where clicking through a Network tab isn't practical.
| Question | Where to answer it |
|---|---|
| I have a page open in my browser and want a quick look at its response headers. | DevTools' Network tab -- that quick raw look is exactly its job. |
| I want to know whether frame-protection and CSP headers actually protect against clickjacking, applying the correct fallback rules. | This checker -- frame-ancestors does not inherit from default-src; a naive read of the panel can miss that. |
I want to know whether an X-Frame-Options: ALLOW-FROM value I can see in the panel is actually doing anything. |
This checker -- names it as ignored by every current major browser instead of leaving you to look that up. |
| I want this checked automatically on every deploy, with a non-zero exit code on a real problem. | This checker's CLI -- node check.mjs <url> --json exits non-zero on a danger-severity finding. DevTools has no CLI to wire into CI. |
| I'd rather not re-derive the CSP fallback rules from memory to read a headers panel myself. | This checker -- paste the CLI's JSON into the browser report and get the plain-English findings without already knowing the rules. |
Neither tool replaces the other, and in practice most people use both: DevTools for a fast raw look at one response you're already looking at, this tool for the recurring, automatable question of whether that response's frame-protection, CSP, and HSTS headers actually do what they look like they do.
node check.mjs https://example.com --jsonOne request to the URL you name, the same kind your browser already sends. Paste the JSON into the checker for the plain-English report.
Different jobs, and most people who use this tool also still open DevTools. The Network tab's Headers panel shows you the raw response headers for a request you've already made in your browser -- free, already installed, and often the fastest way to check one page you're looking at anyway. It does not tell you which of those headers, read together, form a well-documented weakness: whether an X-Frame-Options: ALLOW-FROM value is silently ignored by every current browser, or whether a CSP's frame-ancestors is missing because default-src alone does not cover it. This tool reads the same headers DevTools would show you and names the specific, well-documented pattern -- so you don't have to already know the CSP fallback rules to notice the problem.
If you already know that frame-ancestors doesn't inherit from default-src the way script-src does, that ALLOW-FROM is dead in every current browser, and that unsafe-inline is only a real gap when nothing overrides it, DevTools plus your own judgement is enough. This tool exists for the times you don't want to re-derive those rules from memory on every response, or when you want the same checks wired into your own CI as a non-zero exit code, which DevTools' UI cannot do -- it has no CLI and nothing to script against.
No -- it sees the same response headers DevTools already shows you, and nothing more. The difference is entirely in the reading: this tool applies the frame-protection, CSP-strength, and HSTS checks the same way every time, whether or not you remember the fallback rules, and it can run from a terminal or a CI job where opening a browser and clicking through the Network tab isn't practical.
No. The CLI's request goes directly from your machine to the URL you name, exactly like the request your browser already makes. The browser report viewer only parses JSON you paste into it yourself, locally in your browser -- nothing about the target, the headers, or the report is sent anywhere. The only thing stored is an anonymous local count of which features were used, with no target URLs or header values in it.
Want a hosted, single-grade outside read instead? See this checker vs. Security Headers (securityheaders.com).