Chrome now asks permission before loading insecure HTTP pages

Google Chrome now stops and asks for permission before it opens an insecure HTTP connection, and that behaviour is on by default for every Chrome user. For marketers the practical question is narrow: does any link you control still pass through http://, even for one redirect hop? If it does, a first-time visitor in Chrome can now meet a warning before they ever reach your page.

What Google announced on 21 October 2026

In a post titled "Chrome Now Warns Before Insecure HTTP Connections", the Google blog said on 21 October 2026 that Chrome has "rolled out a change where Chrome explicitly asks users for permission before making an insecure HTTP connection." The post is signed by six members of Chrome's Secure Web and Networking Team: Joe DeBlasio, Eric Trouton, Chris Thompson, Serena Chen, Mustafa Emre Acer and Carlos Joan Rafael Ibarra Lopez.

The protection is tied to a Chrome setting called "Always Use Secure Connections". Google says it promised the change last year, switched it on earlier in 2026 for people enrolled in the Enhanced Protection mode of Safe Browsing, and has now extended it to all users by default. Google also says Chrome is the first browser to make this change and that it hopes other browsers will follow.

The team's reasoning starts with risk. Any unprotected HTTP request, the post says, gives an attacker a chance to inject malicious content into a user's browsing, often without the user knowing they were exposed. The overwhelming majority of Chrome's connections already use HTTPS, which is why Google now considers a stronger warning workable. With high HTTPS adoption, the team argues, enabling warnings no longer risks warning fatigue for users.

Why the "Not Secure" label stopped being enough

For years Chrome's answer to HTTP pages was a "Not Secure" label in the address bar. Google describes that label as the strongest warning a browser could give while plenty of the web still ran on HTTP, without breaking the experience. The post then lists the label's limits:

• Research shows that passive warnings like a badge can go unnoticed.
• Browsers never get the chance to show a "Not Secure" badge on short-lived HTTP traffic such as redirects, even though the user's data is still put at risk.
• The badge only tells the user after their data and connection have already been exposed, so it cannot help them prevent that exposure.

The second point matters most to anyone who runs campaigns. A redirect that bounces a visitor from an http:// address to an https:// page takes a fraction of a second. Under the old model nobody saw a badge during that hop, so nobody noticed it. Google names redirects as traffic the badge could not cover, and says the new approach asks the user before the insecure connection happens. The post does not walk through a redirect example step by step, so treat this as a reading of Google's stated logic. Test your own links instead of assuming they are fine or broken.

How the new warning behaves

Google accepts in the post that HTTPS adoption is not universal and that some people need to reach HTTP sites regularly. The prompt is therefore designed to appear on a first visit, not on every visit. The rules Google set out on 21 October 2026, in one place:

The exemptions are narrow on purpose. Google says single-label names and local addresses are often used when configuring home wifi routers or similar devices, and notes that an attacker would need to be on the same local network to tamper with that traffic. A public marketing site, a campaign microsite or a link shortener on a public domain does not match that description. All of them can get a trusted certificate, so none of them gets the exemption.

The two-week rule matters for paid traffic. It works per user and per site. A loyal visitor who approves an HTTP page once will not be asked again while they keep coming back. A new visitor from an ad or a social post has never approved anything. First-time visitors are the group most likely to meet the prompt, and they are the visitors advertisers pay to bring in.

Google's early numbers point the same way. If nearly 95% of desktop users see no HTTP warning in a week, the web most people use is already on HTTPS. The sites that still trigger the prompt stand out more as a result, and the warning reflects on whoever owns the link.

Where HTTP still hides in a marketing stack

The exposure now sits in the links around a site, many of which were set up once and never checked again. These are the places worth auditing first:

• Ad final URLs. A final URL entered as http://www.example.com that the server then redirects to HTTPS. The landing page is secure, but the first hop is not.
• Tracking templates and click trackers. Third-party redirectors, affiliate networks and older call-tracking or attribution tools can sit in the chain with their own http:// endpoints.
• Short links. Branded or legacy shorteners created years ago, especially on a custom domain that never received a certificate.
• QR codes. Printed codes on packaging, menus, posters and shop windows encode a fixed URL. If that URL starts with http://, it cannot be edited without a reprint, so the redirect behind it has to be right.
• Old backlinks and press mentions. Links other sites created to an http:// address years ago still send people through an HTTP hop before any redirect kicks in.
• Email templates, social bios and chat links. Link fields that were filled in once and then forgotten.
• Subdomains and microsites. Campaign pages, careers sites, booking engines and pages from old landing-page builders that never got the same certificate setup as the main domain.

Google's post does not discuss any of these cases by name. The list is a practical reading of the change: anything that makes Chrome open an http:// connection to a public host is a candidate for the prompt.

How to check a redirect chain with curl

This section and the next describe general web practice; they are not part of Google's post. The quickest way to see every hop is a header-only request from a terminal. The command curl -sIL http://example.com asks for headers only (-I), follows redirects (-L) and hides the progress meter (-s). Each response prints in order, so you can read the status code and the Location header of every step.

A clean chain looks like this: the first request may hit http://, receives a 301 pointing to https://, and every hop after that stays on https:// until a 200 response. A problem chain looks different. An https:// ad URL might pass through a tracker on http://, or an https:// page might redirect back down to http:// on the way to its final destination. Adding | grep -i -E "^(HTTP|location)" to the end of the command trims the output to status lines and redirect targets, which makes long chains easier to scan.

A few habits make the check more reliable:

• Test the exact URL people click, including tracking parameters, rather than a cleaned-up copy.
• Use the ad platform's own tracking-template test where one exists, because templates can add hops that a plain URL does not show.
• Scan the QR codes already in print and test what they actually decode to, not what the design file says.
• Export your backlink list from an SEO tool and run the http:// targets through the same command.
• Open the final page in a fresh Chrome profile with no history, the way a first-time visitor would see it.

Fixes that remove the HTTP hop

The cleanest fix is to stop pointing people at http:// in the first place. Change ad final URLs, tracking templates, email links and social profile links so they begin with https://. Where a link cannot be changed, such as a printed QR code or a backlink on someone else's site, make sure the server answers the first http:// request with a single permanent redirect straight to the final HTTPS page, with no extra hops in between.

That redirect does not make the first hop secure. The first request still travels over HTTP before the redirect arrives, and whether Chrome's prompt fires on that hop for a given setup is something to test rather than assume. Sites can also send an HTTP Strict Transport Security (HSTS) header so a browser that has already seen it goes straight to HTTPS next time. HSTS only takes effect after that first visit, though, unless the domain is on the browser preload list, so it does little for a first-time visitor arriving through an old http:// link.

For any third-party redirector in the chain, ask the vendor whether every endpoint supports HTTPS. A tool that still requires http:// links is now a direct risk to campaign traffic and a reasonable trigger for replacing it.

It also helps to record what you find. A simple sheet listing each campaign URL, tracker, short link and QR code with its first hop and final status code turns a one-off fix into a check the team can repeat each quarter or before a large launch.

What Google did not say

The announcement is a security post, and its scope is tight. It does not:

• give a Chrome version number or a rollout date for each platform;
• mention Google Search rankings, Google Ads, landing-page experience or Quality Score;
• say how the prompt interacts with conversion tracking, analytics referrers or attribution;
• publish data on how many users proceed past the warning and how many leave;
• describe the warning screen's wording in detail beyond an illustrative image.

Reading ranking or ad-quality effects into the post would go beyond what Google stated. The cost that is easy to see sits elsewhere: a person who meets a warning and decides not to continue is a visit that was paid for and lost. That cost needs no algorithm change to be real.

What this means for Thai marketers

Google's post does not limit the change to any country, so Chrome users in Thailand are covered the same way as everyone else. The checklist is also the same, with extra weight on links that live outside the website: LINE Official Account rich menus and broadcast links, Facebook and Instagram profile links, QR codes printed on menus and point-of-sale material, and links on marketplace storefronts. Older SME sites on shared hosting deserve a direct check of the certificate and of the http:// to https:// redirect.

If a site still serves pages on plain HTTP, the fix is a web project rather than a settings change, and a rebuild or migration of the website itself may be the simpler route. For a full sweep of redirects, mixed content and old backlinks, a technical SEO audit covers the same ground. Campaign URLs and tracking templates belong in a Google Ads account review.

FAQ: Chrome's insecure HTTP connection warning

Is Chrome's HTTP warning now on for everyone?

Yes, Google said on 21 October 2026 that the "Always Use Secure Connections" protection is now on for all Chrome users by default. It had been enabled earlier in 2026 for users in Safe Browsing Enhanced Protection. Google did not give a version number or per-platform dates.

Will visitors see the warning on every visit to an HTTP site?

No, Chrome asks the first time a user visits an HTTP site and, once that user approves, stays quiet until they have not visited the site for at least two weeks. New visitors are therefore the group most likely to see it.

Does an http:// redirect to an HTTPS page trigger the warning?

Google's post does not answer that case directly, so test your own links. It does say the old badge could never cover short-lived HTTP traffic like redirects and that the new approach asks before the insecure connection is made, which is a good reason to remove HTTP hops from redirect chains.

Does this change Google rankings or Google Ads performance?

Google did not say so. The announcement mentions neither Search rankings nor Google Ads; the effect it describes is that users are asked for permission before an HTTP connection is made.

Are routers and internal tools affected?

By default, no: Chrome does not show the warning on sites that cannot get a publicly trusted certificate, such as single-label hostnames like intranet/ and local IP addresses like 192.168.0.1.

The change touches very little code on most sites and a lot of forgotten links around them. An afternoon spent tracing ad URLs, short links and QR codes is cheaper than discovering the problem through a drop in first-visit traffic. If you want a second check on redirect chains and landing pages before the next campaign goes live, the Relevant Audience web and SEO team can help.