Free tool · No signup

HTTP security headers grader

One letter that sums up how well your server's response headers protect visitors — and the exact header lines to add to move it up.

No signup · Results in ~10 seconds · Nothing stored except the shareable report

What we check and why

How the grade is calculated

We request your page and read the HTTP response headers the server sends with it. Each security-relevant header is checked for presence and for a sensible value, and missing or weak headers deduct points according to their impact. The result is a score from 0 to 100 and a letter from A+ to F, shown large at the top of the report so you can compare before and after a change.

Strict-Transport-Security: at least six months, ideally with includeSubDomains and preload.
Content-Security-Policy: present, and without unsafe-inline, unsafe-eval or wildcard script sources.
Clickjacking protection with frame-ancestors or X-Frame-Options.
X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy.
Server and X-Powered-By headers revealing software versions.
Cookie flags, exposed files such as .git or .env, mixed content and security.txt.

What each header protects against

HSTS tells browsers to use HTTPS only, so nobody on a café network can downgrade a visitor to an unencrypted connection. A Content-Security-Policy limits which scripts may run, which blunts cross-site scripting. Frame protection stops other sites from embedding your pages to trick visitors into clicks. nosniff prevents browsers from guessing file types in a dangerous way, and a Referrer-Policy keeps full URLs, which may contain names or case numbers, from leaking to other sites.

None of this replaces keeping your software updated, but these headers are cheap insurance against whole categories of attack.

Raising your grade

Most headers are a single line in your web server, hosting panel, CDN or a security plugin. Start with nosniff, frame protection, Referrer-Policy: strict-origin-when-cross-origin and HSTS once you are sure every subdomain works over HTTPS. Content-Security-Policy takes more care: start in Report-Only mode, look at what would be blocked, then enforce it.

Remove version numbers from the Server and X-Powered-By headers. After each change, run the grader again; the report shows the header values we received so you can confirm the server actually sends them.

Headers and your CDN or host

If you use a CDN or managed hosting, headers may be set in more than one place, and the CDN may add or remove some. Configure them where your provider recommends and test the live result here, since the header that counts is the one the browser actually receives. Check again after changing host, CDN or security plugin.

Frequently asked questions

How is this different from the security headers check?

It runs the same header and exposure checks but leads with the letter grade, for a quick before-and-after comparison. The security headers check also includes the full SSL/TLS test.

Will a Content-Security-Policy break my site?

It can if it is too strict. Deploy it as Content-Security-Policy-Report-Only first, review the violations, then switch to enforcing.

Is X-XSS-Protection still needed?

No. Modern browsers have removed the feature it controlled. A Content-Security-Policy is the current protection.

Does an A+ mean my site cannot be hacked?

No. Headers reduce the impact of certain attacks. Software updates, strong passwords, two-factor login and backups remain essential.