HTTP vs HTTPS
In-Depth Technical Comparison & Architecture Guide
The old argument for staying on plain HTTP — that TLS adds meaningful latency — has been substantially undercut by two separate developments: TLS 1.3 cut the handshake from two round-trips to one, and HTTP/2 and HTTP/3 (both dramatically faster than HTTP/1.1) are, in practice, HTTPS-only, meaning skipping encryption today also means giving up the newer protocol versions' own performance gains.
Quick Reference Matrix
| Feature | HTTP | HTTPS |
|---|---|---|
| Default Port | 80 | 443 |
| Encryption | None — plaintext | TLS 1.3 (RFC 8446) or TLS 1.2 |
| Governing Standard | RFC 9110/9111/9112 | RFC 2818 (HTTP over TLS) |
| HTTP/2 and HTTP/3 Support | Technically possible (h2c), not implemented by major browsers | Fully supported and the only path major browsers implement |
| Handshake Overhead (TLS 1.3) | None | 1 round-trip (0-RTT for resumed connections) |
| SEO Ranking Signal | No | Yes — a Google ranking factor since 2014 |
Technology Overview
HTTP, most recently specified as RFC 9110 (semantics), RFC 9111 (caching), and RFC 9112 (HTTP/1.1 message syntax), transmits requests and responses in plaintext — anyone positioned on the network path between client and server can read or modify the traffic. HTTPS is HTTP layered over TLS (Transport Layer Security), originally specified for this purpose in RFC 2818 ('HTTP Over TLS'), providing encryption, integrity verification, and server authentication via the TLS handshake.
TLS itself has evolved substantially: the current version, TLS 1.3 (RFC 8446, 2018), reduced the handshake from TLS 1.2's two round-trips to a single round-trip before encrypted application data can flow (and supports a 0-RTT resumption mode for returning connections), directly addressing the latency overhead that used to be the strongest practical argument against HTTPS.
A detail that changes this comparison's framing entirely: HTTP/2 (RFC 9113) and HTTP/3 (RFC 9114, built on the QUIC transport protocol rather than TCP) are technically specified to allow cleartext operation, but in practice, no major browser implements HTTP/2 or HTTP/3 over unencrypted connections at all — every real-world deployment of these newer, faster protocol versions is HTTPS-only. This means the choice today isn't really 'HTTP vs HTTPS' in isolation; it's 'HTTP/1.1 in plaintext' vs 'HTTP/2 or HTTP/3 over TLS,' and the newer protocol versions' own substantial performance improvements (multiplexing, header compression, and for HTTP/3, elimination of TCP head-of-line blocking) are only available through the encrypted path.
The TLS 1.3 Handshake and Real Performance Impact
A TLS handshake authenticates the server's certificate and negotiates a shared symmetric key before any application data is encrypted and exchanged. Under TLS 1.2, this took two full round-trips between client and server before the first byte of encrypted data could be sent. TLS 1.3 cut this to one round-trip for a new connection, and added a 0-RTT mode allowing a returning client (one that has connected to this server recently) to send encrypted application data immediately, without waiting for a fresh handshake to complete at all.
Combined with session resumption (reusing parameters from a prior connection) and the connection-reuse benefits of HTTP/2's multiplexing (many requests over one connection, avoiding the overhead of opening a new connection — and therefore a new handshake — for every resource), the practical latency cost of HTTPS on a modern stack is genuinely minimal for the vast majority of real-world traffic, a significant change from the meaningfully-measurable overhead TLS 1.2-era HTTPS carried.
Why HTTP/2 and HTTP/3 Are HTTPS-Only in Practice
Nothing in the HTTP/2 (RFC 9113) or HTTP/3 (RFC 9114) specifications technically forbids operating without TLS — HTTP/2 defines an 'h2c' (HTTP/2 cleartext) mode, for instance. In practice, every major browser vendor made an early, deliberate decision to only implement HTTP/2 and HTTP/3 over encrypted connections, effectively making TLS a de facto requirement for using either protocol version on the public web, regardless of what the spec technically permits.
This matters concretely: a site remaining on plain HTTP isn't just accepting the confidentiality/integrity risk of unencrypted traffic — it's also locked out of HTTP/2's multiplexing and header compression and HTTP/3's QUIC-based improvements (faster connection establishment, no TCP head-of-line blocking), both genuinely significant real-world performance gains over HTTP/1.1 that have nothing to do with encryption itself, but that are only reachable via the HTTPS path in every major browser's actual implementation.
How Let's Encrypt Removed the Cost Barrier
Historically, a real barrier to HTTPS adoption was cost and operational friction: TLS certificates from commercial Certificate Authorities cost money and required a manual issuance and renewal process. Let's Encrypt, launched in 2016, changed this by offering free certificates issued and renewed automatically via ACME (Automated Certificate Management Environment, RFC 8555) — removing both the cost and the manual-renewal friction that had previously discouraged smaller sites from adopting HTTPS.
Separately, Google's 2014 announcement that HTTPS would be used as a (lightweight, at the time) ranking signal added a direct SEO incentive on top of the security case — together, these two developments (free automated certificates plus a search-ranking incentive) are widely credited with substantially accelerating HTTPS adoption across the web over the following several years.
HTTP Advantages & Disadvantages
Advantages / Pros
- No certificate provisioning or renewal to manage.
- Marginally simpler for fully isolated, non-sensitive local/internal testing.
Disadvantages / Cons
- Traffic is fully readable and modifiable by anyone on the network path.
- Locked out of HTTP/2 and HTTP/3 in every major browser's actual implementation.
- Flagged as "Not Secure" by modern browsers and penalized in search ranking.
HTTPS Advantages & Disadvantages
Advantages / Pros
- Encrypts and authenticates traffic, protecting against eavesdropping and tampering.
- Required in practice to use HTTP/2 or HTTP/3's substantial performance improvements.
- Free, automated certificate issuance via Let's Encrypt/ACME removes the historical cost barrier.
- A confirmed Google search-ranking signal.
Disadvantages / Cons
- Requires certificate provisioning and renewal (though largely automatable via ACME today).
- A small residual handshake cost remains versus no encryption at all, though minimal under TLS 1.3.
Real-World Use Cases
HTTP
Fully isolated local development
Testing on a local machine with no network exposure, where TLS setup would add friction with no practical security benefit in that isolated context.
HTTPS
Any publicly-accessible website or API
The standard, expected baseline for production traffic, required for HTTP/2/3 and rewarded in search ranking.
Developer Recommendation
Enforce HTTPS on every publicly-accessible site or API without exception — the historical cost and latency arguments against it have both been substantially undercut by Let's Encrypt's free automated certificates and TLS 1.3's single-round-trip handshake.
Use a free, automated ACME-based certificate provider (Let's Encrypt or similar) rather than a manual commercial certificate process, unless you have a specific organizational requirement pointing elsewhere.
If you care about HTTP/2 or HTTP/3's performance benefits specifically, know that adopting HTTPS isn't optional for reaching them — every major browser's actual implementation requires the encrypted path for both protocol versions regardless of what the specifications technically permit.
Frequently Asked Questions
- Does HTTPS slow down page loads?
- Much less than it used to. TLS 1.3 reduced the handshake to a single round-trip (with 0-RTT for resumed connections), and combined with HTTP/2/3's connection-reuse benefits, the practical latency cost of modern HTTPS is minimal for the vast majority of traffic.
- Can I use HTTP/2 without HTTPS?
- Technically the HTTP/2 specification allows a cleartext mode (h2c), but no major browser implements HTTP/2 over unencrypted connections in practice — every real-world browser deployment of HTTP/2 requires TLS.
- Is HTTPS actually a Google ranking factor?
- Yes — Google confirmed HTTPS as a search ranking signal in 2014, and it has remained one since, adding a direct SEO incentive alongside the underlying security and performance benefits.
- Do I have to pay for an HTTPS certificate?
- No — Let's Encrypt, launched in 2016, provides free certificates issued and renewed automatically via the ACME protocol (RFC 8555), which removed the cost and manual-renewal friction that previously discouraged many sites from adopting HTTPS.
- What port does HTTPS use, and why is it different from HTTP?
- HTTPS defaults to port 443, while HTTP defaults to port 80 — a convention (not a technical requirement) that lets a server and firewall distinguish encrypted from unencrypted traffic by port number alone.
- Is it ever acceptable to use plain HTTP in production?
- Essentially no for any publicly-accessible service today — the historical arguments for it (cost, latency) have both been substantially weakened, and modern browsers actively flag plain HTTP sites as "Not Secure," which itself damages user trust regardless of the underlying technical risk.
Part of the HTTP & Web Protocols Developer Hub
This comparison is part of our HTTP & Web Protocols topic guide, covering related tools, standards, and decision guidance.
Launch Interactive Developer Tools
Put these concepts into practice. Test, format, serialize, or analyze your inputs locally with these secure, browser-only utilities: