For over a decade, the web development community has operated under a simple mantra: HTTPS everywhere. Redirect all HTTP traffic to HTTPS. Encrypt everything. Protect your users. It sounds reasonable,security is good, right? But in 2026, this blanket approach has become counterproductive, exclusionary, and based on fundamentally flawed assumptions about how modern browsers work and who actually needs protection.
Let’s examine why forcing HTTPS redirects on static, public content isn’t protecting anyone, it’s just locking people out.
Modern Browsers Already Do This
Here’s what the “HTTPS everywhere” advocates don’t tell you: modern browsers automatically upgrade HTTP requests to HTTPS when a valid certificate is available. Since 2023, this has been the default behavior in Chrome 115+, Firefox, Safari, and Microsoft Edge. If a user visits //yourblog.com in any modern browser, and you have an SSL certificate installed, the browser upgrades the connection to HTTPS automatically, without any redirect from your server.
Your forced server-side redirect isn’t protecting these users. It’s redundant. They were already going to get HTTPS.
So if modern browsers are handling this automatically, who is your HTTPS redirect actually affecting? The answer is uncomfortable. You’re not protecting the 95% of users on modern browsers, they’re already upgraded. You’re affecting roughly 5% of users on systems that cannot handle modern TLS protocols. And you’re not “protecting” them by forcing HTTPS; you’re blocking them entirely from accessing your content.
You are denying access to 5% of users to “protect” maybe 0.1% who don’t need protection in the first place.
The Bootstrap Paradox: When Security Creates Crisis
I had a client recently whose phone was having SSL certificate issues. They couldn’t access Google, couldn’t search for solutions, couldn’t load troubleshooting guides, because every single one of these sites is HTTPS-only. I directed them to one of the few remaining HTTP-accessible search engines, and they were finally able to search. Results appeared: “How to fix SSL certificate errors on Android.”
Every single result was behind HTTPS.
The guides explaining how to fix SSL problems were all locked behind SSL. This isn’t a hypothetical edge case, this is digital exclusion masquerading as security. When someone’s device has a dead CMOS battery and the system clock is wrong, certificate validation fails. When certificate stores get corrupted, when someone’s running a system with outdated root certificates or TLS protocol incompatibilities, these people need access to troubleshooting information. By forcing HTTPS on help documentation, you’ve created a catch-22: to learn how to fix your SSL problem, you must first not have an SSL problem.
Who Actually Gets Locked Out?
The security industry dismisses these users as “edge cases” running “obsolete systems,” but let’s be specific about who you’re actually blocking:
- Factory control systems running Windows Embedded that can’t be upgraded
- Hospital equipment that requires regulatory approval to modify and often runs for decades by design
- Point-of-sale systems in retail environments
- Users in developing nations on older hardware they can’t afford to replace
- Government and enterprise legacy systems still in production
- Industrial machinery with embedded browsers
- People in emergency scenarios trying to troubleshoot broken devices
These aren’t people who “should just upgrade”, these are real users trying to access public information that doesn’t need encryption in the first place.
What Are You Actually Protecting?
HTTPS protects data in transit from being read by third parties, prevents tampering, and protects user privacy so ISPs can’t see page content. But what are you encrypting on a blog post about cooking? On help documentation? On news articles? On product descriptions?
For static, public content, encryption is solving a problem that doesn’t exist. If you’re not transmitting sensitive data, you don’t need it. A blog? Your visitors don’t need SSL to read. Help files? News sites? Anything text-based and public? Not needed. Now, if your site has a login option, absolutely, set up a rewrite rule, protect login pages, make them inaccessible via HTTP. You don’t want people snooping sensitive information. But forcing encryption on a recipe for sourdough bread serves no purpose except to exclude people who can’t comply.
The ISP Injection Argument: Whose Problem Is It?
Security advocates claim that without HTTPS, ISPs can inject ads or malicious scripts into your pages. This is true, ISPs can do this with HTTP traffic, and companies like Comcast and AT&T have been caught doing exactly that. But let’s examine this honestly.
For modern browsers, they auto-upgrade to HTTPS anyway, so the ISP can’t inject anything and your redirect is irrelevant. For legacy browsers, your HTTPS redirect blocks them entirely, they see nothing, not even the content with injected ads. The actual question becomes: is it the webmaster’s job to protect users from their ISP’s business practices?
ISP injection doesn’t compromise your server. Your data isn’t stolen, your website isn’t breached, your reputation isn’t damaged. This is between the user and their network provider. If their ISP injects ads into HTTP traffic, they’re seeing those ads on every HTTP site they visit. Your cooking blog isn’t going to save them by blocking them entirely. They’d rather see your content with an injected ad than no content at all.
You’re not protecting them by forcing HTTPS, you’re excluding them. The ISP injection argument is used to guilt webmasters into forced HTTPS, but it’s not a webmaster security problem, and your HTTPS redirect doesn’t solve it anyway.
The Phishing Red Herring
For years we’ve been told that HTTPS reduces phishing because users learn to look for the padlock. The data says otherwise. Phishing is at record highs despite widespread HTTPS adoption, and the reason is simple: phishers use HTTPS too. Free SSL certificates from Let’s Encrypt mean any scammer can get that padlock. The padlock means “encrypted,” not “trustworthy,” but users don’t understand the distinction.
Social engineering is the real vector, attackers use urgency, authority, and fear, and the protocol doesn’t matter. If anything, HTTPS has legitimized phishing sites by training users to trust padlocks blindly. Forcing HTTPS on your blog didn’t prevent phishing; it just created false confidence.
Performance Still Matters
Yes, TLS handshake overhead has decreased and modern systems handle it fine. But consider users on satellite internet with high latency, mobile users on metered data in developing regions, or slow connections where every millisecond counts. For a static help page or blog post, this overhead serves no purpose. You’re adding latency to deliver “security” that protects nothing.
The Sensible Approach: Selective HTTPS
What actually makes sense is this: enforce HTTPS where it matters. Login pages should redirect to HTTPS. Payment forms should be HTTPS only. User dashboards, API endpoints with authentication, anything transmitting personal data, absolutely, HTTPS only. But for public content like blog posts, help documentation, news articles, and static informational pages, serve it on both protocols and let the browser decide.
Modern browsers will upgrade automatically. Legacy browsers will get the content they need. And for critical documentation, system recovery guides, network troubleshooting, certificate debugging help, always maintain HTTP fallbacks. When someone’s SSL is broken, they need to be able to access the fix.
Install SSL certificates. They’re free and there’s no reason not to. But don’t force HTTP-to-HTTPS redirects on public content. The certificate is there for browsers that can use it. Modern browsers will automatically upgrade to HTTPS when they see you have one. Your redirect adds nothing for them, they were already upgraded. The only people affected by your redirect are the ones who can’t handle modern TLS, and blocking them entirely isn’t protection.
The Real Cost
The intent behind “HTTPS Everywhere” was protection, but the result is exclusion. When you force HTTPS on static, public content, you’re not protecting anyone, you’re just denying access to people who can’t comply. You’re solving a problem that modern browsers already solved, and you’re creating barriers for the people who need information most.
Think about who writes a blog post about how to get to the internet when your SSL isn’t working and then places it behind SSL. That’s the absurdity we’ve created. We’ve locked troubleshooting guides behind the very problem they’re meant to solve.
Modern browsers handle upgrades automatically. Forced redirects only affect users who can’t handle modern TLS. If someone can access HTTPS, it’s automatic if you have a certificate. You are not protecting users by denying them any access. There is, in fact, as originally stated, no reason to force all users to HTTPS.
The web was built on accessibility. Security should enhance that principle, not destroy it. Let the browser decide. Protect what actually needs protection. Stop sacrificing accessibility for security theater.
