HTTPS-Only Mode: What It Protects and Why You Should Turn It On

HTTPS-Only mode tells your browser to upgrade every request to HTTPS and to show a warning instead of loading a page over plain HTTP. It protects against anyone on the network reading or altering what you see, and specifically against downgrade attacks that intercept the first unencrypted request. Turn it on in Firefox, Chrome and Edge; Safari upgrades automatically but offers no strict setting.

What plain HTTP actually exposes

A page loaded over http:// travels in clear text between your browser and the server, through your Wi-Fi access point, your ISP, and every network in between. Anyone positioned on that path can read the full URL, every form you submit, every cookie without the Secure flag, and the entire page content. More importantly, they can change it. An attacker on the same coffee-shop network can serve a different page than the one you asked for, inject a script into a legitimate one, or replace a download with a different file, and the browser has no way to tell.

HTTPS fixes both problems. TLS encrypts the connection so the path cannot read it, and the certificate lets the browser verify that it is talking to the server named in the URL, so the path cannot substitute another. What a certificate proves and how the handshake works is covered in SSL and TLS explained; for this guide the point is simply that the protection only applies once the connection is HTTPS, and the attack that matters is the one that stops it becoming HTTPS in the first place.

The downgrade attack HTTPS-only exists to stop

Most sites today redirect HTTP to HTTPS. The weakness is in the word "redirect": the browser first sends a plain HTTP request, and the redirect comes back in the plain HTTP response. An attacker on the path can intercept that first request and never let the redirect through. The technique was demonstrated publicly in 2009 as SSL stripping, and it still works against any connection that begins with an unencrypted request.

You type:            example.com
Browser sends:       GET http://example.com/   (plain text)
Attacker on the Wi-Fi intercepts it, fetches https://example.com/ itself,
and returns the page to you over plain HTTP with every https:// link
rewritten to http://. You see the site. You see no padlock. You log in.

Two defences exist. The server-side one is HSTS, the Strict-Transport-Security header, which tells the browser never to use HTTP for that host again; its mechanics and the preload list are in HSTS explained. HSTS has a gap: it only works once the browser has seen the header over a good HTTPS connection at least once, so the very first visit to a site, or a visit after the header's max-age has expired, is still vulnerable, unless the site is on the preload list built into the browser. HTTPS-only mode is the client-side defence that closes that gap for every site, whether or not the site's operator has done their part. Our website scanner reports the server side as HSTS and HTTP redirects to HTTPS; the browser side is yours.

How the mode behaves

With HTTPS-only enabled, the browser rewrites http:// to https:// before sending the request. If the server answers on HTTPS, you never notice. If it does not, either because the site has no TLS at all or because the HTTPS version times out, the browser shows an interstitial page saying the secure connection is not available and offering to continue over HTTP for that site. The mode also upgrades sub-resources: images, scripts and iframes referenced with http:// on an HTTPS page are requested over HTTPS, and blocked if that fails, which makes it a stronger version of the mixed-content blocking described in mixed content explained.

The difference between the browsers' modes lies in how they handle failures. Firefox's original HTTPS-Only Mode is strict: warn on every failure. The newer default in Firefox and the default posture in Safari is HTTPS-first: try HTTPS, fall back silently to HTTP when it is unavailable. HTTPS-first removes the risk on sites that support HTTPS but leaves the attacker the option of simply blocking port 443 to force a fallback, which is why the strict version is the one worth switching on.

Turning it on in each browser

Chrome has moved steadily toward this being the default. It already upgrades HTTP navigations opportunistically and warns before HTTP downloads, and Google has announced its intention to make the public-sites warning the default in a future release. Choosing Warn on public sites is the pragmatic option for most people: it treats 192.168.1.1 and printer.local as the exceptions they are while refusing plain HTTP to anything on the internet.

What breaks, and what to do about it

The honest answer is: less than you expect, and a predictable list.

• Local devices. Routers, printers, network-attached storage and development servers often speak only HTTP. Chrome's public-sites option exempts them automatically; in Firefox, add a permanent exception for each on first visit.
• Captive portals. Hotel and airport Wi-Fi login pages work by intercepting HTTP. Browsers detect captive portals and open the portal page in a special window that bypasses the mode; if that fails, the browsers' interstitials still let you continue.
• Old documentation and hobby sites. A shrinking set of sites has no certificate at all. Click through if you must; nothing you type into them is private.
• Sites that serve HTTPS badly. A site with a certificate for www.example.com but not example.com will fail the upgrade on the bare domain. That is the site's bug, and our SSL checker will show it, but from your side the fix is the exception.

A worked example from a typical week: one exception for a home router, one for a museum's archive site that has never had a certificate, and one captive portal that the browser handled by itself. Against that, every page on the open internet was either already HTTPS or upgraded without a prompt.

What the mode does not cover

HTTPS-only mode is a statement about the transport of the page, not about the page itself. A phishing site with a valid certificate loads over HTTPS without any warning, and most phishing sites now have one, because certificates are free and automated. The padlock means the connection is private and the server is the one named in the address bar; it does not mean the address bar names a site you should trust. Reading the domain is still your job.

The mode also cannot fix a site that serves its main page over HTTPS and then loads scripts or forms from plain HTTP. It will upgrade those requests and block the ones that fail, which protects you, but the site may then be missing features. That is the site owner's problem to solve, and it is a finding our website scanner reports as mixed content. Finally, it covers only the browser: mail clients, chat apps and system updaters make their own connections and have their own settings, so a hostile network still has targets other than the page you are looking at.

Why turn it on when most sites redirect anyway

Because the redirect is the attack surface. The value of HTTPS-only is not in the 99 percent of visits where the site would have redirected; it is in removing the one unencrypted request that every one of those visits still began with. A network attacker needs that request. Take it away and SSL stripping has nothing to strip, on every site, from the first visit, regardless of whether the site sends HSTS or is preloaded. It costs a few clicks a month. It also makes the padlock, or its absence, meaningful again: with the mode on, a page you are looking at is HTTPS unless you personally chose otherwise.

The setting sits naturally next to the others in browser security settings, and its effect on the wider threat model is discussed in the browser security hub. If you run a website, do your side too: redirect, send HSTS with a long max-age, and preload, so that visitors who have not switched the mode on are protected anyway.