You open your own website, glance at the address bar, and there it is: a small "Not Secure" next to your domain. It's unsettling — and if a customer sees it on your checkout or contact form, it's worse than unsettling. The good news is that this label almost never means your site was hacked or infected. It's the browser telling you one specific thing: the connection to this page isn't encrypted. This guide explains exactly what triggers the warning, how it looks in Chrome, Firefox, Safari, and Edge, the handful of reasons it shows up, and the concrete steps to make it disappear for every visitor — not just for you.
In short
"Not Secure" means the page is loading over HTTP without a valid, trusted SSL/TLS certificate, so traffic isn't encrypted. The fix is to install an SSL certificate, then force every request onto HTTPS and make sure no resource on the page still loads over HTTP. Do that and the warning clears in every browser — a free certificate is enough to remove it.
What "Not Secure" actually means
The warning is a comment on the connection, not on the content of your site. When a page is served over plain http://, everything that passes between the visitor's browser and your server travels in the clear. Anyone positioned on the network in between — someone on the same café Wi-Fi, an internet provider, a compromised router — can read it, and in principle change it. Passwords, form entries, even the page itself are all exposed. The "Not Secure" badge is the browser's way of surfacing that risk in plain language.
The encryption that removes the risk comes from HTTPS, which is just HTTP wrapped in a TLS-encrypted tunnel. To set up that tunnel, your server needs an SSL/TLS certificate issued by a trusted certificate authority. With a valid certificate in place and the site loading over https://, the browser shows a neutral or padlock-style indicator instead of the warning. If you want the full mechanics, our explainer on what an SSL certificate is and how SSL works walk through it step by step.
Why browsers are so insistent about it. This isn't a new or aggressive policy. Google's Chrome began marking all HTTP pages "Not Secure" back in version 68 (July 2018), and the other major browsers followed the same logic. The reasoning was simple: secure should be the default, and the absence of encryption deserves to be visible rather than silently tolerated. So the warning appears on any HTTP page — it doesn't wait for something to go wrong.
How each browser shows it
The wording and icons differ slightly between browsers, which is why the same insecure page can look alarming in one and merely plain in another. Here's what each one does today.
| Browser | What you see on an HTTP page |
|---|---|
| Chrome | A "Not Secure" label beside the URL. Start typing into a form field and it can turn red. Notably, Chrome 117 (September 2023) retired the padlock for secure sites in favor of a neutral "tune" settings icon — because a study found 89% of users misread the old padlock — but HTTP pages are still flagged "Not Secure." |
| Firefox | A padlock with a red strike-through line. On an HTTP page with a login or password field, clicking into the field adds the text "This connection is not secure. Logins entered here could be compromised." |
| Safari | Shows "Not Secure" text in the address bar for HTTP pages, and a padlock when the connection is encrypted by a valid certificate. |
| Edge | Built on the same Chromium engine as Chrome, so it behaves the same way: a "Not Secure" indicator on HTTP, a neutral icon on HTTPS. |
The takeaway: the warning is generated entirely by the visitor's browser, based on how your page is served. You can't style it, suppress it, or talk it out of appearing. The only lever you control is the connection itself — and that's the part the rest of this guide fixes.
Why your site shows the warning
Almost every "Not Secure" page traces back to one of five causes. Identifying which one you have tells you exactly which fix below to apply.
1. No SSL certificate — the page is plain HTTP
The most common reason by far. The site has never had a certificate, so it only answers on http://. Every page is "Not Secure." Fix 1 below is for you.
2. A certificate exists, but visitors still land on HTTP
You installed a certificate, yet there's no redirect pushing people to the secure version, so http://yoursite.com still loads — insecurely. Fix 2 forces HTTPS.
3. Mixed content on an HTTPS page
The page itself loads over HTTPS, but it pulls in an image, script, stylesheet, or font over HTTP. That "mixed content" downgrades the page, so the browser shows a struck-through padlock or withholds the secure indicator. Fix 3 clears it.
4. An expired or not-yet-valid certificate
A certificate that lapsed — increasingly easy to miss as lifetimes shrink — or one whose start date hasn't arrived yet stops being trusted, and the page falls back to insecure. Fix 4 covers renewal.
5. A name mismatch or self-signed certificate
The certificate doesn't cover the exact hostname being visited (for example, it secures example.com but not www.example.com), or it's self-signed and not issued by a trusted CA. Both produce warnings. Fix 4 addresses these too.
Not sure which applies? Causes 4 and 5 usually trigger a louder, full-page warning with a specific error code (like an expired-certificate or name-mismatch message). Our guide to SSL certificate errors decodes each one. A quiet "Not Secure" with no full-page block almost always means cause 1, 2, or 3.
Fix 1: Install an SSL certificate
If your site has no certificate at all, this is the root fix — everything else builds on it. The process is the same whether you choose a free or paid certificate:
- Choose the right certificate. For most sites a domain-validated (DV) certificate is all you need to remove the warning. If you want a verified business name in the certificate, an OV or EV certificate adds that — but it isn't required just to clear "Not Secure."
- Generate a CSR and private key. On your server (or in your hosting panel) create a certificate signing request. The private key never leaves your control.
- Validate and get issued. The CA confirms you control the domain — typically via a DNS record or a file it asks you to host — then issues the certificate.
- Install it, including the intermediate. Upload the certificate and the CA's intermediate bundle. A missing intermediate is a classic misconfiguration that leaves some visitors seeing errors even when the certificate itself is fine — our guide to the certificate chain explains why.
Many hosting panels (cPanel, Plesk, and others) automate most of this, and we have step-by-step installation guides for the common platforms. If cost is the only thing holding you back, it shouldn't be: a free DV certificate encrypts traffic exactly as well as a paid one and removes the warning everywhere.
Want a paid certificate with support?
If you'd rather have a warranty and human help with installation, a DV SSL certificate is the quickest paid route to a trusted padlock. Not sure which type fits? Our certificate chooser narrows it down in a couple of minutes.
Fix 2: Force HTTPS everywhere
Installing a certificate makes the secure version available — it doesn't make visitors use it. Until you redirect traffic, people who type your domain, or follow an old HTTP link, still arrive on the insecure page and still see "Not Secure." The fix is a single permanent (301) redirect from HTTP to HTTPS.
The exact configuration depends on your server — Apache, Nginx, IIS, or a CMS like WordPress each have a one- or two-line rule. Our dedicated walkthrough, how to redirect HTTP to HTTPS, gives the copy-paste config for each, plus the X-Forwarded-Proto rule that prevents redirect loops behind Cloudflare and load balancers.
Make it stick with HSTS. Once the redirect works, adding an HSTS header tells browsers to use HTTPS automatically on every future visit, before they ever send an HTTP request. It's the belt-and-braces step that closes the brief window a plain redirect leaves open.
Fix 3: Clear mixed content
This is the maddening one: you have a valid certificate, the page loads over HTTPS, and it still won't show a clean secure indicator. The cause is mixed content — the HTML arrives securely, but it references at least one resource (an image, script, stylesheet, font, or iframe) by an http:// URL. Because that one resource is unencrypted, the browser can't call the whole page secure, so it downgrades the indicator or, for active content like scripts, blocks it outright.
To track it down, open your browser's developer tools (F12) and check the Console tab — it lists every mixed-content URL by name. Then update each reference to https:// (or a protocol-relative path), re-upload, and reload. On WordPress this is often a hardcoded image or a plugin pulling assets over HTTP. Our focused guide to fixing mixed content errors covers the platform-specific cleanups in detail.
Fix 4: Expired, wrong-name, or self-signed certificates
Sometimes the certificate is the problem rather than its absence. Three situations account for nearly all of these:
- Expired. A certificate past its validity date stops being trusted instantly. With shorter certificate lifetimes now the norm, this catches people out more often than it used to. The fix is to renew the certificate — and ideally automate renewal so it never lapses again.
- Name mismatch. The certificate must cover the exact hostname in the address bar. A certificate for the bare domain won't secure the
wwwversion (or vice versa), and a certificate for one subdomain won't cover another. Reissue with both names as SANs, or use a wildcard certificate to cover all subdomains at once. - Self-signed. A self-signed certificate encrypts traffic but isn't issued by a trusted CA, so public browsers reject it. It's fine for local development, but a public site needs a CA-issued certificate.
A note on full-page warnings
Expired, mismatched, and self-signed certificates usually produce a louder, full-page interstitial ("Your connection is not private") rather than the quiet "Not Secure" text. If that's what you're seeing, the exact error code on that page tells you which of these it is — and our SSL error reference maps each code to its fix.
How to confirm it's fixed
After you've installed the certificate, forced HTTPS, and cleared any mixed content, verify the result properly instead of trusting a single browser tab — caching can make a fixed page look broken (or a broken page look fixed).
- Load the HTTP version directly. Type
http://yoursite.comand confirm it redirects tohttps://automatically. If it doesn't, revisit Fix 2. - Check a few real pages, not just the homepage. Mixed content often hides on inner pages — a blog post with an old embedded image, say — while the homepage looks perfect.
- Test in a private/incognito window. This sidesteps your local cache and shows what a first-time visitor actually sees.
- Run an external check. An SSL checker tool inspects the certificate, the chain, the expiry date, and the hostname match from outside your network — confirming the fix holds for everyone, not just for you.
The bottom line
"Not Secure" isn't a verdict on your site's safety — it's a prompt to encrypt the connection. Install a trusted SSL certificate, redirect every request to HTTPS, and make sure no resource still loads over HTTP, and the warning is gone for good. If you're starting from scratch, our guide to what an SSL certificate is is the natural next read — and a free certificate is enough to make the label disappear.