Chrome 154 or 155: When HTTPS-First Warnings Become Default and How to Manage Them

There's one wrinkle. Google's own documents don't all agree on which version flips the switch. Chrome 154 is definitely out, but the default may arrive in 154 or slip to 155. For Windows users and IT admins, that difference matters.

What the HTTP warning actually does​

With the setting on, Chrome tries to load every page over HTTPS first. If a public site can't provide a secure connection, Chrome shows a warning before the first visit. The warning says the site doesn't support a secure connection and that attackers could see or change information. You get two buttons:

• Continue to site loads the page over HTTP as before.
• Return takes you back.

This is a speed bump, not a wall. Google's Chrome Security team said in its October 2025 "HTTPS by default" post that users can still turn the warnings off by disabling the setting. Chromium's adoption guide for site owners says the same thing: anyone who finds the warnings too cumbersome, you can disable the "Always Use Secure Connections" setting in chrome://settings/security.

Google also tries not to nag. It says that if you visit an insecure site regularly, Chrome won't keep warning you about it. Warnings are for sites that are new to you or that you haven't visited in a while. Your daily HTTP-only intranet tool won't greet you with a prompt every morning. The recipe blog you bookmarked in 2014 probably will.

Summary: One-click bypass, warns once per new site, and you can turn it off. What changes is that Chrome now asks first.

Why Google is doing this​

Google's argument is about the moment of navigation. HTTP has no authentication and no encryption. Anyone who can tamper with your traffic, such as a hostile hotspot or a compromised router upstream, can hijack an HTTP navigation and send you to content they control. Google says these attacks have already been used to compromise devices in targeted attacks.

Google also points to a less obvious problem. Many sites send you to HTTPS right after an initial HTTP request. You end up on a secure page with a padlock, so you never see that the first hop was exposed. Chrome's "Not Secure" label in the address bar can't help, because by the time it would appear, the risky moment has passed. A warning before the navigation is meant to cover that gap.

Google also published adoption numbers. HTTPS climbed from about 30–45% of Chrome page loads in 2015 to roughly 95–99% by around 2020, then levelled off. The remaining few percent is still a huge number of navigations, and an attacker only needs one.

Who will actually see it​

Probably not many people, if Google's experiment data holds. In Chrome 141, Google turned on the public-sites version of the setting for a small share of users. Warnings made up far less than 3% of navigations. The median user saw fewer than one warning a week, and the 95th-percentile user saw fewer than three.

Platform matters a little. Here is Google's HTTPS share for public sites only:

Most of the gap comes from private-network traffic, which is why the default leaves it out.

These are Google's own experiment figures, not an independent measurement of the Chrome 154 rollout. Google also says it contacted the companies responsible for the most HTTP traffic and expects many of them to move to HTTPS. If that happens, the numbers above could drop further.

What the default leaves alone​

The default is the public-sites version of the setting. Private destinations are excluded:

• Local IP addresses such as 192.168.0.1 (your router's admin page, the NAS in the closet)
• Single-label hostnames
• Short intranet names like intranet/

Google's reason is about certificates. A private name can point to different machines on different networks, so no certificate authority can confirm who owns 192.168.0.1. Getting a trusted certificate for a public site is free and easy. Getting one for a private name is still awkward. Google admits that HTTP on a private network still carries risk, but an attacker generally has to be on the same local network to exploit it.

A stricter mode that also warns on private sites already exists. Google's Android security post explains that users can choose if they would like to warn on any insecure site, or only insecure public sites. The new default is the gentler of the two.

The version-number wrinkle​

Google's Chrome Security blog post from October 2025 set out the plan:

• Chrome 147 (April 2026): public-sites mode enabled for the more than 1 billion users who opted into Enhanced Safe Browsing.
• Chrome 154 (October 2026): public-sites mode enabled by default for everyone.

DigitBin's write-up follows that timeline. It says the setting reached Enhanced Safe Browsing users in Chrome 147 and that Chrome 154 extends it to everyone.

Google's Chrome Enterprise documentation tells a different story. An earlier version of the enterprise release notes did follow the original plan, saying Chrome 154 will enable the Always use secure connections setting in the public sites only mode by default. The current Chrome Enterprise release notes, updated within the past month, say otherwise. They state that Chrome 150 enabled Always use secure connections for users who opted in to Enhanced Safe Browsing protections in Chrome. They also say Chrome 155 enables the Always use secure connections setting in public sites only mode by default. The platform list confirms both points: Chrome 150 on ChromeOS, Linux, MacOS, Windows, Fuchsia: Enable "Always use secure connections" for users who have opted in to Enhanced Safe Browsing. This applies to Desktop only. The all-users step reads Chrome 155 on Android, ChromeOS, Linux, MacOS, Windows, Fuchsia: Enable "Always use secure connections" by default for all users.

So the newest admin documentation suggests the schedule moved back: Enhanced Safe Browsing users got the setting in Chrome 150 rather than 147, and the all-users default comes in 155 rather than 154. DigitBin also says Chrome switched to a two-week release cycle starting with Chrome 153. If that's correct, Chrome 155 would follow 154 within weeks, so the delay is small. Still, it's a delay, and "Chrome 154 turns it on for everyone" may not be accurate.

There's also the rollout itself. Google's Chrome Releases blog says the 154 Stable build is rolling out over the coming days and weeks. Even if your browser says 154, you may not see the new default yet. Chrome changes like this often arrive in stages through server-side flags, so two PCs on the same version can behave differently for a while. That last point is general industry knowledge, not something Google stated for this feature.

How to check your own browser​

The setting lives on Chrome's security page:

1. Open Chrome and type chrome://settings/security in the address bar.
2. Scroll down to the advanced options and find Always use secure connections.
3. If it's on, check which mode is selected: public sites only, or all insecure sites.
4. Test it by visiting a public site you know is HTTP-only. You should see the warning with Continue to site and Return.

Should you turn it off? On a desktop that never leaves your home network, the risk is modest. On a laptop that joins hotel, airport and café Wi-Fi, turning it off is a bad trade. Those are exactly the networks where HTTP traffic is easiest to tamper with, and the warning costs you about one click a week.

For site owners: find your HTTP pages now​

Google strongly recommends that developers and IT staff turn the setting on before the default arrives, so they can spot pages that will trigger the warning. Chromium's adoption guide puts it this way: We recommend you proactively enable "Always Use Secure Connections" for public sites at chrome://settings/security. This can help identify any unexpected usages of HTTP that cause warnings.

Common causes include:

• HTTP-to-HTTPS redirects. Old links, email campaigns and QR codes that point to http:// addresses will now show a warning before the redirect.
• Device setup portals. Some manufacturers host setup pages over HTTP so the page can talk to a device on your local network without being blocked as mixed content. Google says Chrome's new local network access permission lets an HTTPS page reach the local network once the user grants permission, which removes the need to stay on HTTP.
• Expired or abandoned certificates on small business and hobby sites.

Here's a quick test: open your own homepage in Chrome with the setting on. If you see the warning, so will your visitors.

For IT admins: two Group Policy settings to know​

Managed Windows fleets don't have to wait for Google's schedule. Chrome has two enterprise policies for this, and the enterprise notes confirm that Admins can use the HttpAllowlist and HttpsOnlyMode policies to override this behavior.

HttpsOnlyMode controls the setting itself:

Google's policy page says "force_enabled" is supported from M112 onwards, "force_balanced_enabled" is supported from M129 onwards. "force_enabled" and "force_balanced_enabled" can be recommended to users too. Chromium's guide gives an example: set the policy to "force_balanced_enabled" to enforce that your users have the (upcoming) default setting and can't turn it off.

HttpAllowlist handles exceptions. It takes a list of hostnames or hostname patterns (such as "[*.]example.com") that will not be upgraded to HTTPS and will not show a warning when navigating to them over HTTP. One limit applies: Allowlisting only works on platforms capable of full site isolation—any desktop platform and Android devices with 2GB+ RAM. Windows desktops are covered. Low-memory Android devices in a mixed fleet are not.

A sensible rollout:

1. Audit which internal and partner web apps still use HTTP. Pay special attention to anything on a public domain, since private intranet names are already excluded.
2. Add the ones you can't fix yet to HttpAllowlist, and set a deadline to remove them.
3. Decide whether to enforce balanced mode so users can't turn it off, or strict mode if your threat model includes attackers on the local network.
4. Tell your helpdesk to expect the warning, because "Chrome says my site isn't secure" tickets will come in.

The bottom line​

The change is both overdue and modest. HTTPS has been nearly universal for years, and a one-click warning on public HTTP pages is a small cost against a real attack technique. The open question is timing. The Chrome 154 build is out, but Google's newest enterprise notes say the everyone-gets-it default arrives in Chrome 155. Check chrome://settings/security yourself, and if you manage Chrome across a fleet, configure the policies now rather than waiting for helpdesk tickets.

Chrome 154 is worth installing either way. Google's release notes list 11 security fixes, including a critical out-of-bounds write in WebGL, CVE-2026-103628. Those fixes are a separate matter from the HTTP warning.