Chrome's HTTPS warning can start before the site you meant to visit

A link can finish at an HTTPS website and still take an insecure step on the way there. That is the easily missed detail in Google's plan to make Chrome ask permission before opening public sites over unencrypted HTTP. The warning can concern an intermediate address, not the page a reader expected to reach.

Google has announced that the public-sites version of “Always use secure connections” will become the default with Chrome 154 in October 2026. Its current Chromium adoption guide still describes that change as forthcoming. This article explains the documented behaviour and preparation steps; it does not establish that the default has reached every browser. The setting already exists for users who want to enable it.

For readers, the distinction helps explain an unfamiliar interruption. For people running a website, it changes what needs testing: not just the final page, but the addresses that send visitors there.

Consider a short promotional link that forwards to a company's main website. If that forwarding host cannot accept HTTPS connections, a visitor may encounter a warning before reaching the encrypted destination. According to Chromium's guide, every step in an inbound redirect chain needs HTTPS support to avoid these warnings.

The same issue can arise without an outside marketing service. A site's bare domain may forward visitors to its www address. If the final www site supports HTTPS but the bare domain does not, checking only the final page misses the problem. Google's example specifically identifies this gap between the two hosts.

That does not mean every link beginning with HTTP will produce a warning. Chrome tries to upgrade connections to HTTPS. The question is whether the relevant host can complete that secure connection, rather than whether an old bookmark happens to contain the shorter protocol prefix.

Google's security team explains why it is addressing the journey. An HTTP connection that immediately redirects to HTTPS can be invisible to the visitor: by the time the final address appears, the insecure step has already happened. The final connection does not retrospectively protect that earlier exchange.

Chromium says its Ask-before-HTTP warning appears when Chrome cannot connect to a site over HTTPS but believes an HTTP connection may work. It asks before using that unencrypted connection. This is a permission boundary, not a declaration that the destination has been identified as malicious.

Nor is it a blanket ban on HTTP. The warning is bypassable. Google's documentation says Chrome remembers a user's decision for 15 days and renews the exception when that person revisits the site. Someone who regularly uses an HTTP site may therefore see the warning only once, rather than on every visit.

There are important limits to that fallback description. If someone explicitly follows or enters an HTTPS URL and the connection fails, Chromium says the browser shows the regular network error rather than trying HTTP. Sites protected by HTTP Strict Transport Security, or HSTS, also do not fall back to HTTP. The new default should not be read as permission to disregard existing connection errors.

The warning is about transport: whether the connection between browser and site is protected against someone viewing or changing information in transit. It is not a review of the business, its products or the truth of its claims.

Google's help page advises checking the site name in the address bar even on secure sites and being careful with personal information. HTTPS should not be treated as a reason to trust an unfamiliar seller or enter sensitive details. Conversely, the absence of HTTPS is a connection problem, not by itself proof that a particular site has committed fraud.

Keep other warnings separate. Google's help documentation distinguishes an insecure connection from a full-page red warning for a site flagged by Safe Browsing. Chromium also says existing HTTPS certificate-error warnings are not changing as part of Ask-before-HTTP. A broken or expired certificate is not the same issue as a host that only offers HTTP.

The version Google plans to enable by default warns for insecure public sites. A stricter option also covers private sites, such as a company's intranet. Google's desktop help page presents these as two configurations of the same setting.

In its adoption guide, Chromium says local IP addresses, single-label hostnames and non-unique names such as a local development hostname do not trigger the public-sites warning. Localhost is also excluded. But a development server using a public hostname can still prompt a warning if it lacks HTTPS support. “Only used by our team” is not, on its own, the relevant technical distinction.

For an organisation managing Chrome, policy controls can affect the experience. The Chromium guide documents an HTTP allowlist and policies for enforcing different modes. It also says Chrome will respect a user's previously chosen setting after the default changes. Not everyone will necessarily see the same behaviour after an update.

On a desktop computer, Google's documented path is Settings, Privacy and security, Security, then “Always use secure connections” under Secure connections. The public-sites option provides a way to check the planned default's scope before relying on a rollout.

Website operators have a more useful test than opening their homepage once. Follow the inbound links people actually receive: a campaign link, a forwarded domain and the bare-domain version of the address. Chromium recommends inspecting the address when a warning appears and using Chrome DevTools' Network panel to identify redirect hops without HTTPS support.

Where a forwarding service controls the intermediate host, its provider may need to enable HTTPS. Asking visitors to switch off warnings does not repair that missing support. A successful test is a route whose relevant hosts all support HTTPS, not simply a destination that looks secure after several redirects.

For ordinary readers, the useful habit is more modest: notice which address the warning names and distinguish a connection warning from a verdict on a website. For site owners, the work is concrete. An encrypted homepage is only part of the journey.