Free Tool
Security Header Learning Tool
When a website answers your browser, it sends headers — small lines of instructions that tell the browser how to behave. Some of those headers are security headers: they stop the browser running untrusted scripts, force an encrypted connection, or block the page being framed by another site. Paste a set of headers below and this tool explains each one in plain English. It never contacts a website — you paste the headers, it reads them here.
Paste-only — this tool never probes a live site. Scanning a website you do not own, without permission, is unauthorised probing. This tool only reads header text you paste into it — copied from your own site's response, or from the worked example below.
What this tool does
HTTP response headers are the metadata a server sends with every page: the content type, the length, the caching rules, and — for the security headers — the instructions that protect the visitor. A Content-Security-Policy tells the browser which scripts it may run and where they may come from. Strict-Transport-Security tells it to use HTTPS for this site from now on, and never to accept plain HTTP. X-Content-Type-Options tells it not to guess the type of a file, which blocks a class of attacks where a harmless-looking file is reinterpreted as a script. X-Frame-Options and the frame-ancestors rule tell it whether the page may be embedded inside another page, which blocks clickjacking. And the Referrer-Policy and Permissions-Policy tell it how much information to share, and which powerful features — camera, microphone, location — a page may use.
This tool teaches those headers by reading them. You paste a block of headers — copied from your browser's developer tools, from a response you received from your own site, or from the worked example built into the page — and the tool parses each line, names the header, and explains what it does, whether the value is a good one, and what is missing. It also flags the headers that are not security headers at all, so you can tell the difference between a security instruction and an ordinary piece of metadata.
The tool is for people learning how the web works — students, junior developers, and anyone who has seen a security-header report and wanted to understand what it meant. It is not a scanner, it does not grade a site, and it never contacts a website: the paste-only design is the point, because probing a site you do not own without permission is not something this site will do, even for education.
Try it
Paste response headers (one per line, Name: value) and the tool will explain each one. Use the worked example, or copy headers from your own site's response in your browser's developer tools.
Waiting. Paste headers and press Explain these headers — or load the worked example.
How it works
The tool parses the pasted text line by line. Each line is split at the first colon into a name and a value, and the name is matched, case-insensitively, against a built-in table of known security headers. For each known header the tool explains what it does in plain English, and checks the value against what a good value looks like: a Strict-Transport-Security with a long max-age and includeSubDomains is good; a Content-Security-Policy that allows everything is not a policy at all; an X-Content-Type-Options that says anything other than nosniff is not doing its job.
Headers the tool does not recognise are reported as unknown rather than guessed at, because inventing an explanation would be worse than admitting ignorance. Ordinary headers — content-type, cache-control, server — are named as non-security headers, so you can see the difference between the metadata that every response carries and the instructions that protect the visitor. The tool also notes what is missing: a response with no Strict-Transport-Security and no Content-Security-Policy is a response with no security headers at all, and the tool says so plainly.
The worked example is a set of headers for a well-configured small site, and it is the best way to learn the tool. Load it, read the explanations, then compare it with a response you paste yourself — from your own site, or from a site you run. The comparison is the lesson: security headers are not mysterious, they are a short list of instructions, and once you can read them you can read any site's security posture from its first response.
Limitations
This tool explains headers you paste; it does not fetch, scan or grade a website. It cannot tell you whether a site is secure, because headers are one part of a site's security — the code, the configuration and the data handling matter as much, and none of those are visible in a header block. A site with perfect headers and a vulnerable application is still vulnerable.
- Paste-only by design. The tool never contacts a website, because scanning a site you do not own without permission is unauthorised probing, and this site will not do it.
- The tool explains the common security headers. It does not know every header in existence, and unknown headers are reported as unknown rather than guessed at.
- A header's presence does not prove it is configured correctly, and its absence does not always mean the site is unsafe — some protections are done another way. The tool explains what each header does, not whether a site passes a test.
Examples
Example 1 — the worked example. Load the worked example and read the explanations. It shows a Strict-Transport-Security with a one-year max-age, a Content-Security-Policy that allows scripts only from the site itself, X-Content-Type-Options set to nosniff, X-Frame-Options set to DENY, and a Referrer-Policy that sends no referrer on downgrade. That is a well-configured small site, and the tool says so for each header.
Example 2 — a missing header. Paste a block with only content-type and cache-control. The tool reports that there are no security headers at all, and explains what each missing header would have done. The lesson is that the absence of a header is information too — and that a site can work perfectly well without security headers while still being unprotected in the ways headers protect.
Example 3 — a weak policy. Paste a Content-Security-Policy that reads default-src *. The tool explains that this allows scripts from anywhere, which is barely a policy at all. A real policy lists the sources it trusts — its own domain, a named analytics domain — and blocks the rest. The difference between a policy and a decoration is in the value, and the tool reads the value, not just the name.
Frequently asked questions
What is a security header?
A line in a website's response that instructs the browser how to behave — for example, to run scripts only from trusted sources, to use HTTPS only, or to refuse to be framed by another page. They are instructions, not code, and they protect the visitor.
What does Content-Security-Policy do?
It tells the browser which sources it may load scripts, styles and other content from. A strict policy — scripts only from the site itself — blocks most cross-site scripting attacks, because an attacker's injected script comes from a source the policy does not allow.
What is HSTS?
Strict-Transport-Security. It tells the browser to use HTTPS for this site from now on and never to accept plain HTTP, which stops an attacker downgrading the connection. It is set with a max-age, usually a year, and includeSubDomains to cover the site's subdomains.
Why is this tool paste-only?
Because scanning a website you do not own, without permission, is unauthorised probing. This tool only reads header text you paste into it — from your own site, or from the worked example — so it can teach the concept without probing anyone.
Do security headers make a site secure?
They help, but they are one part of security. A site with perfect headers and a vulnerable application is still vulnerable. Headers protect the visitor's browser; the application, the configuration and the data handling must be sound too.