Why Does My Website Say "Not Secure" (and How to Fix It)

Chrome shows “Not Secure” when a page isn’t served over valid HTTPS — usually because the site has no SSL certificate, the certificate is expired or untrusted, or the page mixes HTTP resources into HTTPS. Fix the certificate and force HTTPS site-wide.

For the site owner (plain English)

In everyday terms, “Not Secure” means the browser can’t confirm the connection to your page is private. It is not saying you’ve been hacked. But it does scare visitors away and quietly warns them not to type anything into your forms, so it is worth fixing promptly rather than urgently. Almost every case comes down to one of three things: no HTTPS certificate at all, a certificate that has expired or is for the wrong name, or a secure page that still loads one or two images or scripts over the old insecure address. The simplest path: ask your host to turn on their free SSL certificate (most do this in one click), then have them force every visitor onto the secure version of the site.

What does the “Not Secure” label actually mean?

The “Not Secure” warning in the browser address bar is a per-page verdict, not a virus alert or a hacking accusation. It is the browser’s plain-language way of saying: the connection to this page is not encrypted, or its encryption could not be fully verified. Modern versions of Chrome, Edge, Firefox and Safari all expect every page to load over https:// with a trusted TLS certificate. When that expectation isn’t met, the browser replaces the padlock with a warning so visitors know that anything they type — passwords, card numbers, contact details — could be read or altered by anyone on the network between them and your server.

There are three broad reasons a page earns the label, and almost every real-world case is one of them: the page is served over plain HTTP with no certificate at all; the page is served over HTTPS but the certificate has a problem (expired, untrusted, or for the wrong domain); or the page is HTTPS but pulls in some resources over insecure HTTP, which downgrades the whole page. The rest of this guide walks each cause in turn and links to the specific fix.

Cause 1: does the site have HTTPS at all?

The most common cause is the simplest: the page is being delivered over http:// instead ofhttps://, and the server has no SSL/TLS certificate installed. Every plain-HTTP page is flagged, with no exceptions. If your address bar shows http:// and never switches tohttps:// even when you type it manually, this is your situation.

How to fix it

• Install a certificate. Most hosts and CDNs issue a free, automatically renewing certificate (commonly via Let’s Encrypt) with one click in the control panel. If yours doesn’t, ask support to enable SSL for your domain.
• Force HTTPS with a redirect. Once the certificate is live, redirect everyhttp:// request to its https:// equivalent with a permanent (301) redirect so visitors and search engines always land on the secure version.
• Add HSTS. Send the Strict-Transport-Security header so browsers refuse to connect over plain HTTP at all in future. See our guide to HSTS and preloading for the exact header and the caveats before you turn it on.

A minimal Apache redirect looks like this; most platforms have a one-line equivalent:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Cause 2: is there a problem with your certificate?

Sometimes HTTPS is configured but the certificate itself fails validation, so the browser shows a full interstitial warning page rather than a quiet address-bar note. The three usual problems are an expired certificate, an untrusted issuer (often a self-signed or incomplete chain), or a name mismatch where the certificate was issued for a different domain than the one being visited.

• Expired certificate. Certificates last 90 days to about a year and must be renewed. See how to fix an expired SSL certificate.
• Untrusted issuer or broken chain. This often surfaces as NET::ERR_CERT_AUTHORITY_INVALID; see the authority-invalid fix.
• The general “Your connection is not private” screen. Our walkthrough of that error covers every variant and how to tell a server problem from a local one.

To see exactly what your certificate looks like to the outside world — expiry date, issuer, the domains it covers, and whether the chain is complete — run it through our SSL checker. That tells you in seconds whether the problem is the certificate itself or something else on the page.

Cause 3: is mixed content downgrading your HTTPS page?

This is the cause that surprises people most. The page itself loads over a valid https://URL with a perfectly good certificate — and the browser still says “Not Secure” or shows an info icon instead of a padlock.

The reason is mixed content: the secure page is pulling in one or more resources — an image, a script, a stylesheet, a font, an iframe — over insecure http://. Because that insecure request can be tampered with, the browser refuses to treat the whole page as secure. MDN’s mixed content reference documents exactly how browsers block and downgrade these requests.

How to find and fix mixed content

• Open the browser console. Press F12, open the Console tab, and reload. Mixed-content requests appear as explicit warnings naming the exact http:// URL being loaded.
• Switch the offending URLs to HTTPS. Most of the time the same asset is available overhttps:// — just change the protocol. Update hard-coded links in templates, theme files, and your CMS database.
• Use protocol-relative or relative paths for your own assets so they always inherit the page’s protocol, and re-check the console until it is clean.

How do you verify the fix?

After installing a certificate, forcing HTTPS, and clearing any mixed content, confirm the result from the outside. Load the page in a fresh private window and check that the padlock appears and stays on every page — not just the homepage. Then scan the whole site so nothing is missed: an internal page, an old blog post, or a subdomain can still be flagged even when the homepage looks fine.

Frequently asked questions

Why does my website say Not Secure?

Your website says “Not Secure” because the page is not being served over valid, fully-trusted HTTPS. In practice this comes down to one of three things. First, the page may have no SSL certificate at all and load over plain http:// — every such page is flagged. Second, a certificate may exist but be expired, issued by an untrusted authority, or registered for a different domain than the one visitors are on. Third, the page may load over HTTPS while quietly pulling in images, scripts or fonts over insecure http://, which is called mixed content and downgrades the whole page. The fix depends on which applies: install or renew the certificate, force HTTPS redirects site-wide, and replace any hard-coded http:// asset URLs with their secure equivalents.

Is a Not Secure site dangerous to visit?

Reading a “Not Secure” page — for example a news article or a static brochure site — is generally low-risk, because the worst case is that someone on the same network could see which pages you viewed or tamper with what is shown to you. The real danger is entering information. Without encryption, anything you type into a form — passwords, payment card numbers, addresses, messages — travels in plain text and can be intercepted or altered in transit. So never log in, pay, or submit personal details on a page marked “Not Secure.” If it is your own site, treat the label as a signal to fix HTTPS promptly: visitors increasingly abandon sites that warn them, and search engines treat HTTPS as a ranking and trust factor.

How do I make my website secure (HTTPS)?

Making a site secure is a three-step process. First, obtain and install an SSL/TLS certificate for your domain — most hosting providers and CDNs offer a free, auto-renewing certificate that you enable with a single click, so you rarely need to buy one. Second, force HTTPS everywhere by adding a permanent (301) redirect from every http:// URL to its https:// version, so visitors and search engines always land on the encrypted page. Third, eliminate mixed content by updating any hard-codedhttp:// links to images, scripts, stylesheets and fonts. Once that is done, add theStrict-Transport-Security header so browsers refuse plain HTTP in future, then re-test the whole site — not just the homepage — to confirm the padlock appears on every page.

I have an SSL certificate but still see Not Secure — why?

Two things commonly cause this. The first is mixed content: your page loads over valid HTTPS, but it references at least one resource — an image, a script, a font, an embedded widget — over insecure http://. Even one such request makes the browser withhold the padlock. Open the developer console (F12) and reload; it will name the exact http:// URL, which you then switch to https://. The second cause is that you are not forcing HTTPS: the secure version works if typed manually, but the server still serves the plain-HTTP version by default, so visitors see the insecure page. Add a site-wide 301 redirect to HTTPS. It is also worth checking that the certificate itself is current and matches the exact domain, including the www variant.

Where to go next

For the full picture of how HTTPS, certificates, headers and the rest of your security posture fit together, read our pillar guide on website security. If your specific problem is a certificate or TLS warning, the sibling SSL/TLS errors guide covers every common error and its fix in one place.