Processed on our server. Your input is sent to our server to produce the result. Uploaded files are not kept, and nothing is sold or shared; our privacy policy lists what is logged.
Check a Website’s HTTP Security Headers
The Tools Kit’s free Security Headers Checker shows which HTTP security headers a website sends in its response. Enter a URL and it reports whether seven widely recommended headers are present, including HSTS, Content-Security-Policy and X-Frame-Options, and displays the exact value of every header it finds.
Security headers are instructions the server gives the browser: use HTTPS only, do not let other sites frame this page, do not guess file types, and so on. They cost nothing to add and shut down whole classes of attacks, which is why security scanners and penetration testers look for them first. Headers sit alongside transport security, so if you are auditing a site it is worth confirming its certificate with the SSL certificate checker at the same time, and to paste a certificate or signing request into the CSR and certificate decoder to read its fields.
How to Check Security Headers
- 1
Enter the website URL
Type a domain such as example.com or paste a full URL into the Website URL field. If you leave off the protocol, https:// is added for you.
- 2
Run the check
Click Check Headers or press Enter. Our server requests the page, following up to four redirects, and reads the HTTP response headers of the final page.
- 3
Read the summary
The summary line tells you how many of the seven common security headers were found, for example 4 of 7 common security headers present.
- 4
Review each header
Each header is listed with a green check if it was sent or a red cross if it was missing. For headers that are present, the exact value the server returned is shown underneath so you can confirm the policy is what you intended.
There is no sign-up and no cost. To keep the service fair, checks are rate limited per visitor, so if you run many in quick succession you may be asked to wait a moment.
What Each Security Header Does
These are the seven headers the checker looks for, what each one protects against, and a common starting value. The example values are typical configurations, not something the tool requires; the right policy depends on your site.
| Header | What it does | Common value |
|---|---|---|
| Strict-Transport-Security | Tells browsers to use HTTPS only for this site for a set time, blocking protocol downgrade and cookie hijacking on insecure networks | max-age=31536000; includeSubDomains |
| Content-Security-Policy | Lists which sources scripts, styles, images, frames and other resources may load from; the strongest browser-side defense against cross-site scripting | default-src 'self' |
| X-Frame-Options | Stops other sites from embedding your pages in a frame, which prevents clickjacking | DENY or SAMEORIGIN |
| X-Content-Type-Options | Stops browsers from guessing (sniffing) a file type that differs from the declared Content-Type | nosniff |
| Referrer-Policy | Controls how much of the current URL is sent in the Referer header when visitors follow links or load resources | strict-origin-when-cross-origin |
| Permissions-Policy | Turns browser features such as the camera, microphone and geolocation on or off for the page and its embedded frames | camera=(), microphone=(), geolocation=() |
| X-XSS-Protection | Legacy switch for an XSS filter that modern browsers have removed; current guidance is to disable it and rely on CSP | 0 |
A few practical notes. HSTS only takes effect when it arrives over HTTPS, so start with a short max-age and raise it once you are sure every subdomain works over HTTPS. The CSP frame-ancestors directive is the modern replacement for X-Frame-Options, but sending both keeps older browsers covered. And the checker looks only for the enforcing Content-Security-Policy header, so a policy sent as Content-Security-Policy-Report-Only shows as missing.
How the Header Check Works
Browsers do not let one site read another site’s response headers, so the request is made by our server rather than your browser. It sends a GET request to the URL, adding https:// if you typed a bare domain, and follows up to four redirects itself, such as http to https or the bare domain to www. Each request has an 8-second timeout. If the chain keeps redirecting past that point, the check stops with a Too many redirects error. Redirect status codes, and the 4xx or 5xx codes a server might return instead, are explained in the HTTP status codes reference.
Before every request, including each redirect, the hostname is resolved and checked so that localhost, names ending in .local or .internal, and private, loopback or link-local addresses are refused. If a name will not resolve at all, look up its records with the DNS lookup tool. Successful results can be cached by URL for up to 30 minutes, so a check repeated right after you change your server configuration may still show the previous headers.
The result is a presence check, not a grade. Each header gets a check or a cross, and present headers show their raw value, but the tool does not judge whether a policy is strict enough. To see the same headers yourself, run curl -sL -D - -o /dev/null https://example.com in a terminal (a GET request that follows redirects and prints the response headers), and if you want that command as code, the cURL converter turns it into JavaScript, Python or other languages.
How to Add Missing Security Headers
Headers are added wherever your responses are produced: the web server (an add_header line in Nginx or a Header set line in Apache), a CDN or edge rule, or your application framework’s header configuration. Adding them at the edge covers every route in one place; adding them in the app lets you vary the policy by page.
Roll out the low-risk headers first: X-Content-Type-Options, Referrer-Policy and X-Frame-Options rarely break anything. Content-Security-Policy needs more care, because a policy that is too strict blocks your own scripts, analytics or embeds, so trial it in report-only mode before enforcing it. After deploying, rerun this checker on the live URL to confirm the headers survived your CDN and proxy layers. Email has its own set of domain-level protections, which you can audit with the DMARC and SPF checker, and the port scanner helps confirm that only the services you intend to expose are reachable.
Common uses
- Auditing a website’s security header configuration before a launch or penetration test
- Confirming a header change went live after editing a server, CDN or framework config
- Checking that a CDN or reverse proxy is not stripping headers set by the origin server
- Reading back the exact CSP, HSTS or Permissions-Policy value a site is sending
- Comparing the headers of a staging and a production URL, or of competing sites
For certificate, DNS, hashing and token utilities, browse all security tools.
Security header terms explained
| Term | What it means here |
|---|---|
| HTTP response header | A name and value the server sends before the page content, giving the browser instructions about how to handle the response |
| HSTS | HTTP Strict Transport Security, the policy delivered by the Strict-Transport-Security header |
| CSP | Content Security Policy, an allowlist of where a page may load scripts and other resources from |
| Clickjacking | Tricking a user into clicking something on your site by loading it invisibly inside a frame on another site |
| MIME sniffing | A browser guessing a file’s type from its contents instead of trusting the declared Content-Type |
| Defense in depth | Layering several independent protections so one missing or bypassed control does not expose the site |
Frequently Asked Questions
Enter the domain or URL in the Website URL field and click Check Headers. The tool requests the page from our server, follows up to four redirects, and reports which of seven common security headers the final response includes, along with the exact value of each one that is present.
It checks seven headers: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and X-XSS-Protection. Other headers in the response are not listed.
No. It reports whether each header is present and shows the value exactly as the server sent it, but it does not score the site or judge whether a value is strong. A weak policy, such as a CSP that allows unsafe-inline scripts, still shows as present, so read the values yourself.
From our server. Browsers do not let a web page read another site’s response headers, so the check runs server-side. That also means it sees the headers that a CDN, load balancer or reverse proxy adds, exactly as a visitor would receive them.
Yes. It follows up to four redirects, for example from http:// to https:// or from the bare domain to www, and checks the headers on the final page. If a URL redirects five or more times, the check stops with a Too many redirects error.
Successful results for the same URL can be cached for up to 30 minutes, so a recheck straight after a change may show the old headers. Also make sure you are checking the exact URL that serves the headers, that a CDN or proxy is not stripping them, and that your server adds them to every response rather than only some routes.
The tool only looks for the enforcing Content-Security-Policy header. Content-Security-Policy-Report-Only logs violations without blocking anything, so it is not counted. Switch to the enforcing header once your reports are clean.
Modern browsers have removed the XSS filter this header controlled, and current guidance from OWASP is to send X-XSS-Protection: 0 or omit it, and to rely on Content-Security-Policy instead. The tool still checks for it, and a value of 0 counts as present.
Not necessarily. Security headers are defense in depth, so a missing one is a hardening opportunity rather than proof of an exploitable flaw. HSTS, CSP, X-Frame-Options (or the CSP frame-ancestors directive) and X-Content-Type-Options are the ones most worth adding first.
No. To stop the tool being used to probe internal networks, hostnames such as localhost and names ending in .local or .internal are refused, as are any hosts that resolve to private, loopback or link-local addresses. Only publicly reachable sites can be checked.
No, it checks the single URL you enter. Different paths can send different headers, for example an API route or a static asset served from a separate bucket, so check each important page on its own.
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026
How do you check which security headers a website sends?
To check security headers, enter a URL and the site is fetched server-side, following up to four redirects, and the final response is checked for seven headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and X-XSS-Protection. Each is marked present or missing, with its value shown when present.
Which security headers matter most?
Strict-Transport-Security forces HTTPS, Content-Security-Policy limits where scripts can load from, X-Frame-Options blocks clickjacking, and X-Content-Type-Options stops MIME sniffing. Those four cover the most common attacks. X-XSS-Protection is now considered obsolete, since modern browsers ignore it and rely on Content-Security-Policy instead.