The Chrome HTTP warning is now on for everyone. In an October 21, 2026 post, Google said Chrome now asks users for permission before it loads a site over plain HTTP, and that this is the default for all users. Before that, it reached Enhanced Safe Browsing users, a small test group, and people who turned on a setting called "Always Use Secure Connections."
For agencies and the nonprofits they serve, this lands on the forgotten corners of a web estate. Old campaign microsites, vanity domains, event subdomains and redirect chains that start on http:// can now stop a visitor with a full-page prompt. This post covers what changed, what is exempt, the policies IT can set, and how to find and fix HTTP leftovers.
The short version: if any site, subdomain or redirect hop you manage cannot answer over HTTPS, Chrome visitors now get a Chrome HTTP warning asking whether to continue. Local IP addresses and single-label intranet names are exempt by default. Put HTTPS on every hostname, redirect at the first hop, and add HSTS once it all works.
What Google changed in Chrome
Google’s October 21 announcement comes from Chrome’s Secure Web and Networking team. It says, "Earlier this year we enabled this feature for users enrolled in Chrome’s Enhanced Protection mode of Safe Browsing," and "now we extended this protection to all users by default."
The plan was set a year earlier. Google’s October 2025 HTTPS-by-default post laid out the steps.
| When | Chrome version | Who gets the warning |
|---|---|---|
| 2022 | Opt-in setting | Only users who turn it on |
| 2025 | Chrome 141 | A small experiment group |
| April 2026 | Chrome 147 | Enhanced Safe Browsing users |
| Fall 2026 | Chrome 154 | All users, by default |
The middle step slipped. Google’s Chrome Enterprise release notes say Enhanced Safe Browsing users got the setting in Chrome 150, on desktop, which reached stable on June 30, 2026.
The October 2025 post placed Chrome 154 in October 2026. Chrome then moved to a two-week release cycle starting with Chrome 153 in September, and the Chromium Dash schedule lists Chrome 154 stable on September 22, 2026. Google’s October 21 post says the change has "now rolled out" but gives no pace, so assume your visitors have it.
The announcement’s early data says "nearly 95% of Chrome users on Desktop don’t see any HTTP warnings in a given week, with less than 1% seeing 3 or more." "Warning rates on mobile are even lower," it adds. Those are web-wide numbers. They do not tell you whether your old microsite is in the 5%.
When the Chrome HTTP warning appears, and when it does not
The Chrome HTTP warning shows up when Chrome cannot connect to a site over HTTPS but thinks plain HTTP may work. Chrome tries HTTPS first. If that fails, it stops and asks before falling back.
Google’s guide for site owners, Adapting your website for Chrome’s "Ask-before-HTTP" warning, fills in the rules:
- It asks once per site, then remembers. The guide says, “Chrome remembers a user’s decision for 15 days, and the exception is renewed whenever a user revisits that site.” The announcement puts it as “at least two weeks” without a visit.
- Explicit HTTPS links do not fall back. If a link or typed address says https:// and the connection fails, the user sees a regular network error page. Chrome does not try HTTP.
- HSTS wins. The guide says HSTS “takes precedence over Chrome’s automatic HTTPS upgrades and Ask-before-HTTP warnings.”
- Certificate errors are unchanged. No new certificate warnings come with this.
What is exempt by default
The default is the "public sites" version of the setting. Per the announcement, "warnings are not shown on single-label hostnames like intranet/, or local IP addresses like 192.168.0.1." The guide adds non-unique hostnames to that list.
So a printer at 10.0.0.25 or a router at 192.168.1.1 should not trigger a prompt. An appliance reached by a full public-style name, such as printer.example.org, is not on the exempt list. Test those.
The guide says admins can push a "strict" mode that also warns on private sites. Google’s 2025 post says users can still turn the setting off.
Redirect chains will trip the Chrome HTTP warning most often
On an established site, the likely trouble spot is a single redirect hop. The guide says "you should ensure that all inbound links and redirect chains fully support HTTPS at every step along the way."
Take the guide’s own example. A visitor follows http://example.com. It redirects to http://www.example.com, which redirects to HTTPS. If the apex domain has no HTTPS, Chrome warns at the first hop, even though the visitor would have landed on a secure page. Several insecure hops can produce several warnings.
The guide names domain-forwarding services too, and says you may need to ask your provider whether it supports HTTPS. Vanity domains bought for a campaign often forward this way. If the service answers only on HTTP, every printed URL and QR code on that domain now shows a prompt.
The fix is to make each hop answer on HTTPS. Redirect from http:// to https:// on the same hostname first, then move to the final address.
Where HTTP still hides on nonprofit and association sites
From the patterns above, these are the places to check first:
- Old microsites and campaign landing pages on hosts no one renews or watches.
- Subdomains for events, giving, stores, careers or chapters, often run by a vendor.
- Vanity and short domains used on print pieces, signage, QR codes and radio spots.
- Apex domains that only redirect and never got a certificate.
- Email and tracking links that start on http:// in old templates.
- Appliance admin pages reached by a full hostname instead of an IP address.
Embedded content is a separate, older story. On an HTTPS page, Chrome already blocks mixed content such as HTTP iframes and scripts. A 2019 Chromium blog post says, "Browsers block many types of mixed content by default, like scripts and iframes." Forms that post to HTTP from an HTTPS page have drawn full-page warnings since Chrome 87, according to the Chromium blog. The Chrome HTTP warning is about navigations: the page a visitor opens and every redirect on the way.
If your whole site runs on HTTP, the Chrome HTTP warning is the least of it. Our plain-English guide to HTTPS and SSL/TLS covers the basics.
How to find HTTP leftovers before your visitors do
Google’s 2025 post "very strongly" recommends turning the setting on now to find sites that need work. Here is a practical order:
- Turn on the setting on a test browser. Go to chrome://settings/security and enable “Always Use Secure Connections.” Then browse your sites, campaigns and print URLs.
- List every hostname. Export your DNS zones, including subdomains a vendor set up. Our DNS explainer covers the record types.
- Request each one on http:// and https://. Note which ones fail on HTTPS or redirect through HTTP.
- Crawl from HTTP starting points. Run your crawler with http:// seed URLs and flag any hop that stays on HTTP.
- Check the Search Console HTTPS report. The HTTPS report shows indexed HTTP URLs and why their HTTPS versions were not indexed. It works for Domain and HTTPS URL-prefix properties.
- Trace redirects in DevTools. The guide suggests the Network panel to see each redirect hop.
Google’s help page says the report "isn’t a comprehensive list of all detected items," so treat it as one input. Our traffic-drop walkthrough shows where to find it.
Fixing it: HTTPS everywhere, clean redirects, then HSTS
The guide suggests ACME-enabled servers such as Apache, Nginx or Caddy, a free certificate authority, or your hosting provider. Ask your host how it handles certificates for extra domains. Vendor-run subdomains need the vendor to do it.
Then set up redirects. Send http:// to https:// on the same hostname, then to the final URL. Give the apex domain its own certificate, even if it only redirects.
Once every host works on HTTPS, add HSTS. The header tells browsers to use HTTPS only:
Strict-Transport-Security: max-age=31536000; includeSubDomainsPer MDN’s HSTS reference, browsers ignore the header if it arrives over HTTP. Preloading requires a max-age of at least one year plus includeSubDomains. The guide also mentions HTTPS resource records in DNS as a way to signal an upgrade.
Certificates also need steady renewal. Our post on shrinking SSL certificate lifespans explains why manual renewals will not keep up.
Chrome HTTP warning settings for managed browsers
Organizations that manage Chrome can set the behavior by policy. The guide names two, and Chrome Enterprise’s policy pages for HttpsOnlyMode and HttpAllowlist list the values.
| Policy | Setting | Effect |
|---|---|---|
HttpAllowlist |
Hostnames or patterns, such as [*.]example.com |
Listed sites are not upgraded and show no warning over HTTP |
HttpsOnlyMode |
force_balanced_enabled |
Enforces the new default; the guide says users cannot turn it off |
HttpsOnlyMode |
force_enabled |
Strict mode, which also warns on private sites |
HttpsOnlyMode |
disallowed |
Turns the setting off |
Use the allowlist for internal tools that cannot move yet, such as an old badge printer. Keep the list short and review it each quarter.
How other browsers handle HTTP
Mozilla says HTTPS-First is "enabled by default in Firefox version 136 and above," in its HTTPS-First support page. Firefox tries HTTPS, then loads HTTP if it has to. WebKit’s Safari 15 post says Safari "supports automatic HTTPS upgrades." Microsoft’s HttpsUpgradesEnabled policy page says Edge has tried to upgrade HTTP navigations since version 120. Google’s guide says all three also have optional modes that warn before falling back to HTTP.
For the wider picture of which browsers to test, see our browser engines guide and our Q4 2026 platform calendar.
Frequently Asked Questions
What is the Chrome HTTP warning?
It is a full-page prompt Chrome shows before it loads a site over plain HTTP. Chrome tries HTTPS first. If HTTPS fails, it asks the user whether to continue.
When did the Chrome HTTP warning become the default?
Google announced it on October 21, 2026. Its guide ties the default to Chrome 154, which reached stable on September 22, 2026. Enhanced Safe Browsing users got it earlier, in Chrome 150, which reached stable on June 30, 2026, per Google’s enterprise release notes.
How often will visitors see the Chrome HTTP warning?
Once per site. Chrome remembers the user’s choice for 15 days, and each visit renews it. Google’s announcement puts it as at least two weeks without a visit.
Does it warn on intranet sites and printers?
Not by default. Single-label hostnames like intranet/, local IP addresses like 192.168.0.1, and non-unique hostnames are exempt. An appliance reached by a full public-style hostname may still warn, so test it.
Why do we get a warning when our site already uses HTTPS?
Usually a redirect hop. If an old link points to http://example.com and the apex domain has no HTTPS, Chrome warns at that hop. Every step in the chain needs HTTPS.
Does this affect HTTP iframes or forms on our pages?
Not directly. Chrome already blocks mixed content like HTTP iframes and scripts on HTTPS pages. Forms that post to HTTP have drawn warnings since Chrome 87. The new prompt covers page loads and redirects.
Can IT turn the Chrome HTTP warning off for internal tools?
Yes. The HttpAllowlist policy exempts listed hostnames. The HttpsOnlyMode policy can enforce the default with force_balanced_enabled, or strict mode with force_enabled. Chrome’s policy page lists disallowed to turn it off.
Will HSTS stop the Chrome HTTP warning?
HSTS takes precedence over the warning, according to Google’s guide. But HSTS only works once a host serves HTTPS, and browsers ignore the header over HTTP. Fix HTTPS first, then add HSTS.
Do Firefox and Safari do the same thing?
Not quite. Mozilla says HTTPS-First is on by default from Firefox 136. It tries HTTPS and falls back to HTTP. Apple’s WebKit team and Microsoft say Safari and Edge upgrade navigations to HTTPS, and Google’s guide says they offer optional warning modes.
