Chrome 154 Asks Before Loading HTTP: What Changes for Dev, Staging, and Test Automation

If you have ever shared a staging link that starts with http://, Chrome now has an opinion about it. Chrome 154 turned on “Always Use Secure Connections” by default. Chrome tries HTTPS first and asks for the user’s permission before the first visit to a public site that cannot be reached over HTTPS.

For the average visitor to a modern website, nothing changes. For developers, the story is different. The pain does not land on localhost, which is exempt. It lands on the quieter corners of a real workflow: staging servers with public hostnames, preview environments nobody put a certificate on, old redirect chains, and CI jobs where no human is around to click “Continue.”

This guide covers what shipped, how the warning behaves, where it breaks developer and QA workflows, the exact flag for test automation, and how to fix the underlying problem instead of papering over it.

TL;DR

• Chrome 154 reached the stable channel on September 22, 2026, with the public-sites variant of “Always Use Secure Connections” on by default. Google’s own launch post followed on October 21, 2026.
• Chrome attempts HTTPS first. If that fails but HTTP might work, it asks before loading the page over HTTP.
• localhost, local IP addresses, single-label hostnames and non-unique names like staging.local do not trigger the warning.
• A public hostname served over plain HTTP can trigger it. For a human, clicking through still works, so it is friction rather than a wall. For unattended automation, it can be a wall.
• For test automation, Chromium’s documented escape hatch is --unsafely-treat-insecure-origin-as-secure.
• The durable fix is HTTPS on every public hostname, including every hop of every redirect.

What Chrome 154 actually changed

The “Always Use Secure Connections” setting is not new. Chrome introduced it in 2022 as an opt-in feature. Google later added a variant limited to public sites, because HTTP to private sites carries less risk. What changed in Chrome 154 is the default.

Here is the rollout, as Google described it:

When	What happened
2022	“Always Use Secure Connections” launches as an opt-in setting
2024	A public-sites-only variant is introduced
Chrome 141	Google experiments with enabling the public-sites variant for a small percentage of users
October 28, 2025	Chrome Security Team announces the plan to make it the default
Chrome 147 (April 2026)	Enabled by default for users enrolled in Enhanced Safe Browsing, a group Google’s announcement put at over one billion people
Chrome 154 (September 22, 2026)	Enabled by default for everyone, per the Chrome 154 release notes
October 21, 2026	Google publishes “Chrome Now Warns Before Insecure HTTP Connections,” confirming the rollout to all users

One detail is worth correcting if you read early coverage. The original announcement said the change would arrive in October 2026. Chrome 154 actually reached stable on September 22, 2026, because Chrome moved to a two-week release cycle starting with Chrome 153 on September 8. The Chrome 154 release notes list “Ask before HTTP on by default” and say administrators can control it with the HttpsOnlyMode enterprise policy. As with any stable release, rollout to every machine happens gradually, so you may still meet a few older builds in the wild.

Why did Google do this? According to the Chrome Security Team, the share of Chrome page loads using HTTPS climbed from roughly 30 to 45 percent in 2015 to the 95 to 99 percent range around 2020, and has largely plateaued since. The remaining slice matters for two reasons:

• An attacker needs only one insecure navigation to get a foothold, for example by hijacking the navigation and loading attacker-controlled resources.
• Many plaintext HTTP connections are invisible to users, because the HTTP site immediately redirects to HTTPS. The old “Not Secure” badge never gets a chance to appear.

In the Chrome 141 experiment, warnings reached well under 3 percent of navigations. The median user saw fewer than one warning per week, and the 95th-percentile user saw fewer than three. Google’s October 2026 post adds early rollout data: nearly 95 percent of desktop Chrome users see no HTTP warning in a given week, and fewer than 1 percent see three or more. Warning rates on mobile are lower still. Google also notes that Chrome is the first browser to make this change by default.

How the warning behaves

Understanding the mechanics saves you from chasing ghosts. This is what Chromium’s own adoption guide says.

Trigger. The warning appears when Chrome could not connect over HTTPS but believes it may be able to connect over HTTP. Chrome then prompts before loading the page.

Memory. Chrome remembers a user’s decision for 15 days, and the exception is renewed whenever the user revisits the site. If you use an HTTP site regularly, you may see the warning only once. Google’s launch post describes this as no new warning until the site has gone unvisited for at least two weeks.

Explicit HTTPS never falls back. If a link or the address bar specifies https:// and the connection fails, you get a normal network error page and Chrome does not try HTTP.

HSTS wins. If a site has HTTP Strict Transport Security configured, Chrome does not fall back to HTTP. HSTS takes precedence over automatic upgrades and the new warning.

Redirects count. If any step in a redirect chain does not support HTTPS, Chrome shows the warning, even if the final destination is a good HTTPS page. The guide’s example: https://www.example.com is fine, but http://example.com redirects to http://www.example.com and the apex has no HTTPS. Visitors typing example.com hit the warning. Several insecure hops can mean several warnings in a single navigation.

Certificate errors are unchanged. An expired certificate or a misconfigured server still produces the existing certificate warnings, and no additional warning type is added.

Existing choices are respected. If you previously set the setting either way, Chrome keeps honoring it.

What is exempt, and why developers care

Chrome splits the world into public and private sites, and the warning applies to public sites only. Private sites are excluded for two reasons:

• Examples are local IP addresses like 192.168.0.1, single-label hostnames like intranet/, and internal shortlinks.
• There is no practical way for a certificate authority to validate and issue a publicly trusted certificate for a non-unique name, and attackers generally need to be on the same network to exploit them.

For local development, the adoption guide spells it out:

• http://localhost is considered secure and shows no warning.
• Local names such as staging.local, non-unique hostnames, local IP addresses and single-label hostnames also show no warning.
• A development server on a public hostname without HTTPS may show the warning. Clicking through lets development continue as it does today.

That last bullet is the one that matters. Your laptop is fine. Your shared staging box at http://staging.yourcompany.com is not.

Enterprises can go the other direction. The HttpsOnlyMode policy can be set to force_balanced_enabled to lock in the new default, or force_enabled to opt users into strict mode, where warnings also appear for private sites.

Where it actually hurts: staging, previews and shared environments

Most developers will not notice this on a laptop. They will notice it when someone else opens a link. Typical trouble spots:

Staging servers on public hostnames. A QA engineer or client opens http://staging.example.com and gets an interstitial instead of your app. It is bypassable, but it looks alarming.

Preview and demo environments. Ad hoc preview boxes and “temporary” deployments are the sites that skip certificates, and they get shared with people outside your team.

Redirect chains. Short links, apex-to-www redirects and old tracking redirects often hide an HTTP hop. Users never see it, but Chrome does.

Old links in docs and tickets. http:// links to tools on public DNS names will start prompting people.

Anything unattended. A human can click through. A scheduled browser job cannot.

If you are unsure whether something on your side will trigger the warning, Chrome’s guidance is simple: turn the setting on and use your normal workflows. In chrome://settings/security, enable “Always Use Secure Connections” and pick the option that warns on insecure public sites. Then browse your own staging, preview and internal tools and note every warning. Use the Network panel in DevTools to inspect each redirect hop for the ones that are not obvious.

Test automation: the flag you need

Automated browser tests are the sharpest edge of this change. A human clicks “Continue to site” once and moves on. A Selenium, Playwright or Puppeteer run typically starts with a fresh browser profile and has nobody to click, so an interstitial can stand in the way of your application.

Chromium’s documented answer is the --unsafely-treat-insecure-origin-as-secure command-line flag. It takes a comma-separated list of origins (for example http://example.com) or hostname wildcards (for example *.example.com). The guide’s own example allowlists a specific host plus a wildcard:

--unsafely-treat-insecure-origin-as-secure=http://insecure.example,*.example.com

Here is how that looks in practice.

Playwright (TypeScript), in playwright.config.ts:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: {
        launchOptions: {
          args: [
            '--unsafely-treat-insecure-origin-as-secure=http://staging.example.com,*.preview.example.com',
          ],
        },
      },
    },
  ],
});

Selenium (Python):

from selenium import webdriver

opts = webdriver.ChromeOptions()
opts.add_argument(
    "--unsafely-treat-insecure-origin-as-secure="
    "http://staging.example.com,*.preview.example.com"
)
driver = webdriver.Chrome(options=opts)

The same pattern works in Puppeteer or any other tool that lets you pass launch arguments to Chrome.

A few practical notes:

1. Keep the list narrow. The flag name says “unsafely” for a reason. Allowlist only the hosts your tests need, never a blanket pattern. Pair it with a dedicated browser profile where you can.
2. Know the side effect. The flag makes an HTTP origin behave like a secure context, so secure-context-only APIs may start working there. It does not add transport encryption. A green test on an allowlisted HTTP origin does not prove the production HTTPS path works.
3. Mind the old opt-out. Before launch, the guide mentioned --disable-features=HttpsFirstBalancedModeAutoEnable as a way to turn the default feature off. The guide framed it as a pre-launch option, so re-check current Chromium documentation before relying on it.
4. Pin your browser. Chrome now ships a stable major version every two weeks, so an auto-updating CI image picks up changes like this silently. Pin a version (for example with Chrome for Testing) and bump it on purpose. Enterprises can also use the Extended Stable channel, which stays on an eight-week cycle and therefore picks up new defaults on a different schedule.
5. Managed fleets. The HttpAllowlist enterprise policy takes hostnames or patterns such as [*.]example.com that will not be upgraded or warned about.

The flag does nothing for real users. If staging is genuinely public, outside reviewers still see the prompt.

Fix the cause: HTTPS on every public hostname

Allowlisting is a bandage for test runners. The real fix is to stop serving public hostnames over HTTP.

Automate certificates. Chromium’s guide points to ACME-based automation. Apache has mod_md, Nginx has native ACME support, and Caddy handles certificates automatically. Many certificate authorities now offer free certificates, and Let’s Encrypt is the best-known example, so cost is no longer a reason to skip staging. If you do not run your own server, ask your hosting provider to enable HTTPS, since modern hosts generally support it. For server configuration, Chromium also recommends the Mozilla SSL Configuration Generator.

Fix every redirect hop. Audit apex domains, www variants, vanity domains, link shorteners and tracking redirects. Every step in the chain must answer on HTTPS. If a domain-forwarding service sits in the middle, ask the provider whether it supports HTTPS. If your domain is a CNAME to the provider, the provider can usually obtain certificates on your behalf.

Use localhost for local work. It is already treated as secure. When you need real HTTPS locally, Chromium points to the web.dev guides “When to use HTTPS for local development” and “Use HTTPS for local development.”

Be careful with HSTS on non-production hosts. HSTS is the strongest signal because Chrome will not fall back to HTTP at all. That suits production, but once a browser has seen the header, a later certificate problem on that host becomes a hard stop instead of a click-through. Avoid broad subdomain rules until every subdomain is ready.

Where a tunnel fits in

There is a situation the steps above do not neatly solve. You have a dev server running on your machine, and a teammate, client or webhook sender needs to reach it from outside. Self-hosting HTTPS for a throwaway environment is more ceremony than the task deserves.

This is where an HTTPS tunnel earns its keep. InstaTunnel serves tunnels over HTTPS by default, so the URL you share is an https:// address from the first click. A reviewer opening it does not meet an HTTP warning, and you do not have to provision a certificate for a hostname you will delete tomorrow. A stable custom subdomain also means the link you drop in a ticket keeps working, instead of re-sharing a new URL every session.

Two honest caveats apply to any tunnel, not just ours:

• Your app is still speaking HTTP locally. The tunnel terminates HTTPS at the edge and forwards to your dev server. If your framework builds absolute URLs or forces redirects based on the request scheme, make sure it trusts the forwarded protocol header correctly, or you may see redirect loops or mixed-content problems. Many dev servers also reject unfamiliar Host headers by default, so the tunnel hostname may need to be added to an allowed-hosts setting.
• A tunnel is not a substitute for a real staging setup. If a shared environment is going to live for months, give it a real hostname and an automated certificate. Use the tunnel for the short-lived, share-this-right-now cases it is good at.

One scoping note: this is a different mechanism from Chrome’s Local Network Access prompts, which concern a public page reaching into your local network. Chrome 154 also extends that area. It adds a targetAddressSpace option to the WebSocket constructor, which lets a connection to a public hostname be treated as going to a local or loopback destination. The Chrome 154 release notes describe it as a way around mixed-content restrictions when talking to local servers without HTTPS, provided the user grants local network permission. Ask-before-HTTP, by contrast, is about navigating to a public page that lacks HTTPS.

Frequently asked questions

Does Chrome 154 block HTTP sites?
No. It asks for permission before the first visit to a public HTTP site, and the warning is bypassable. Chrome also remembers the choice for 15 days and renews it on each visit.

Does http://localhost show the warning?
No. Chrome treats it as secure. Local IP addresses, single-label hostnames and non-unique names like staging.local are also exempt.

Can I turn it off for myself?
Yes. Disable “Always Use Secure Connections” in chrome://settings/security. If you set it either way before Chrome 154, Chrome keeps your choice.

How do I stop the warning in Selenium or Playwright?
Pass --unsafely-treat-insecure-origin-as-secure with the specific origins or wildcard hosts your tests use.

What about Firefox, Safari and Edge?
Per Chromium’s guide, all three already upgrade HTTP navigations to HTTPS and offer optional modes that warn before falling back to HTTP. The difference is that Chrome now enables the warning by default.

The bottom line

Chrome 154 did not break the web, and for most sites nothing visibly changed. But it did draw a clear line: public means HTTPS. Developers keep a free pass on localhost and private names, while staging servers, preview environments and test automation on public hostnames now need either a proper certificate or a deliberate, narrow exception. Spend an afternoon turning the setting on, walking your environments, and fixing the hosts that prompt. It is cheaper than explaining the warning to every client who opens a demo link.

Sources

• HTTPS by default, Chrome Security Team (Oct 28, 2025)
• Chrome Now Warns Before Insecure HTTP Connections, Chrome Secure Web and Networking Team (Oct 21, 2026)
• Adapting your website for Chrome’s “Ask-before-HTTP” warning, Chromium docs
• Chrome 154 release notes, Chrome for Developers
• Get features faster with Chrome’s two-week release cycle, Chrome for Developers Blog (Mar 3, 2026)
• Fresher features, faster fixes: The two-week release cycle is here, Chrome for Developers Blog (Sep 8, 2026)
• Google Chrome starts two-week release cycle with version 153, 9to5Google
• Chrome to Turn HTTPS on by Default for Public Sites, SecurityWeek
• Chrome Will Default to HTTPS for All Public Sites Starting October 2026, CyberInsider