HTTP vs HTTPS
HTTP vs HTTPS: what TLS actually protects against, and why there's basically no reason to ship plain HTTP today.
Last updated
The short answer
There's no real argument for plain HTTP on a public site anymore — free certificates, automatic renewal, and browser-side pressure (mixed-content warnings, disabled APIs) closed the gap that used to justify skipping it. HTTPS is the default; the only real question is whether a specific internal or local-dev context can reasonably skip it.
| Dimension | HTTP | HTTPS |
|---|---|---|
| Encryption | None — plaintext on the wire | TLS encrypts request and response |
| Integrity | Modifiable in transit (ISP injection) | Tampering detected and rejected |
| Authentication | No proof you're talking to the real server | Certificate proves server identity |
| Browser APIs | Geolocation, service workers, etc. blocked | Required for most modern APIs |
| Address bar | Flagged 'Not Secure' | Padlock, ranking signal |
| Handshake cost | Slightly less overhead | Mostly hidden by HTTP/2 and session resumption |
Choose HTTP when
- →Strictly local development on localhost, where the browser already treats it as a secure context.
- →An internal service on a network you fully control with no sensitive data — even then, HTTPS is usually still worth the near-zero setup cost.
- →Legacy embedded or IoT hardware too constrained to handle a TLS handshake — a shrinking and increasingly bad excuse.
Choose HTTPS when
- →Any site handling logins, payments, personal data, or anything a user would call private — non-negotiable.
- →You want browser features (service workers, geolocation, clipboard access) that flatly require a secure context.
- →You're running any public-facing site at all — free automated certificates removed the last real cost argument.
The catch nobody mentions
HTTPS protects data in transit, not the endpoints — a compromised server, a malicious browser extension, or a phished password are all untouched by TLS. It also doesn't hide which sites you're visiting from a network observer, since the hostname (SNI) is sent in the clear on most connections unless Encrypted Client Hello is in place — 'HTTPS means private browsing' overstates what the protocol actually hides.
Questions
Does HTTPS slow a site down?
Not meaningfully any more. The handshake costs a round trip, session resumption removes it for repeat visits, and HTTP/2 and HTTP/3 require encryption — so the fastest protocols are only available over HTTPS.
Is HTTPS still worth it for a site with no logins?
Yes. Without it, anyone on the network path can read what visitors browse and inject content into the page — which internet providers and public wifi operators have both been caught doing. It also protects the integrity of what you serve.
What does the padlock actually prove?
That the connection is encrypted and the certificate matches the domain. It says nothing about whether the site is trustworthy, which is why phishing sites have padlocks too — certificates are free and issued to anyone controlling a domain.
What is HSTS for?
It tells browsers to use HTTPS for this domain in future, so the initial plain-HTTP request that a redirect would answer never happens. That request is the window an attacker uses, and HSTS closes it for repeat visitors.
Do I need to pay for a certificate?
No. Let's Encrypt issues free certificates with automated renewal, and most hosts now provision them automatically. Paid certificates differ in warranty and validation level, not in the encryption itself.
What is mixed content?
An HTTPS page loading a resource over HTTP. Browsers block scripts and stylesheets outright and may block images, so a single hard-coded HTTP URL can break a page that otherwise migrated cleanly.