HTTP vs HTTPS

Every time your browser loads a web page, it's running a request-response conversation with a server. That conversation follows a protocol called HTTP. For most of the web's history, that conversation happened in plain text — completely readable by anyone in between. HTTPS fixed that. Understanding both tells you something fundamental about how the web works and why security matters at the transport layer.

HTTP

HTTP stands for HyperText Transfer Protocol. It's an application-layer protocol — meaning it runs on top of TCP/IP and defines how clients (browsers, apps, CLIs) and servers communicate.

The model is simple: the client sends a request, the server sends a response. HTTP is stateless — each request is independent. The server doesn't remember previous requests unless something (like a cookie or session token) is used to link them.

HTTP defines a set of methods that describe the intent of the request:

• GET — retrieve a resource (a page, a file, data)
• POST — send data to the server (submit a form, create a record)
• PUT — replace a resource at a given URL
• PATCH — partially update a resource
• DELETE — remove a resource

And status codes in the response tell you what happened:

• 200 OK — success
• 201 Created — resource created
• 301 Moved Permanently — redirect
• 400 Bad Request — client sent something malformed
• 401 Unauthorized — not authenticated
• 403 Forbidden — authenticated but not allowed
• 404 Not Found — resource doesn't exist
• 500 Internal Server Error — something broke on the server

HTTP Request Anatomy

Here's what an actual HTTP request looks like on the wire:

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Cookie: session_id=abc123xyz
User-Agent: Mozilla/5.0

Breaking it down:

• GET /api/users/42 HTTP/1.1 — the request line: method, path, HTTP version
• Host — which server to talk to (required in HTTP/1.1)
• Authorization — credentials, often a token
• Accept — what format the client wants back
• Cookie — session data the client sends with every request
• User-Agent — identifies the client software

For POST or PUT requests, there's also a body:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 45

{"name": "Alice", "email": "alice@example.com"}

HTTP Response Anatomy

The server responds with a status line, headers, and a body:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
Cache-Control: max-age=3600
Set-Cookie: session_id=newtoken; HttpOnly; Secure

{"id": 42, "name": "Alice", "email": "alice@example.com", "role": "admin"}

• HTTP/1.1 200 OK — protocol version and status
• Content-Type — tells the client how to parse the body
• Cache-Control — how long the client can cache this response
• Set-Cookie — the server setting a cookie in the browser
• The body — the actual payload (HTML, JSON, binary, etc.)

The Problem With HTTP

Here's the issue: everything above travels in plain text over the network.

Every router, every switch, every ISP in the path between you and the server can read it. The coffee shop WiFi owner can see it. Anyone on the same network running a packet sniffer can see it. That Authorization: Bearer ... header? Readable. That Cookie: session_id=abc123? Readable. Any form submission with a username and password? Completely visible.

This is called a man-in-the-middle attack. The attacker doesn't need to break anything — they just read the traffic as it flows past. With HTTP, that's trivially easy.

The attacker can also modify the traffic in transit. They can inject JavaScript into an HTML page, swap out a bank account number, or redirect a login form to their own server. The client and server have no way to detect it.

HTTPS

HTTPS is HTTP with a layer of encryption added underneath. The "S" stands for "Secure." The protocol used for that encryption layer is called TLS — Transport Layer Security (formerly known as SSL, which is why you'll still hear people say "SSL certificates").

From the application's perspective, HTTPS works exactly like HTTP. Same methods, same status codes, same headers. The difference is that before any HTTP data flows, the browser and server run a handshake to establish an encrypted channel. After that, every byte is encrypted. Nobody in the middle can read it.

An attacker intercepting HTTPS traffic sees garbled ciphertext — they can see that you connected to example.com (because DNS is often unencrypted and the initial connection reveals the domain), but they can't see what you sent or received.

TLS Handshake Overview

When your browser connects to an HTTPS site, the handshake happens before any application data is exchanged:

1. Client Hello — the browser sends a list of supported TLS versions and cipher suites (encryption algorithms).
2. Server Hello + Certificate — the server picks a cipher suite, sends its TLS certificate (which contains its public key and is signed by a Certificate Authority).
3. Certificate verification — the browser checks that the certificate is valid, hasn't expired, and is signed by a trusted CA.
4. Key exchange — both sides use the certificate's public key to establish a shared session key without transmitting it directly (using Diffie-Hellman or a similar mechanism).
5. Encrypted communication begins — all subsequent HTTP traffic is encrypted with that session key.

This handshake adds latency — typically one to two additional round trips before data flows. TLS 1.3 (the current version) reduced this to one round trip. HTTP/3 (over QUIC) can combine the TLS handshake and connection setup into zero additional round trips for connections to servers you've talked to before.

SSL Certificates

Every HTTPS site needs a certificate. The certificate serves two purposes: it contains the server's public key (used during the handshake), and it proves the server is who it claims to be.

That proof comes from a Certificate Authority (CA). CAs are organizations that browsers trust by default — DigiCert, Sectigo, GlobalSign, and notably Let's Encrypt. When a CA issues a certificate for example.com, they verify that the requester actually controls that domain, then cryptographically sign the certificate.

Your browser ships with a built-in list of trusted CAs. When it receives a certificate, it checks the signature chain: is this certificate signed by a CA I trust? This is called the chain of trust.

Let's Encrypt, launched in 2016, made certificates completely free and automated. Before that, certificates cost money and were manual to install. After Let's Encrypt, HTTPS adoption went from roughly 30% of web traffic to over 95% within a few years. Most hosting providers now issue certificates automatically.

Certificates have expiry dates — typically 90 days for Let's Encrypt. The certbot tool (and most hosting platforms) renew them automatically.

HTTP/2 and HTTP/3

HTTP didn't stop evolving at version 1.1. Two major upgrades exist:

HTTP/2 (2015) introduced multiplexing: multiple requests can be in-flight simultaneously over a single TCP connection. HTTP/1.1 allowed only one request at a time per connection (or used multiple connections as a workaround). HTTP/2 also compresses headers, which reduces overhead for sites with many small requests. HTTP/2 effectively requires HTTPS — all major browsers only support HTTP/2 over TLS.

HTTP/3 (2022) replaced TCP with a new transport protocol called QUIC. QUIC runs over UDP and builds its own reliability, ordering, and congestion control on top. The advantages: connection setup is faster (QUIC combines the TLS handshake with connection establishment), and packet loss in one stream doesn't block other streams (a TCP problem called head-of-line blocking). Major sites like YouTube, Google Search, and Cloudflare-served content already use HTTP/3.

Mixed Content

One subtle issue: an HTTPS page loading resources over HTTP. If your site is served over HTTPS but loads an image, script, or font over HTTP, that resource is unencrypted. An attacker can intercept and modify that script to run arbitrary code on your page — even if the page itself was delivered securely.

Browsers classify mixed content as a security violation. Active mixed content (scripts, iframes) is blocked outright. Passive mixed content (images) shows a warning. Modern browsers are increasingly strict — upgrading some mixed content automatically or blocking it entirely.

The fix is simple: ensure every URL on your page uses https://. For third-party resources, check whether the CDN or API you're calling supports HTTPS (nearly all do today).

Real-World Impact

Let's Encrypt's impact on the web was enormous. In 2014, only about 30% of page loads used HTTPS. By 2024, it's over 95% on Chrome. Free, automated certificates removed the last excuse not to encrypt.

For developers: if you're running anything on the web that handles user data, authentication, or any sensitive information — HTTPS is not optional. Most browsers now actively warn users when they land on HTTP pages. Search engines rank HTTPS sites higher. And practically speaking, HTTP/2 (with its performance improvements) requires it anyway.

Key Takeaways

• HTTP is a stateless request-response protocol; methods describe intent (GET, POST, PUT, DELETE), status codes describe outcomes (200, 404, 500)
• Plain HTTP sends everything in clear text — headers, cookies, request bodies, responses — readable by anyone in the path
• HTTPS is HTTP over TLS: an encrypted tunnel is established first, then HTTP runs inside it
• The TLS handshake verifies server identity via certificates signed by trusted Certificate Authorities
• Let's Encrypt made certificates free and automated, driving HTTPS adoption from 30% to 95%+ of web traffic
• HTTP/2 adds multiplexing over a single connection; HTTP/3 replaces TCP with QUIC for faster, more resilient connections

Next up: the transport layer underneath HTTP — how TCP and UDP actually move data across the network, and when you'd choose one over the other.