Chrome HTTPS-First October 2026: What Changes for HTTP Websites

Verified directly from Google’s Chrome Security Team blog post: with the release of Chrome 154 in October 2026, Chrome will change its default settings to enable ‘Always Use Secure Connections.’ This means Chrome will ask for the user’s permission before the first access to any public site without HTTPS. Today is June 19, 2026. That gives site owners with HTTP holdouts roughly four months before this becomes the default for every Chrome user worldwide.

What Is Actually Changing (and What Isn’t New)

This is not a brand new browser feature. ‘Always Use Secure Connections,’ Chrome’s HTTPS-First Mode, has existed as an opt-in setting for several years, dating back to early testing in Chrome 94 and a broader opt-in rollout around 2021 to 2022. Anyone can already turn it on manually today. What is changing is that Google is making it the default for everyone, on a two-phase rollout.

If you are reading this after April 2026 and have noticed new HTTPS warnings appearing in Chrome, you are very likely an Enhanced Safe Browsing user already inside Phase 1. October 2026’s Chrome 154 release is when this becomes universal.

What Users Will Actually See

The exact mechanism, per Google’s own description: Chrome will ask for the user’s permission before the first access to any public site without HTTPS. Three specific behaviors matter for understanding the real-world impact:

• It only warns on first access, not every time: once a user has clicked through the warning for a specific HTTP site, or that site is one they visit regularly, Chrome does not repeatedly warn them on every subsequent visit. The warning specifically targets new or infrequently visited HTTP sites, not established browsing habits.
• The warning is bypassable: users who see the warning can choose to proceed anyway and load the HTTP site. This is friction, not a hard block. The setting is also user-controllable; anyone can disable ‘Always Use Secure Connections’ entirely if they choose to, even after Chrome 154 makes it the default.
• It applies only to public websites: local IP addresses, internal company networks, intranets, and local routers are explicitly exempt from these warnings. Google’s stated reasoning, per Infosecurity Magazine’s reporting, is that these internal systems typically carry less risk and are often harder to secure with publicly trusted HTTPS certificates, since public CAs cannot issue certificates for private IP addresses or non-public internal hostnames.

The internal-network exemption is an important detail for business IT teams to understand correctly: it does not mean internal tools are safe to leave on HTTP indefinitely, only that Chrome’s specific October 2026 default change will not generate user-facing warnings for genuinely private, non-publicly-routable systems. An internal tool that is accidentally exposed on a public IP address or public hostname, even if intended only for internal use, is not covered by this exemption and will trigger the warning like any other public HTTP site.

How Much Real-World Impact Should You Actually Expect?

Google ran its own experiment before announcing this change, enabling the setting for a small percentage of users on public sites in Chrome 141. The result: the number of warnings triggered was less than 3% of navigations. Combined with the broader context that over 95% of global web traffic already uses HTTPS, this suggests the change will be largely invisible for the majority of everyday browsing, since most sites users actually visit have already migrated.

The practical implication: this change is not a broad disruption to typical browsing. It is a targeted enforcement mechanism aimed specifically at the remaining minority of HTTP holdout sites, which, while a small percentage of overall web traffic, still represents a meaningful number of individual websites that have not migrated.

Who Gets Hit Hardest: The Realistic HTTP Holdout Categories

Given that most major, actively maintained websites already use HTTPS, the sites most likely to trigger warnings under this change fall into a few specific, recognizable categories:

• Old or abandoned small business websites: sites built years ago, rarely updated, often still on the original hosting setup from when they launched, frequently without SSL because it once required separate purchase and manual installation rather than today’s free, automatic options.
• Archived content and old documentation: legacy documentation sites, old blog archives, and historical content that organizations have not prioritized migrating because traffic to them is low and nobody actively maintains them.
• Internal tools accidentally exposed publicly: a tool genuinely intended only for internal company use that, due to misconfiguration, is reachable at a public IP address or public hostname rather than being properly restricted to an internal network, meaning it does not benefit from Chrome’s local-network exemption.
• Vendor and partner portals that never modernized: third-party tools, supplier portals, and partner-facing systems that an organization depends on but does not control directly, where migration depends on the vendor’s own update timeline rather than the affected organization’s.

What Site Owners Should Do Before October 2026

Google’s own guidance to website developers and IT professionals is direct: enable the ‘Always Use Secure Connections’ setting yourself, today, specifically to identify which sites in your own browsing and business ecosystem still need HTTPS migration before the global default takes effect.

To enable it now and start testing:

chrome://settings/security

Under the Secure connections section, toggle Always use secure connections on. This setting is disabled by default today; it is the exact setting Chrome 154 will enable automatically in October 2026. Turning it on now lets you see, firsthand and ahead of the deadline, exactly which sites in your regular workflow, internal tools, and vendor relationships will trigger a warning.

Practical action steps, in order:

• Enable the setting in your own browser now and browse your organization’s full site portfolio, internal tools, and frequently used vendor portals to identify any HTTP holdouts before the deadline forces the discovery
• Audit any site you control for HTTP-only pages, embedded HTTP resources, and forms that submit over HTTP rather than HTTPS, since the warning fires on the navigation itself even for otherwise low-risk static content
• Contact vendors and partners operating HTTP-only portals your organization depends on, to confirm their own migration timeline before October 2026
• For any site still on HTTP, obtain and install an SSL certificate; free, automated options (Let’s Encrypt via your hosting provider’s AutoSSL, or a managed platform’s built-in SSL) cover the large majority of standard website migration needs at no cost
• Verify the migrated site redirects HTTP to HTTPS correctly and that no mixed content (HTTP resources loaded on an otherwise HTTPS page) remains, since incomplete migrations can still trigger partial warnings

For organizations managing many domains or subdomains, running a bulk check rather than testing one site at a time saves significant effort. A simple script using curl or a bulk SSL checking tool against your full list of owned domains and known internal tool URLs can identify every HTTP-only endpoint in one pass, rather than discovering them one at a time as the October 2026 deadline approaches and warnings start appearing organically.

Frequently Asked Questions

If my site already has an HTTPS certificate installed, do I need to do anything before October 2026?

If your site is fully migrated to HTTPS, with no mixed content and all HTTP traffic correctly redirecting to HTTPS, you do not need to take any action for this specific change. Chrome’s HTTPS-First default change only generates warnings for sites it cannot connect to over HTTPS at all, or new and infrequently visited sites lacking HTTPS support. A properly configured HTTPS site is unaffected by this rollout regardless of which Chrome version a visitor is running.

Will this affect my company’s internal intranet or internal tools?

Genuinely internal systems, meaning sites reachable only via local IP addresses or within a private internal network rather than a public hostname or public IP address, are explicitly exempt from these warnings under Google’s stated scope for this change. However, if your internal tool is technically reachable at a public hostname or public IP address, even if it is intended only for internal use and not actively advertised, it does not qualify for this exemption and will be treated like any other public HTTP site. Verify how your internal tools are actually reachable on the network, not just how you intend them to be used, before assuming the exemption applies.

Does this mean HTTP will stop working entirely after October 2026?

No. HTTP sites will still load; users will simply see a warning before the connection is established on first or infrequent visits, and can choose to proceed past the warning if they wish. This is friction designed to inform and nudge users toward safer behavior, not a hard technical block that prevents HTTP sites from functioning. Users can also disable the ‘Always Use Secure Connections’ setting entirely if they want to remove the warnings altogether, though doing so removes the protection the setting is designed to provide.