Why does my browser say “not secure” when my site has HTTPS?

Having HTTPS available is not the same as using it: a visitor who types the domain or follows an old link may land on the HTTP version.

If nothing redirects HTTP to HTTPS, that visitor sees the site unencrypted and the browser says so.

Check the address bar: if it shows http:// or no scheme with a warning, this is the cause.

The fix is a permanent redirect from every HTTP URL to its HTTPS equivalent, followed by HSTS once the redirect is reliable.

The page is HTTPS, and something it loads — an image, a script, a stylesheet, a frame — is requested over HTTP.

Browsers block active content such as scripts outright, which usually breaks something visibly.

Passive content such as images is upgraded to HTTPS or loaded with a degraded padlock, depending on the browser.

The references usually come from content stored in a database with absolute HTTP URLs, or from a third-party embed written years ago.

The browser console lists each mixed request, which is the fastest way to find them.

A form on an HTTPS page whose action points at an HTTP URL would send what the visitor types unencrypted.

Browsers warn when such a form is used, and some mark the page as not secure as soon as the field is focused.

It is common with newsletter sign-up forms pasted from a provider's old embed code.

The fix is changing the form action to HTTPS, which the receiving service almost always supports.

An expired certificate, a certificate that does not include this host name, or one signed by an authority the browser does not trust.

These usually produce a full-page warning before the page loads rather than a quiet label, which distinguishes them from the first three causes.

A missing intermediate certificate can produce the warning on some devices and not others, because some clients fetch or cache the missing piece.

A certificate valid for the main domain and not for the www host, or the reverse, is a frequent version of the name problem.

Clicking the padlock or the warning shows the certificate the browser actually received.

Look at the address bar first: an HTTP scheme is cause one.

If the page is HTTPS and loads normally with a warning label, open the console and look for mixed-content messages — cause two.

If the warning appears only when you interact with a form, check the form's action — cause three.

If you saw a full-page warning before the page appeared, inspect the certificate — cause four.

Check a second page and a second browser, since mixed content and forms are often confined to one template.

Store internal links and embedded resources as relative or HTTPS URLs, so content entered later does not reintroduce HTTP references.

Once the redirect and the pages are clean, HSTS makes browsers refuse the HTTP version entirely, which closes the first cause for returning visitors.

A Content-Security-Policy directive can ask browsers to upgrade any remaining HTTP requests automatically while the references are being cleaned up.

Set certificate renewal to run automatically and alert on failure, since an expiry is the one cause that arrives on a date.