Chrome Now Asks Before Opening Plain HTTP Sites: What Changed and What to Do

Written on 8 November 2026. The facts below come from Google's own announcement, the Chrome 154 release notes and news coverage that we opened and read. Browser behaviour can change between builds, so the settings page of your own browser is the final word.

Since the Chrome 154 stable release on 22 September 2026, Chrome asks before it opens a public website that does not support HTTPS. The setting is called "Always Use Secure Connections". Google first offered it in 2022 as an option that few people switched on. It is now the default for everyone.

For most people nothing will look different, because the large majority of the web already uses HTTPS. The change matters in the places where it does show up: an old forum, a small shop's website, a link in an old email. This article explains what Chrome does now, why Google decided that the time had come, what the warning means, and how it connects to a second, quieter change in how long HTTPS certificates are allowed to last.

The short version

Chrome 154 reached the stable channel on 22 September 2026. Its release notes list the item "Ask before HTTP on by default".
Chrome now tries to open every address over HTTPS. If a public site cannot be reached that way, Chrome shows a warning with an option to continue, and you decide.
Chrome does not keep warning you about the same site. It warns on a new site, or one you have not visited recently.
Private addresses are excluded. That covers local IP addresses such as 192.168.0.1, single-word hostnames and internal shortlinks.
You can switch the behaviour off at chrome://settings/security. Administrators can manage it with the HttpsOnlyMode policy.
Separately, the maximum life of a publicly trusted HTTPS certificate has been 200 days since 15 March 2026. It falls to 100 days in March 2027 and to 47 days in March 2029.

What Chrome does now

Before this change, typing or following a plain http:// address simply loaded the page, usually with a small "Not secure" label in the address bar. Many sites quietly sent the visitor on to the HTTPS version, so the label often never mattered.

Under the new default, Chrome tries HTTPS first for every navigation. If the site answers over HTTPS, you arrive as usual and see nothing. If it does not, you get a full-page warning before anything loads. One how-to guide published on 6 November 2026 describes it as a screen headed "Connection is not secure" with a "Continue to site" button. If you press that button, the page opens over plain HTTP, as it always did.

Google's announcement says the warning is meant to be rare. Chrome does not repeat it for sites you visit regularly. It appears for a site that is new to you or that you have not opened for a while. The setting itself is not new. It was added in 2022, and an experiment in Chrome 141 turned it on for a small group of users first. In April 2026, Chrome 147 enabled it for people who use Enhanced Safe Browsing, a group Google puts at over one billion users. Chrome 154 extends it to everyone.

Why Google did it

Google's reasoning, published in October 2025 under the title "HTTPS by default", rests on a simple observation. HTTPS is already normal, so the exceptions are now the dangerous part.

The company's HTTPS transparency data shows that the share of page loads over HTTPS rose from roughly 30 to 45 percent in 2015 to about 95 to 99 percent around 2020, and has barely moved since. Google says the remaining plain-HTTP traffic is mostly invisible to users, because the site redirects to HTTPS straight away. That invisibility is the problem. The announcement points out that a single insecure navigation is enough for an attacker who can see or change traffic on the network, because the first request in a redirect chain travels unprotected. In Google's words, an attacker can hijack that navigation and send the visitor to malicious content. The post's conclusion is brief: "Now is the time."

The company also had evidence that the change would be tolerable. In the Chrome 141 experiment, the median user saw fewer than one warning a week, and the user at the 95th percentile saw fewer than three. Google says warnings would appear on well under 3 percent of navigations, and expects that figure to fall as more sites move over. SecurityWeek reported that Google had already contacted organisations still running insecure connections.

Why a redirect is not enough

Many site owners reasoned that plain HTTP was harmless as long as their server redirected to HTTPS. That redirect has a weak point. When you type example.com without a scheme, or follow an old http:// link, the first request leaves your device unencrypted. It asks the server where to go next, and the answer is the redirect. Someone sitting between you and the server, for instance on a shared Wi-Fi network, can answer that first request themselves and send you somewhere else. Everything after that point can look normal.

The new default shrinks this window. Chrome sends the first request over HTTPS itself, so there is no unprotected hop for a site that supports it. A site that does not support HTTPS is the one that now triggers the warning, which is the correct place for it.

What is not covered

Google drew a line between public and private sites. A public site is one such as example.com, which can get a certificate that browsers trust. Private sites cannot, because nobody can prove ownership of them in the same way. The announcement lists three kinds:

Local IP addresses, such as the 192.168.0.1 address many home routers use.
Single-label hostnames, which have no dot in them.
Shortlinks used inside a company, such as intranet/.

This is why developers and IT teams were not the main target. Your router's admin page, a test server on your own network and an internal company tool should open as before. The announcement adds one related detail. Once a user grants the new local network access permission, an HTTPS page can talk to devices on the local network without mixed-content blocking, which gives those sites a way to move to HTTPS.

Address you open	What Chrome 154 does by default
A public site that supports HTTPS	Opens normally over HTTPS. No warning.
A public site with only HTTP	Shows a warning first. You can continue.
The same HTTP-only site, visited often	Does not repeat the warning.
A local address such as 192.168.0.1	Excluded from the default.
A single-word internal hostname	Excluded from the default.
A site with an expired or invalid certificate	Not this feature. It already gets Chrome's separate certificate error page.

What to do when you see the warning

The warning is not a verdict that the site is malicious. It says the connection to it cannot be protected. What you do next depends on what you were about to do there.

Read the address. If you followed a link, check that the domain is the one you expected. A warning on an address you did not intend to visit is worth taking seriously.
Try the secure version yourself. Type https:// in front of the domain. If the site supports it, it opens. Sites with a setup problem sometimes only work with or without www.
Decide by what you will do on the page. Reading a public article over HTTP exposes less than logging in. Do not enter a password, card number or personal details on a page that is not protected. Anyone on the same network can read or change what you send.
Tell the owner if you can. A shop or club whose site triggers the warning has probably never noticed. A short message often gets it fixed.
Leave if unsure. If the page is not important, closing it costs nothing.

To switch the feature off, open chrome://settings/security and turn off "Always use secure connections". On Android, one guide gives the route as the three-dot menu, then Settings, then Privacy and security, then Security. We would leave it on. The warning is rare, and the cases where it appears are the ones where the protection matters.

The second change: shorter certificates

HTTPS depends on certificates, which are small files issued by certificate authorities that prove a site controls its domain. A second change, agreed in 2025, makes those certificates expire much sooner. It matters because it makes HTTPS something sites must automate, and a site that fails to renew simply stops working over HTTPS.

In April 2025 the CA/Browser Forum, the body where certificate authorities and browser makers agree shared rules, approved ballot SC-081v3. It sets a schedule that starts in March 2026 and ends in March 2029. Under it, the maximum validity of a publicly trusted certificate drops from 398 days to 47 days. The steps, as set out by a certificate vendor's summary of the ballot, are:

From	Maximum certificate life	How long proof of domain control can be reused
15 March 2026	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

Certificates issued before 15 March 2026 keep their original validity. The limits apply to certificates issued on or after each date, and only to publicly trusted authorities that follow the Forum's rules. Private certificate authorities that sit outside the public trust stores are not covered. Let's Encrypt, which already issues 90-day certificates, sits under the 200-day cap and is not directly affected. The people who feel the change are those who bought a one-year or multi-year certificate and renewed it by hand once a year.

The two changes point the same way. Chrome now treats a site without HTTPS as the exception that needs your approval, and certificate rules push site owners toward renewing certificates automatically. A small website with a manually installed certificate has more to lose than before.

If you run a website

Serve everything over HTTPS and redirect http:// to https:// on the same host.
Fix mixed content. Images, scripts or styles still loaded from http:// addresses cause trouble even on an HTTPS page.
Automate renewal. With certificates lasting 200 days now and 47 days in 2029, a calendar reminder is not a plan. Use your host's built-in renewal or an ACME client, and have something alert you if it fails.
Check old links. Search your own pages, newsletters and profiles for http:// links to your site.
Test from outside. Open the site on a phone using mobile data, not only on your office network.

Habits for everyone else

Look at the address, not only the page. A padlock tells you the connection is encrypted. It does not tell you the site is honest, as the search hijack article and the Binance hack write-up both show.
Be more careful on public Wi-Fi. The warning helps, but a proxy or VPN changes who can see your traffic, and each has limits. The proxy and VPN comparison covers them.
Remember that HTTPS hides the content of a page, not the fact that you visited the site. The fingerprinting guide explains what else sites learn about you.

Where Rapid+ fits

We build Rapid+ Browser, so here is what we can state about our own app. On Android, when you type a bare domain such as example.com, Rapid+ opens the https:// version. When a site's certificate is invalid, Rapid+ shows a full-page warning and never continues silently. If you choose "Proceed anyway", the choice applies to that site in that tab for the current session only and is not saved. The site information panel says "Connection is not secure" for pages that are not protected.

What Rapid+ does not do today is show a warning before it opens a plain http:// link. If you follow an old HTTP link, the page loads and the site information panel is where you see the status. Until that changes, check it before you type anything private. Rapid+ is built on the system's web engine, and this article describes Chrome, so do not assume the two behave the same.

Frequently asked questions

When did Chrome start asking before opening HTTP sites?

Chrome 154 reached the stable channel on 22 September 2026. Its release notes list "Ask before HTTP on by default". Updates reach users gradually, so some people received it later than others. An earlier step in Chrome 147, in April 2026, covered users of Enhanced Safe Browsing.

Does the warning mean the website is dangerous?

No. It means the connection to the site cannot be protected, so anyone able to watch or change your traffic could read or alter what is sent. A harmless old site can trigger it. What matters is what you do on the page, and logging in or paying on an unprotected page is the real risk.

Will I see this warning all the time?

Unlikely. Google's experiment found that the median user saw fewer than one warning a week. Chrome also avoids repeating the warning for sites you visit regularly.

Does this apply to my home router or a company intranet?

No. Local IP addresses, single-word hostnames and internal shortlinks are excluded, because they cannot get certificates that browsers trust. Public websites are the target of the default.

Can I turn it off?

Yes. Open chrome://settings/security and switch off "Always use secure connections". Managed devices can be configured by an administrator with the HttpsOnlyMode policy.

Does this affect Edge, Brave or other browsers?

The announcement and the release notes we read describe Chrome. Other browsers set their own defaults, so check the security settings of the browser you use rather than assuming it behaves the same.

Sources

Written by the Rapid+ Team. We build Rapid+ Browser for Android and Windows. Spotted a mistake or have a question? Email us at admin@rapidplusbrowser.online.