Chrome on your Android phone may now stop before opening an old website and ask whether you want to continue without a secure connection. In an October 21, 2026 announcement, Google confirmed that it has finished rolling out its “Always Use Secure Connections” protection by default. The change means Chrome asks before making certain unencrypted HTTP connections instead of merely labeling the page “Not secure” after it opens.

That warning does not automatically mean a website has been hacked or that your phone has a virus. It means Chrome could not establish the preferred HTTPS connection for that visit and wants your permission before using HTTP. The practical question is whether you need that particular page badly enough to accept a connection that others on the network might read or alter.

What Chrome does when you tap an old HTTP link

Suppose you follow a bookmark saved years ago, a link in an old email, or an address printed on a device’s instruction sheet. Even if that link starts with http://, Chrome first tries to open the destination securely over HTTPS when possible. If HTTPS works, the website loads normally. You do not have to approve an insecure connection just because the original link was old.

If Chrome cannot establish HTTPS but believes the site may still be reachable over HTTP, it displays the new approval screen before taking that less secure route. You can return rather than connect, or consciously choose to continue. The Chromium team’s technical guidance describes this as an “Ask-before-HTTP” warning. It also makes an important distinction: when you explicitly open an https:// address and that connection fails, Chrome does not silently switch to HTTP. Sites configured to require HTTPS through HSTS likewise do not get an HTTP fallback.

HTTPS encrypts information moving between your phone and the site and helps your browser verify that it is connected to the named website. Ordinary HTTP does neither. Someone in a position to intercept the connection could potentially read the traffic or change the page on its way to you. That matters even if you are only opening a link and have not typed a password.

There is a less obvious case, too: an old HTTP link might redirect immediately to a secure HTTPS page. Chrome can still warn because the first step in that journey is insecure. The final secure connection does not undo exposure during the earlier redirect. Google’s previous “Not secure” address-bar label often appeared too late to alert users to these brief HTTP connections; asking first closes that gap.

Does choosing “Continue” make the site safe?

No. Continuing is permission to use HTTP, not a security fix. Chrome does not encrypt the connection by getting your approval, and it does not certify that the site is legitimate. If the page opens using HTTP, information you send or receive may still be visible to, or modified by, a suitably positioned attacker. Chrome’s Android connection-security guide explains the distinction between a private connection and an unprotected one.

If an unexpected HTTP warning appears on a link claiming to lead to your bank, an online store checkout, a workplace login, or a payment service, return instead. Open the organization’s known official address independently and check the actual domain name. Do not submit passwords, card numbers, personal details, or recovery codes through an HTTP page. The extra tap is not the main danger; the unprotected session that follows is.

A legitimate old website may have no HTTPS option. You might decide to view a public archive or a non-sensitive information page after verifying the address and understanding the risk. Even then, treat what you see as potentially alterable in transit, especially on an unfamiliar shared network. Be cautious about downloads or instructions to install software. A page’s familiarity is not proof that the connection is protected.

HTTPS, on the other hand, is not a certificate of honesty. A scam website can use HTTPS, too. Encryption helps protect the journey between your browser and that domain; it does not establish that the business, seller, message, or download deserves your trust. That is why Chrome’s HTTP warning and its phishing defenses answer different questions.

Why the warning may appear once, return later, or never show up

Google designed this to avoid asking you the same question every day. Its October announcement says that after you approve HTTP access to a site, Chrome will not warn again until you have gone at least two weeks without visiting it. The Chromium guide describes the remembered decision more specifically as lasting 15 days, renewed each time you revisit the site. Those are the sources’ respective descriptions, not a promise that every phone will show a new prompt on a particular calendar date.

The default protection also focuses on public websites. Google says local IP addresses such as 192.168.0.1 and short private hostnames such as intranet are normally exempt from this HTTP warning. They are common ways to reach router setup pages and internal services, where getting a publicly trusted HTTPS certificate can be difficult. No warning in those cases does not mean the HTTP connection has become encrypted.

Another reason your experience may differ from someone else’s is that Chrome respects a secure-connections preference you previously selected, even after the default-on rollout. And if you choose the stricter option that warns for private as well as public sites, your router or intranet experience can change. These are configuration differences, not necessarily signs that one phone got the feature and another did not.

Most people should rarely encounter the prompt. Google says early rollout figures showed nearly 95% of Chrome users on desktop received no HTTP warning in a typical week, while fewer than 1% saw three or more; it says warning rates on mobile were lower still. Those are Google’s reported rollout observations, not an assurance that any individual will never see a warning.

What if the link leads to your home Wi-Fi router?

Routers, network extenders, printers, and other household devices sometimes provide a small setup page at a local address. If your router’s documentation tells you to visit 192.168.0.1, the public-sites-only default usually will not interrupt you with the new Ask-before-HTTP warning. That exception exists because a local address is different from a website exposed across the public internet—not because the router is automatically trustworthy.

If the page no longer opens, first make sure the phone is connected to the intended home Wi-Fi network and that the address matches the label, manual, or official support instructions for your device. A familiar number is not universal: different routers use different addresses. Where the manufacturer offers a working HTTPS interface or official management app, prefer that over an unencrypted admin page.

Some equipment still relies on HTTP for local administration. If you have to use such an interface, do so on a private network you control, not on a public or shared network, and remember that even a password entered on that page is not protected by HTTPS. Keep the device’s firmware current through its supported update process. The absence of Chrome’s new prompt is not a reason to disregard ordinary router security.

There is also a different permission you might see while configuring equipment: a website asking to “look for and connect to” devices on your local network. Chrome’s Android site-permissions help describes Local network access as permission for a website to find or connect to devices on your network. It is intended to stop websites from making those requests without approval. It does not mean that an HTTP router page has suddenly gained HTTPS protection. Grant it only when you recognize the site and need the specific device-setup function.

Four Chrome warnings that mean different things

  • “This site doesn’t support a secure connection” or “Connection is not secure”: Chrome is warning before it uses HTTP because it cannot make the intended connection through HTTPS. The decision is whether to permit an unencrypted visit.
  • “Your connection is not private” or a certificate error: Chrome attempted HTTPS, but something about the secure connection could not be validated. An expired or incorrectly configured certificate, a network problem, or an attack may be involved. This is not the same as a routine HTTP approval prompt. Google’s error-message guidance covers these cases, including checking an incorrect device clock. For a banking or login site, stop rather than hunting for a workaround.
  • A red “Dangerous site” warning: This is associated with Google Safe Browsing and suspected phishing, malware, or another deceptive destination. A website can have HTTPS and still be dangerous. Google recommends not visiting a site flagged this way.
  • A request for local network access: A website wants to communicate with devices on your Wi-Fi or local device. It is asking for a site permission, not permission to downgrade the connection to HTTP. Verify why the site needs access before granting it.

Knowing which warning you are seeing matters more than memorizing the color or button layout. One concerns encryption, another concerns a failed secure connection, another is about the site’s suspected behavior, and the fourth is about access to nearby devices. Treating all four as interchangeable can lead to a bad decision.

How to check the setting in Chrome for Android

On an Android phone, open Chrome, tap the three-dot menu, and go to Settings > Privacy and security. Find Always use secure connections under the Security section. Google’s current Android help page lists two configurations:

  • Warns you for insecure public sites: The default approach, which leaves private sites such as an intranet out of these warnings.
  • Warns you for insecure public & private sites: A stricter choice that can also warn about HTTP on internal network pages.

For most people, the public-sites setting strikes a reasonable balance. If you deliberately selected a different behavior before the rollout, Chrome’s implementation guide says that choice is preserved. On phones using Android Advanced Protection, Google says the feature is enabled with warnings for both public and private sites; device security controls can determine that setting. A work-managed browser may also follow an administrator’s rules.

If the control is missing or doesn’t match the guidance, check for a Chrome update in the Play Store and look under Chrome Settings > About Chrome for the installed version. Google’s Android update instructions cover both steps and list Android 10 and later as supported. Chromium identifies Chrome 154 as the version for default-on Ask-before-HTTP warnings. This is a Chrome browser change, not a requirement to install a particular new Android operating-system version; an older Chrome build or a saved preference may behave differently. Google’s announcement does not list any country-specific restrictions. These menu directions are for Android, not an assumption that Chrome on iPhone presents identical controls.

Disabling the protection globally just to open one old link throws away a useful warning for every future public HTTP destination. It is better to understand the specific page, look for a secure replacement, and decide whether that particular unencrypted connection is acceptable.

If a trusted bookmark suddenly behaves differently

Start by reading the warning rather than repeatedly retrying the link. If it is the new HTTP approval screen, check the destination carefully. A company may have moved a page to an HTTPS address while leaving an old HTTP redirect behind. Going directly to the company’s current HTTPS URL, rather than through the old bookmark or redirecting short link, may avoid that insecure step. If the site really has no HTTPS support, only its owner can fully fix the underlying problem.

If you are instead seeing “Your connection is not private,” an expired-certificate message, or a plain network error, do not assume the new HTTP feature caused it. As Chromium explains, a deliberately specified https:// URL does not automatically fall back to HTTP when the secure connection fails. Check the address, your phone’s date and time, and any official service notice; contact the site or device maker if the error continues. For sites handling accounts or money, don’t switch to HTTP as a workaround.

For a router or extender, confirm the exact local address and make sure you are on the network that hosts it. If a trusted setup webpage asks separately for local network access, review that permission on its own terms. These steps are more useful than switching off Chrome’s browser-wide safeguards.

The takeaway: Chrome is moving the security decision to before the unencrypted connection. On Android, that can make an old link look newly suspicious, but the warning is useful information, not a verdict on the site. Prefer HTTPS, distinguish the type of warning, and treat any decision to proceed over HTTP as accepting a real limitation—not as making the connection safe.