Somebody told you. A customer, a friend, the person who does your invoices: your website says Not Secure. Or you saw it yourself, in grey, at the left end of Chrome’s address bar, on a site you paid to have built. So you typed the question into Google.
I read fifteen pages that answer it, nearly all of them from companies that sell certificates,
hosting or services. Then, on 25 September 2026, on my Mac, in Chrome 154.0.8037.57, I opened
public test pages built for this — badssl.com, broken in known ways, and neverssl.com — and one of my own sites, and took a screenshot of the
address bar and the page each time. One thing none of the fifteen mentions: Chrome
154, out since 22 September 2026, can ask before a plain http:// page opens, and its release
notes list that question as on by default.
The answer first. Chrome writes “Not Secure” in grey when the page arrived over plain http:// —
the address without the s. The page opens anyway. It writes the same words in red when it will
not accept the site’s certificate, and then the page does not open: a full page reading “Your
connection is not private” comes first. Images and scripts loaded over http on an otherwise secure
page — the cause six of the fifteen pages blame — and forms that send to http, which one other page
blames, showed no warning in the address bar on the test pages built to have them. The check needs
only a browser, so it comes first.
Type your address with http:// in front
In Chrome on a desktop, type your domain with http:// in front and press Enter. Then again with
www. after the http://, and once more with https://. One of four things happens, and the
message further down has a line for each.
The site opens, and the left end of the address bar shows only a small icon of two sliders. No words. That is what a fine page looks like in Chrome now. One caution: it does not prove your site forwards visitors from http to https. Chrome changes the address to https itself, before your server is asked: its help page for the setting, fetched 25 September, says so when “Always use secure connections” is on — “Chrome upgrades URLs to use HTTPS” — and a new profile with that setting off did the same.
A dimmed page and a card at the top, before anything opens: “This site doesn’t support a secure connection”, with “Continue to site” and “Go back”. The address you typed has no working https, or, says the guide for site owners quoted below, an address it forwards through has none, even if the page you end up on is secure.
On the https:// address, a full page reading “Your connection is not private”, with a red
chip in the address bar. A certificate problem, and the grey NET:: line on that page names which.
The page opens, and the chip says “Not Secure” in grey, with a small triangle. Your page is
served over plain http. Either this profile is not set to ask first (look in
chrome://settings/security for “Always use secure connections”; the roll-out is staged, and a
setting chosen earlier is kept), or the question was answered continue in this profile. Click the
chip: if the panel says “You have chosen to turn off security warnings for this
site”, it was answered here.
Chrome remembers your answer for 15 days
Chromium — the open-source code Chrome is built from — has a guide for site owners on the question, and it says how long Chrome keeps an answer:
Chromium’s guide for site owners, on how long Chrome remembers a visitor’s answer
Chrome remembers a user’s decision for 15 days, and the exception is renewed whenever a user revisits that site – this means that if a user regularly uses an HTTP site they may only ever see the warning once for that site.
You probably open your own site often: click continue once, and as long as you come back within
15 days, each visit renews that answer, and your Chrome stops asking. The answer is kept by the
Chrome profile that gave it, not by the computer: a second profile on the same machine has
its own settings. Whether a visitor is asked at all depends on their own setting; more
on that below. My own screen showed a kept answer: http://http.badssl.com, a test page served over plain http,
opened with the grey chip and no question, and the panel behind the chip read “You have chosen to
turn off security warnings for this site.” — answered in this profile at some earlier time, I do
not know when.
The message to send
Whoever runs your site will change something on the server and tell you it is done. Typing
http:// into Chrome cannot check that part, because Chrome tries https first by itself; a tool
that does not upgrade anything can. Fill in what you saw:
Copy and send
When I open my site in Chrome with http:// or https:// typed in front of the address, I get [the grey “Not Secure” chip, and the page opens / a card before the page opens: “This site doesn’t support a secure connection” / on the https:// address, a full page: “Your connection is not private”, with the line NET::ERR_CERT_… / no warning; it looks fine to me, but please confirm the forward, item 3]. Please fix whichever applies, and tell me:
-
Which address on the way in — the bare domain, the www address, or the page it forwards to — answers over plain http, and can it answer over https instead?
-
If it is the full page: do you see the same NET:: line from a computer that is not on my network? If so, please pass the code to whoever looks after the certificate.
-
When it is done, please check each address with a tool that does not change http:// to https:// by itself, the way Chrome does, and send me what a plain http:// request to each returns.
A grey chip, and the page opens anyway
On http://http.badssl.com, a test page whose only fault is that it is served over plain http,
Chrome opened the page and put a light-grey pill with a warning triangle and the words “Not
Secure” at the left of the address, with the http:// itself hidden. I clicked the chip:
Chrome’s panel behind the grey chip, on the http test page
Your connection to this site is not secure You should not enter any sensitive information on this site (for example, passwords or credit cards) because it could be stolen by attackers.
Chrome’s help page on checking a site’s connection, fetched 25 September, says whose job it is: “To resolve this issue, the site owner must secure the site and your data with HTTPS.”
What the chip says is that the page, and everything typed into it, travels in the open. (Mac shows “Not Secure” and, by Chrome’s own text files, Windows and Linux “Not secure”; my Chrome is in UK English, and in the quotes on this page it differs from US-English Chrome by two commas and one word.)
A question before the page opens, when the setting is on
Google’s security blog announced this on 28 October 2025:
Google’s security blog, “HTTPS by default”, 28 October 2025
One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”.
Chrome 154 did not wait for October. In March, Chrome announced a release every two weeks from September — 153 on 8 September, 154 on 22 September, where the old plan had 20 October — and the 154 release notes list, under its own heading:
Chrome 154 release notes, “Ask before HTTP on by default”
Chrome prompts users by default when they connect to a site over an insecure (http) connection. Administrators can control this default behavior using the HttpsOnlyMode enterprise policy.
In my usual Chrome profile the setting was on. I typed http://neverssl.com/, which I had not
opened before. Its own page sends each visitor on to a random address under neverssl.com, and that
is where the address bar was when I looked: before that page opened, the page area was dimmed dark
grey and a card sat at the top:
The card Chrome 154 showed before the http page opened
This site doesn’t support a secure connection
Two buttons: “Continue to site” and “Go back”. In the address bar, a crossed-out padlock and “Not Secure” — a different icon from the triangle on the already-allowed page. Nothing else was on the card. Whether a card also came at the first address, before the site moved me on, I did not record.
The card also appears on the way in, not only at the end. The same guide:
Chromium’s guide for site owners, on redirects
If in the process of navigating to an HTTPS site there were any redirect steps that do not support HTTPS, Chrome will show an Ask-before-HTTP warning. After clicking through that warning, the navigation will continue and proceed to the HTTPS site.
So Chrome can ask on the way to a site whose pages are all secure, if the bare or the www address
forwards through a plain-http step first — which is why the check types both.
How many of your visitors see it, I cannot tell you. The 22 September release post
says Chrome 154 “will roll out over the coming days/weeks”, and Chrome’s
feature tracker lists desktop at 154 and
Android at 155. The profile that asked had Safe Browsing’s “Enhanced protection” on, which Google’s
2025 announcement said would bring “Always use secure connections” with it; Chrome’s help page on warnings,
fetched 25 September, calls it “Enhanced Safe Browsing”, something “you can also turn on”; I
switched on neither setting myself. So I made a new profile in the same Chrome 154, on its defaults — Standard
protection, “Always use secure connections” off — and typed http://neverssl.com/ again. No
question. Chrome tried https first even so and landed on an https:// copy of one neverssl
address, with no chip at all (neverssl sometimes has one); another neverssl address, reached over
http, opened with the grey chip and no question — the chip of the first section, on a default
profile, on 25 September. This is Chrome; I tested no other browser.
A full-page stop: the certificate
The certificate is how a site proves to Chrome that it is the address in the bar. When Chrome will
not accept it, it stops the page, and going on takes a deliberate choice. On
https://wrong.host.badssl.com, a test page whose certificate is for a different name, the address
bar showed a red circled cross, “Not Secure” in red, and “https” struck through, and the page was:
Chrome’s full-page stop on the wrong-name test page
Your connection is not private Attackers might be trying to steal your information from wrong.host.badssl.com (for example, passwords, messages or credit cards). … NET::ERR_CERT_COMMON_NAME_INVALID
Two buttons: “Advanced” and “Back to safety”. The NET:: line is the part to read, and to pass to
whoever looks after the certificate, because it names the fault. Two codes came up on the test
pages, and Chromium’s
list of error codes
describes them: CERT_COMMON_NAME_INVALID is a certificate whose name did not match the address;
CERT_AUTHORITY_INVALID is a certificate signed by nobody Chrome trusts, the self-signed kind
included — https://self-signed.badssl.com showed it, with the same page and chip. A third, CERT_DATE_INVALID, is expired or not yet valid, or the visitor’s clock; I did not
see it on any screen. Chrome’s
page on error messages,
fetched 25 September, says of it: “You can get this error if your computer or mobile device’s date
and time are inaccurate.”
The test page expired.badssl.com — whose certificate, by another tool’s reading, ran out in
April 2015 — showed NET::ERR_CERT_AUTHORITY_INVALID in Chrome, not the expired code. Chromium’s
code for choosing the line
explains why only one code shows: “A certificate may have multiple errors. We report the most
serious error.” It maps the errors it found to one code in a fixed order, the signer before the
date. Why Chrome also distrusts whoever signed this old certificate, I have not traced.
This screen did not change on 22 September — the Chromium guide says of certificate warnings, “These warnings are not changing” — and if one visitor gets it and you do not, the fault may be at their end: the same error-messages page lists antivirus with “HTTPS scanning”, a work computer whose “proxy configuration that performs HTTPS interceptions” gives that same AUTHORITY_INVALID error, and the clock. Ask which line they see, and from where, before anyone touches the server.
Mixed content and the padlock, in Chrome 154
Six of the fifteen pages I read name a cause the screens above do not: mixed content, an image or script that loads over http inside an https page. One other blames a form that sends to http. Each cause, on its test page:
| Cause | What Chrome 154 showed | Where you would notice it |
|---|---|---|
| An http image on an https page | The two-sliders icon, no words; the image displayed | Nowhere I could see |
| An http script on an https page | The two-sliders icon, no words; the script refused | In the page: whatever the script did is missing |
| A form that sends to http | The two-sliders icon, no words, until Submit | A full page after Submit |
The script page is the clearest. Its caption read “This page triggers active mixed content (a script from an insecure URL).” and the page was grey. The script it tries to load over http would have turned the page red — I read it — so grey means Chrome refused it. The image page displayed its image and said nothing; a secure copy of that image exists, so the screen cannot tell me which one Chrome loaded. The form page showed a field, “This form submits to HTTP.”, a Submit button, and only the two-sliders icon. I pressed Submit:
Chrome’s full page after Submit on the mixed-form test page
The information that you’re about to submit is not secure
Two buttons, “Send anyway” and “Go back”. Nothing before the click.
The mixed-content claim is not made up; it is old. In October 2019 the Chromium blog wrote: “Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox.“ (The omnibox is the address bar.) That was true, for a few versions. Then Chrome 86, October 2020, began loading the https copy of an image instead, “Enabled by default”. Three pages are three pages; I am not telling you that mixed content can never put “Not Secure” in the address bar, only that on the pages built to show it, it did not. If the words are in your address bar, look at the address first.
Eight of the fifteen tell you to look for a padlock. The two-sliders icon replaced it; the change was announced in May 2023, for Chrome 117, “which releases in early September 2023”, with a reason worth having: “nearly all phishing sites use HTTPS, and therefore also display the lock icon.” The pages that still blame mixed content or send you to the padlock are dated 2023 to 2026; the advice is older than they are.
How to know it is fixed
What a visitor sees, a browser can show: on http:// and https://, bare and with www., the
page opens with the two-sliders icon — no chip, no card, no full page. A card, in a Chrome set to
ask, still means a plain-http step on the way in; a full page still means the certificate, and the
NET:: line says which part. What no browser can show is whether the server now forwards a plain
http request to https: Chrome tries https first even with “Always use secure connections” off, and
with it on changes the typed address itself. I typed http://kovalweb.com into my Chrome and it
opened with the two-sliders icon and nothing else. So I asked six addresses — kovalweb.com, kovalseo.com and cryptowl.io, bare and with www. — with a tool that
does not upgrade anything, the kind item 3 of the message asks for: every http home page answered
with a 301 and a Location: line beginning https://, and every certificate verified. Home
pages only, from one place, on one day. Once your forward is in place, the old http:// addresses
may appear in Search Console as
Page with redirect; that row is the
forward working, not a new fault.
What this page gives you is which of the three warnings Chrome is showing — a grey chip, a card before the page, or a full-page stop — and one message to send.
The part worth remembering
In grey, on my test pages, "Not Secure" meant the page came over http. In red, above a full page, it meant the certificate, and the NET:: line names the fault. Chrome 154 can also ask before an http page opens, when "Always use secure connections" is on; once someone has answered in a Chrome profile, the answer is kept for 15 days and renewed on every visit, so your own screen may not show the question. Send whichever you saw to whoever looks after the site, and ask for the forward to be checked with a tool that does not change http:// to https:// by itself. Six of the fifteen pages I read blame http images and scripts, and eight send you looking for a padlock; on my test pages, neither matched what Chrome 154 showed.
Koval SEO Console reads the public pages of your site — the same ones Google sees — and explains each finding in plain words, with the evidence beside it, then answers fixed, not fixed, or couldn't confirm when you check again.
Check my site