🔒

SSL & Security Headers Checker

Verify that any website loads securely over HTTPS and audit its HTTP security headers — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and more. Missing headers leave visitors exposed and can hurt trust signals.

⚡ Interactive demo — sample data

Secure HTTPS connection, but 3 of 6 security headers are missing — including Content-Security-Policy.

HTTPS — secure connection with a valid certificate Looks good

HSTS (Strict-Transport-Security) present — browsers forced to use HTTPS Looks good

Content-Security-Policy missing — no protection against injected (XSS) scripts Issue

X-Content-Type-Options present — MIME-sniffing disabled Looks good

X-Frame-Options missing — page can be embedded in an iframe (clickjacking risk) Warning

Permissions-Policy missing — powerful browser features (camera, geolocation) are unrestricted Warning

This is a sample. Run the real check on your own URL above ↑

About this tool

How it works

Enter your website URL

Paste any URL and run the check. We make a real request to the site and follow it to its final destination, so we see whether it actually ends up on HTTPS — not just whether you typed https:// in the box.

Review HTTPS and headers

You get a clear verdict on the secure connection plus a row-by-row audit of six HTTP security headers — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Each missing header comes with a one-line explanation of what it protects.

Add the missing headers and re-run

Set the flagged headers in your server config, CDN, or app framework, then run the check again to confirm they're live. The score moves up as HTTPS and each header come into place.

What we check

HTTPS / secure connection — Confirms the final URL is served over HTTPS with a valid SSL/TLS certificate. Browsers mark plain HTTP pages 'Not secure', and Google has used HTTPS as a ranking signal for years — so this is the foundation everything else sits on.
HSTS (Strict-Transport-Security) — Tells browsers to only ever connect over HTTPS, even if a user types http://. It closes the brief window where a first request could be intercepted and downgraded. Without it, an attacker on the same network can strip your encryption.
Content-Security-Policy — Whitelists where scripts, styles, and other resources may load from. It's the strongest defense against cross-site scripting (XSS) — if a page is injected with a malicious script from an untrusted source, a good CSP blocks it from running.
X-Frame-Options — Stops other sites from embedding your pages in an invisible iframe to trick users into clicking (clickjacking). Set to DENY or SAMEORIGIN, or replace it with the modern CSP 'frame-ancestors' directive.
X-Content-Type-Options — The single value 'nosniff' stops browsers from second-guessing a file's declared type. Without it, a browser might execute a file you served as text as if it were JavaScript — a real attack vector on user-uploaded content.
Referrer-Policy & Permissions-Policy — Referrer-Policy controls how much of your URL is leaked to other sites users click through to (protecting query-string data and private paths). Permissions-Policy restricts powerful browser features — camera, microphone, geolocation — so a compromised script can't silently use them.

Common issues we catch

HTTPS works but HTTP isn't redirected — The secure version loads fine, but typing http:// serves an insecure copy instead of forwarding to HTTPS. Visitors and links can land on the unencrypted page. Add a permanent 301 redirect from http to https, then add HSTS so browsers stop trying http at all.
No HSTS header — Even with a perfect HTTPS setup, missing HSTS leaves the very first request vulnerable to a downgrade attack on untrusted networks. It's a one-line header most sites forget. Add it only once you're confident every resource is HTTPS, because it's sticky.
No Content-Security-Policy — The most impactful header is also the most commonly missing, because it takes real effort to configure without breaking legitimate scripts. Many sites ship with none at all, leaving them fully exposed to injected-script (XSS) attacks.
Headers set on the homepage only — Security headers added at one route or page template but not applied site-wide leave inner pages, APIs, and error pages unprotected. Headers should be set globally at the server or CDN edge, not per-page, so every response carries them.
A CDN strips or overrides your headers — A proxy or CDN layer can drop headers your origin sets, or inject its own that conflict. This checker reads the final headers the browser actually receives, so it catches the gap between what your app sends and what reaches the user.
Mixed content quietly breaking HTTPS — A page on HTTPS that loads a script, image, or stylesheet over http:// triggers browser warnings and can downgrade the padlock. The certificate is valid, but insecure sub-resources undermine it — a separate, easy-to-miss problem worth checking alongside this.
Expired or self-signed certificate — An SSL certificate that has lapsed or isn't from a trusted authority throws a full-page browser warning that stops most visitors cold. Auto-renewal can fail silently, so a site that worked last month can break overnight without anyone noticing.

Where this matters

All modern browsers — Chrome, Safari, Firefox, and Edge enforce these headers consistently and label non-HTTPS pages 'Not secure'. The headers we check are part of the platform-neutral web security standard every current browser respects.
Google Search — HTTPS has been a confirmed ranking signal since 2014, and Chrome's security warnings affect bounce rate and trust. A secure, properly headered site removes a class of soft ranking and conversion drags.
Cloudflare & CDN edges — Many sites terminate HTTPS and set or rewrite security headers at the CDN/proxy layer rather than the origin. Because we read the final delivered headers, this tool reflects what the edge actually serves — including anything it strips or adds.
WordPress, Shopify & hosted platforms — Most managed platforms provide HTTPS out of the box, but security headers vary: some require a plugin, server snippet, or theme edit to add CSP and HSTS. This check shows which ones your platform is actually sending.
Server & framework configs — Headers are typically added in your web-server config or application framework's response middleware. Whatever the stack, the fix is the same shape — emit the header on every response — and this checker verifies it landed.

Frequently asked questions

What's the difference between SSL and security headers?

SSL/TLS encrypts the connection between the browser and your server — that's the padlock and HTTPS. Security headers are separate instructions your server sends with each page that tell the browser how to behave safely, like forcing HTTPS (HSTS) or blocking injected scripts (CSP). You want both.

Do security headers affect SEO?

HTTPS itself is a confirmed Google ranking signal, so being on a secure connection helps directly. The other headers don't rank you on their own, but they prevent security incidents and browser warnings that damage trust, conversions, and ultimately the signals search engines care about.

What is HSTS and is it safe to enable?

HSTS (Strict-Transport-Security) tells browsers to only ever connect to your site over HTTPS. It's very effective but sticky — browsers remember it for the duration you set. Only enable it once every page and sub-resource works on HTTPS, or visitors could get locked out of broken HTTP content.

Why does Content-Security-Policy matter most?

CSP is the strongest defense against cross-site scripting (XSS), one of the most common web attacks. It lets you whitelist exactly where scripts and styles may load from, so an injected malicious script from anywhere else simply won't run. It takes effort to tune, which is why it's so often missing.

Is HTTPS enough on its own?

It's the essential baseline, but no. HTTPS encrypts the connection; it doesn't stop clickjacking, MIME-sniffing attacks, or injected scripts. The security headers add those protections on top. A site can have flawless HTTPS and still be missing every header.

My certificate is valid but the tool says not secure — why?

Usually because the page loads insecure http:// resources (mixed content) or the final URL didn't end on HTTPS after redirects. We follow the request to its real destination, so a valid certificate that isn't actually being served on the final page will still flag.

Where do I add these headers?

Set them globally on every response — typically in your web-server configuration, your CDN's edge rules, or your application framework's response middleware. Avoid adding them per-page; inner pages, APIs, and error responses need them too. After adding, re-run this check to confirm they're live.

How often should I check security headers?

Re-check after any server, CDN, or platform change, since those layers can silently strip or override headers. A periodic check — say monthly, or as part of a release checklist — catches certificate near-expiry and dropped headers before users hit a warning.

This is one of several free SEO tools from Custom Web Audits. For a complete, prioritized analysis of your whole website, run a full audit.