HTTP vs HTTPS

HTTP (Hypertext Transfer Protocol) is the application-layer protocol that browsers and servers use to exchange web content. An HTTP request is plaintext: the method, URL, headers, and body are all transmitted unencrypted. Any network intermediary — an ISP, a CDN, a Wi-Fi router, or an attacker — can read and modify the traffic.

HTTPS is HTTP transmitted over a TLS (Transport Layer Security) connection. The HTTP request and response are identical in structure; the difference is that TLS wraps the connection in an encrypted channel before any HTTP data flows. From the application's perspective, writing code for HTTP and HTTPS is identical — the TLS layer is handled by the web server or reverse proxy.

The “S” in HTTPS stands for “Secure” — specifically:

• Confidentiality — the request and response body, headers, cookies, and URL path are encrypted. An observer on the network can see only the destination IP address and approximate payload size.
• Integrity — TLS's AEAD cipher detects any modification to packets in transit. Man-in-the-middle content injection is not possible.
• Authentication — the server presents a TLS certificate signed by a trusted Certificate Authority. The browser verifies the certificate's hostname matches the URL and the chain of trust leads to a pre-installed root CA.

HTTPS was historically associated with e-commerce and login pages — the padlock appeared only where sensitive data was transmitted. The rest of the web ran on HTTP. Several converging changes shifted this to “HTTPS everywhere”:

• Free certificates (2015). Let's Encrypt launched in 2015, making trusted TLS certificates freely available with automated issuance and renewal. The cost barrier to running HTTPS on any domain dropped to zero.
• HTTP/2 requires TLS (2015). The HTTP/2 specification allows plaintext use, but all browser implementations require TLS. HTTP/2 multiplexing, header compression, and server push only work on HTTPS. Sites that stayed on HTTP were stuck at HTTP/1.1.
• Google's HTTPS ranking signal (2014). Google started using HTTPS as a ranking signal. HTTP sites gradually lost search visibility relative to HTTPS equivalents.
• Browser “Not Secure” labels (2018). Chrome 68 (2018) began marking all HTTP pages as “Not Secure” in the address bar. Firefox and Safari followed. HTTP pages with form inputs show additional warnings.
• Secure cookie and API features require HTTPS. The Secure cookie attribute (prevents cookies from being sent over HTTP), Service Workers, Web Push, Geolocation API, and camera/microphone access all require a secure context (HTTPS).

A common objection to HTTPS migration is performance overhead. In 2026, this is no longer a meaningful concern:

• TLS handshake overhead is negligible. TLS 1.3 completes in 1 round trip (versus 2 for TLS 1.2). For most connections, the handshake adds < 10 ms, which is dominated by network latency.
• TLS session resumption eliminates repeated handshakes. For returning users, TLS 1.3 0-RTT session resumption and TLS 1.2 session tickets skip the full handshake entirely.
• HTTP/2 makes HTTPS net faster for most pages. HTTP/2 (HTTPS only in browsers) multiplexes all page resources over a single connection, eliminating the head-of-line blocking and parallel connection limits of HTTP/1.1. A page with 30 sub-resources loads faster over HTTPS/HTTP2 than HTTP/HTTP1.1.
• Modern CPUs handle AES-GCM in hardware. AES-NI instructions mean symmetric encryption adds almost no CPU overhead on any server hardware produced in the past decade.

The 2016 research project “HTTPS is faster than HTTP” at httpvshttps.com demonstrated this — the multiplexing advantage of HTTP/2 over TLS consistently outweighed any TLS overhead on real-world page loads.