LogoTools
Uses a small server-side call for part of this tool - see below for what's sent

Fetches a URL's raw HTTP response headers and grades them against well-known security-header best practices, the same headers tools like securityheaders.com check: Strict-Transport-Security, Content-Security-Policy, clickjacking protection, Referrer-Policy, Permissions-Policy, and whether the response leaks its software stack via Server/X-Powered-By.

Why this needs a server

A browser's fetch() can't read most response headers from a different origin. That is a CORS restriction by design, not a missing feature. Checking another site's headers takes a request that same-origin rules don't bind, and that is what WebSync's own server does here: it fetches the URL you enter and hands the raw headers back for grading in your browser.

What the grade does and doesn't mean

The score is a fixed checklist with hardcoded point deductions. It is no penetration test and no guarantee of security. A site can score 100 here and still carry vulnerabilities these headers do nothing about, and a lower score doesn't mean a site is unsafe, only that it's missing some standard defense-in-depth headers.

Headers set by client-side JavaScript, as opposed to the server's own response, won't show up. This is a plain HTTP fetch, and it executes nothing on the page.

Frequently asked questions

Is the URL I check sent anywhere?

Yes. The URL goes to WebSync's own server, which fetches it (a GET request, headers only, with no page content downloaded or stored) in order to read the response headers, since browsers can't read another origin's headers directly. Nothing else on this site works this way.

Why does it use GET instead of a lighter HEAD request?

A meaningful number of servers answer HEAD requests differently from GET, or reject HEAD outright, which would silently produce wrong results. This uses GET and aborts the transfer the moment the response body starts arriving. Headers always come first, so nothing past them is downloaded.

Why isn't a header I know is set showing up?

Two causes come up often. Client-side JavaScript may be setting it in place of the server's real HTTP response, and only real response headers are visible here. Or the header is set differently depending on the request path or resource type, and the URL you checked happens not to set it.