Code · June 1, 2026

HTTP vs HTTPS in 2026: why plain HTTP is effectively dead

HTTPS is no longer optional and has not been for years. This 2026 guide explains the technical differences, TLS 1.3 improvements, and what still trips teams up.

By ByteLedger Team

HTTP sends everything in plaintext. Every header, every cookie, every form submission, every URL parameter — all readable by anyone on the network path between client and server. HTTPS wraps HTTP in TLS, encrypting that traffic and authenticating the server's identity. In 2026, shipping a public-facing service over plain HTTP is not a technical trade-off — it is a misconfiguration.

What changed in 2026

TLS 1.0 and 1.1 are disabled everywhere — all major browsers and servers dropped support. TLS 1.2 is the minimum; TLS 1.3 is the default.
Let's Encrypt has issued over 4 billion certificates — automated ACME-based issuance is built into every major hosting platform, reverse proxy, and cloud provider.
HTTP/2 requires HTTPS — all browser implementations of HTTP/2 mandate TLS. If you want multiplexed streams (faster page loads), you must use HTTPS.
HTTP/3 (QUIC) requires HTTPS — QUIC has TLS 1.3 baked in at the protocol level; there is no plaintext HTTP/3.
Service mesh mTLS is standard — Istio, Linkerd, and AWS App Mesh default to mutual TLS for east-west (service-to-service) traffic.

What HTTPS actually does

Plain HTTP request:
GET /account?token=abc123 HTTP/1.1
Host: example.com
Cookie: session=xyz789
Authorization: Bearer secret-token

All of the above is visible to any network observer (ISP, coffee shop router, MITM proxy).

HTTPS (TLS 1.3):
- TLS handshake authenticates the server via its certificate
- A shared session key is derived (ECDH key exchange)
- All subsequent data is encrypted with AES-GCM or ChaCha20-Poly1305
- Headers, body, URL path, and cookies are all encrypted
- Only the destination IP and SNI hostname are visible to observers

TLS 1.3 vs TLS 1.2 performance

Metric	TLS 1.2	TLS 1.3
Handshake round trips	2 (full)	1
0-RTT resumption	No	Yes (with session tickets)
Cipher suites	Many (some weak)	5, all strong
Forward secrecy	Optional	Mandatory (ECDHE)
Handshake latency (same datacenter)	~8 ms	~4 ms
Handshake latency (cross-continent)	~200 ms	~100 ms

TLS 1.3 with session resumption approaches zero additional latency for returning clients — the "HTTPS is slow" complaint is a TLS 1.0/1.2 era artefact.

Certificate setup with Let's Encrypt

# Certbot (nginx, standalone)
certbot --nginx -d example.com -d www.example.com

# Caddy (zero config — auto-HTTPS by default)
# Caddyfile:
example.com {
  reverse_proxy localhost:3000
}
# Caddy obtains and renews the certificate automatically.

# Kubernetes with cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

# Then annotate your Ingress:
# cert-manager.io/cluster-issuer: "letsencrypt-prod"

HSTS: locking in HTTPS

# nginx: send HSTS header
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

With HSTS set:

Browsers refuse to connect over HTTP for the declared duration
preload submits your domain to browser preload lists (hard-baked HTTPS enforcement, no first-visit downgrade possible)
includeSubDomains covers all subdomains — only add if all subdomains serve HTTPS

Service-to-service: mTLS

For internal services, HTTPS authenticates the server but not the client. Mutual TLS (mTLS) adds client certificate validation:

// Go server: require client certificate
tlsConfig := &tls.Config{
    ClientAuth: tls.RequireAndVerifyClientCert,
    ClientCAs:  certPool, // load your internal CA
    MinVersion: tls.VersionTLS13,
}
server := &http.Server{
    TLSConfig: tlsConfig,
    Addr:      ":8443",
}

In Kubernetes, service mesh solutions (Istio, Linkerd) inject mTLS automatically with SPIFFE/SPIRE identity — you do not write TLS code at all.

How to pick

Public-facing web service? → HTTPS, full stop. Use Let's Encrypt + certbot or Caddy.
Service-to-service in a Kubernetes cluster? → mTLS via service mesh, or at minimum TLS with internal CA.
Local development? → HTTP is fine; use mkcert for localhost HTTPS if you need to test HTTPS-only browser APIs (Service Workers, Web Crypto).
Static files on a CDN? → CDN handles TLS termination; configure HTTPS-only redirect at the CDN edge.

Common mistakes

Serving mixed content (HTTPS page loading HTTP assets). Browsers block active mixed content (scripts, iframes) and warn on passive (images). Audit with Chrome DevTools > Security panel.

Not renewing certificates. Let's Encrypt certs expire in 90 days. Automate renewal with certbot renew in a cron job or use a platform that auto-renews (Caddy, Fly.io, Vercel, Cloudflare).

Using a wildcard cert without understanding SANs. Modern browsers require the Subject Alternative Name extension, not just the Common Name. certbot handles this; manually created certs sometimes miss it.

Disabling HTTPS for "internal" load balancer to backend traffic. Unencrypted internal traffic is vulnerable to lateral movement after a network compromise. Use TLS all the way to the origin.

What to skip

Self-signed certs in production — use Let's Encrypt or an internal CA with cert-manager. Self-signed certs require distributing root certs to every client, which is operationally painful.
HTTP on port 80 without redirect — always redirect 301 to HTTPS. Some crawlers and monitoring tools still hit port 80.
Extended Validation (EV) certificates — browsers removed the EV indicator from the address bar. EV certs cost more and offer no UX benefit over DV (Let's Encrypt) certs.

FAQ

Does HTTPS hide the domain I am visiting? The SNI (Server Name Indication) field in the TLS handshake reveals the hostname to network observers in most configurations. Encrypted Client Hello (ECH) hides the SNI; it is supported by Cloudflare and some browsers in 2026 but not yet universal.

Can HTTPS be decrypted by my employer or ISP? Yes, with a MITM proxy that presents a certificate your device trusts (e.g., corporate root CA installed on your laptop). This is called TLS inspection and is common in corporate environments.

Is HTTP/2 faster than HTTP/1.1 over HTTPS? Meaningfully so — multiplexed streams eliminate the per-request connection overhead. Most performance gains attributed to "switching to HTTPS" are actually HTTP/2 gains.

What is HSTS preloading and should I use it? Preloading submits your domain to browser-embedded lists so HTTPS is enforced before the first request. Only add preload if you are certain all subdomains serve HTTPS — removing a domain from the preload list takes months.