Chrome's HTTPS-by-Default Rollout, Explained
Chrome's "Always Use Secure Connections" setting — opt-in since 2022 — is becoming the default during 2026, starting with Enhanced Safe Browsing users and expanding from there. It's a real change, and it's worth checking your own stack against it. It is not, however, a change to CORS, and conflating the two leads to wasted debugging time. Here's what actually moves, what doesn't, and the one place it does intersect with calling APIs from the browser.
What's actually changing
Chrome has offered an "Always Use Secure Connections" toggle since 2022: turn it on, and Chrome tries every navigation over HTTPS first, showing a warning you can click through if a site has no HTTPS to offer. Google has been rolling this setting on by default through 2026 — first for users with Enhanced Safe Browsing enabled, then more broadly over the course of the year, according to reporting from Infosecurity Magazine and ppc.land. Private and local-network addresses are reportedly carved out of the warning, at least for now, so internal tools and localhost development aren't swept in by the first wave.
The mechanism itself is simple: when a user navigates to a plain http:// page with no HTTPS available, Chrome shows an interstitial asking for confirmation before loading it. It's the same category of protection as the long-standing "Not Secure" address-bar label, just promoted from a passive label to an active, bypassable gate.
This is not a CORS change
It's tempting to read "Chrome enforcing HTTPS" and assume it touches CORS, preflight, or Access-Control-Allow-Origin somehow. It doesn't. The Always Use Secure Connections warning fires on top-level navigation — a user loading a page — not on fetch() or XMLHttpRequest calls a page makes in the background. CORS is a same-origin-policy relaxation mechanism that runs independently of whether either side is on HTTP or HTTPS. A plain-HTTP API can send a perfectly valid Access-Control-Allow-Origin header, and an HTTPS API can omit it and still get blocked. Protocol and CORS are orthogonal checks.
Where HTTP actually already blocks a fetch call
There is a real, much older browser mechanism that already stops exactly the pattern developers worry about here: mixed content. A page served over HTTPS cannot fetch() a plain http:// endpoint — the browser blocks the request outright, independent of any CORS headers, before the request even leaves the page. This has been standard behavior for years; Chrome's 2026 default change doesn't add it, extend it, or alter it.
So if you're already serving your frontend over HTTPS (which, per the previous section, is close to mandatory in modern hosting), an HTTP-only upstream API has always been unreachable by direct fetch() from that page — this isn't new, and it isn't something the 2026 rollout changes. What the rollout does add is a warning on the other direction: a user directly navigating to that HTTP-only API's docs page, status dashboard, or admin console now gets an interstitial first.
What to check on your own stack
- Any public-facing page still served over plain HTTP — a status page, an internal tool someone linked externally, a docs site on an old subdomain. Users will start seeing a warning before it loads.
- Hardcoded
http://links in emails, READMEs, or marketing pages that point at your own properties, even if the target actually redirects to HTTPS — the redirect happens after the warning, not before it. - Local development is unaffected for now; reporting on the rollout specifically calls out that private and local addresses are excluded from the first phases.
None of this requires touching your CORS configuration. If your preflight responses and Access-Control-Allow-Origin headers were correct last month, they're still correct — this rollout doesn't change what the browser demands of a cross-origin response.
If you're still stuck with an HTTP-only upstream
Mixed-content blocking isn't new, but it does come up for real: a legacy internal API, a vendor that's never shipped TLS, a device-management endpoint that only speaks HTTP. If your HTTPS frontend needs data from one of those, you have the same two options mixed content has always left you — serve the call from your own HTTPS backend, or put something HTTPS-only in front of the HTTP target so the browser's fetch() never touches a plain-HTTP origin directly.
corsproxy.dev's proxy accepts either http:// or https:// as the target in the url parameter and always answers back over HTTPS from api.corsproxy.dev, regardless of which protocol the upstream speaks:
curl "https://api.corsproxy.dev/proxy?url=http://legacy-internal-api.example.com/status&key=sk_live_..."The browser only ever sees an HTTPS response from an HTTPS origin; the HTTP hop happens server-side, where mixed-content rules don't apply. This also has nothing to do with the Chrome rollout above — it's the same mixed-content workaround a CORS proxy has always provided, worth mentioning here because it's the one place "my HTTP target got blocked" and "Chrome's HTTPS warning" tend to get confused for the same problem.
The one-line takeaway
Chrome defaulting to HTTPS-only navigation warnings in 2026 is a browser-UX change for people visiting sites, not a CORS or fetch() change for API calls. If your frontend is on HTTPS and your API sends correct CORS headers, this rollout changes nothing for you. If any of your own pages — not just APIs — are still served over plain HTTP, that's the thing actually worth fixing before it starts asking your visitors for permission.