HTTP vs HTTPS: How the Web Actually Communicates

When you log in on café Wi-Fi, what stops the person at the next table from reading your password?

Most of the time, the honest answer is HTTPS. Without it, your login request would travel across the network as readable text. This guide explains what HTTP is, why plain HTTP is risky, and how HTTPS fixes that, using a login request as the running example.

Key Takeaways

• HTTP is the agreed language browsers and servers use to exchange requests and responses
• Plain HTTP sends readable text, so anyone on the path can read or change it
• HTTPS is HTTP sent over TLS, which adds encryption, integrity checks, and server identity
• A certificate lets your browser confirm the server is the one it claims to be
• HTTPS does not hide the domain name, and a padlock does not prove a site is trustworthy

1. Why the Web Needs a Communication Protocol

Why: A browser and a web server are different machines, often run by different people, with no shared memory or shared context. To cooperate, they need a common language with agreed rules.

What: A protocol is that agreed set of rules. The web uses a client-server model: the client (usually your browser) sends a request, and the server sends back a response. This pattern is called the request-response cycle.

How: Each side knows what a valid message looks like, so neither has to guess what the other means.

Tradeoff: Shared rules make the web interoperable across many browsers and servers, but every rule also has to be designed, maintained, and secured.

2. What is HTTP?

Why: Browsing, APIs, and forms all need a single, predictable way to ask for resources and receive them.

What: HTTP (Hypertext Transfer Protocol) is an application-layer protocol for request-response exchanges. RFC 9110, the IETF standard that defines HTTP semantics, describes it as a stateless application-level protocol. It sits above the transport layer, where TCP normally carries it.

How: HTTP messages are human-readable text. Each request names a method and a target, and each response carries a status code. Because HTTP is stateless, each request is understood on its own, and the server does not keep a memory of earlier requests unless something else, such as a cookie or token, carries that context.

Tradeoff: Stateless design keeps servers simple and scalable. The cost is that applications must add state explicitly, through cookies, sessions, or tokens.

3. Anatomy of an HTTP Request and Response

Why: Knowing the parts of a message makes it easier to read traffic in DevTools and to debug problems.

What: A request has a request line (method, path, version), headers (such as Host, User-Agent, Content-Type, and Cookie), and an optional body. A response has a status line (version, status code, reason), headers, and a body.

How: Status codes come in families. 2xx means success, 3xx means redirection, 4xx means the client made an error, and 5xx means the server failed. RFC 9110 defines the meaning of each code in its status code section.

Tradeoff: Readable text helps humans and debugging tools, but it also means the content is visible to anyone who can see the traffic. That is the problem Section 5 covers.

4. HTTP Methods, State, and Everyday Use

Why: Different actions need different verbs, and the browser and servers rely on those meanings to decide what is safe to repeat.

What: The common methods are GET (retrieve), POST (submit data to be processed), PUT (replace a resource), PATCH (partially change a resource), and DELETE (remove a resource). RFC 9110 defines safe methods, which should not change server state, and idempotent methods, where repeating the request has the same effect as sending it once. GET is safe and idempotent. PUT and DELETE are idempotent but not safe.

How: For statefulness, servers use cookies, sessions, or tokens. Caching uses headers such as Cache-Control and ETag. Many REST APIs are simply HTTP methods applied to resources, such as GET /users/42 to read a user.

Tradeoff: Choosing the right method matters. Using GET to change data can cause repeated actions when a link is prefetched or retried, so keep GET read-only.

5. The Problem with Plain HTTP

Why: Imagine the login request again. On public Wi-Fi, every packet can pass through devices you do not control.

What: Plain HTTP has no encryption, so the data travels as readable text. That creates three specific risks: eavesdropping (someone reads the request), tampering (someone changes it in transit), and impersonation (someone pretends to be the server, a man-in-the-middle attack).

How: Here is what an attacker on the same network can see with plain HTTP:

The attacker does not need to break anything. The credentials are simply visible.

Tradeoff: Plain HTTP is simpler and has no certificate or encryption cost, which is why it survived for so long. Today, that simplicity is rarely worth the risk for anything private, and browsers warn users about it.

6. What is HTTPS?

Why: HTTP needs a way to protect data and to prove who the server is.

What: HTTPS is HTTP carried over TLS (Transport Layer Security). According to RFC 9110, the https scheme identifies a resource on a server that has been authenticated and whose HTTP communication has confidentiality and integrity protection. It is not a different application protocol. The HTTP messages are the same; they just travel through a secure channel. The default port is 443 for HTTPS and 80 for HTTP.

How: HTTPS provides three guarantees:

• Confidentiality: others cannot read the content
• Integrity: changes in transit can be detected
• Authentication: the browser can check the server’s identity

Tradeoff: HTTPS does not protect against everything. It does not hide the domain name from the network, it does not stop phishing sites that have valid certificates, and it does not fix bugs on the server.

7. How HTTPS Works: TLS Handshake and Certificates

Why: Encrypting data needs a shared secret, but two strangers cannot easily agree on one in public.

What: TLS uses two kinds of encryption. Asymmetric encryption uses a key pair: a public key anyone can see and a private key only the server holds. It is slower, so it is mainly used to prove identity and agree on a secret. Symmetric encryption uses one shared key for both sides. It is fast, so it protects the actual data after the handshake.

How: The TLS handshake runs before any HTTP request:

The server’s certificate contains its domain name, its public key, and a signature from a certificate authority (CA). Your browser trusts a list of root CAs. A root CA can sign an intermediate CA’s certificate, which can sign the site’s certificate. This chain is the chain of trust. If the chain is valid, the domain matches, and the certificate has not expired, the browser proceeds.

Common errors include an expired certificate, a mismatched domain name (the certificate is for another site), and an unknown issuer. Browsers show warnings for these because the identity check failed.

TLS 1.2 and TLS 1.3 are both in use. TLS 1.3 completes the handshake with fewer round trips than TLS 1.2. [verify exact round-trip counts before quoting them]

Tradeoff: The handshake adds time and CPU work, and it depends on trusting CAs. Compromised or misissued certificates are a real risk, which is why certificate management matters.

8. HTTP vs HTTPS: Side-by-Side Comparison

Why: You need to decide when each matters, and what each one costs.

What: The main differences are security, port and URL scheme, handshake overhead, and browser trust. HTTP uses http:// and port 80. HTTPS uses https:// and port 443.

How: Consider these points as a list, not a verdict:

• Security: HTTPS encrypts and authenticates. HTTP does neither.
• Performance: HTTPS adds a handshake, which costs some time on the first connection. Session resumption and newer TLS versions reduce this cost.
• Browser trust: Browsers mark plain HTTP pages as not secure, and some features such as service workers and geolocation require a secure context.
• Cost and certificates: HTTPS needs a certificate. Let’s Encrypt issues free, automated certificates.
• Mixed content: A secure page that loads images or scripts over plain HTTP can be blocked or flagged.

Tradeoff: HTTPS is now the standard for most public sites. HTTP still appears in local development and some internal systems, where the threat model is different.

9. Beyond the Basics: HTTP Versions and Hardening

Why: Protocol versions and server settings change how fast and how safely a site works.

What: HTTP/1.1 sends one request at a time per connection, so browsers open several connections in parallel. HTTP/2 multiplexes many requests on one connection. HTTP/3 runs over QUIC, which uses UDP. RFC 9110 notes that all three share the same semantics, and that they differ mainly in how messages are encoded and carried.

How: Hardening usually means:

• Redirecting HTTP to HTTPS with a 301 or 308 response
• Sending HSTS (HTTP Strict Transport Security), which tells browsers to use HTTPS only for that domain
• Setting Secure and HttpOnly flags on cookies
• Terminating TLS at a load balancer or CDN, then forwarding to the application server

curl -I http://example.com

This prints the response headers, so you can check whether the server redirects to HTTPS.

Tradeoff: HSTS is powerful but hard to undo quickly, so start with a short duration before a long one. Misconfigured redirects can also cause loops.

10. Real-World Usage and Choosing the Right Approach

Why: The right setup depends on what data flows through the site.

What: Login and payment pages must use HTTPS. Personal projects and student apps should use HTTPS too, since certificates are free and the setup is short. Internal tools and local development often use HTTP on a private network, but the risk is still real on shared networks. APIs and microservices may use mutual TLS (mTLS), where both sides present certificates.

How: A practical deployment checklist:

• Obtain a certificate (for example from Let’s Encrypt)
• Serve the site over HTTPS on port 443
• Redirect all HTTP traffic to HTTPS
• Enable HSTS once redirects work reliably
• Set secure cookie flags
• Check mixed content and certificate expiry

Tradeoff: Each step adds operational work, especially certificate renewal and redirect rules. Automating renewal removes most of that burden.

Next learning steps: web security basics, networking fundamentals, and DevOps practices for certificates and deployment.

Try It Yourself

Open your browser’s DevTools. In the Network tab, load a page and click the main request to see its headers and status code. In the Security tab, inspect the certificate, its issuer, and its validity dates. Compare what you see with the diagrams above.

Recap Checklist

• HTTP carries requests and responses in readable text
• Status codes group into 2xx, 3xx, 4xx, and 5xx
• Plain HTTP exposes data to eavesdropping, tampering, and impersonation
• HTTPS adds TLS for confidentiality, integrity, and authentication
• The handshake uses asymmetric encryption to agree on symmetric session keys
• Certificates form a chain of trust back to a root CA
• HTTPS does not hide the domain name or stop phishing

Interview Q&A

Q: Is HTTPS a different protocol from HTTP? A: No. It is HTTP carried over TLS, so the messages are the same and the channel is secured.

Q: Why use both symmetric and asymmetric encryption? A: Asymmetric encryption helps establish identity and agree on a secret. Symmetric encryption is faster for the data itself.

Q: What does a padlock guarantee? A: That the connection is encrypted and that the server proved control of the domain. It does not guarantee the site is honest.

Q: What is HTTP stateless? A: Each request is interpreted on its own. State is added with cookies, sessions, or tokens.

Q: Which port does HTTPS use by default? A: Port 443 by default; HTTP uses port 80.

FAQ

Does HTTPS hide which website I visit?

> Not fully. The domain name is still visible to the network in common cases, though the page path and content are encrypted.

Is a site with a padlock safe to use?

> The padlock means the connection is encrypted and the domain was verified. It does not mean the site is legitimate.

Why do browsers show “Not Secure” on HTTP pages?

> Because HTTP sends data without encryption or identity checks, so the browser warns users.

Is HTTPS slower?

> The handshake adds some delay on the first connection, but session reuse and newer TLS versions reduce the cost.

Do I need a paid certificate?

> Not necessarily. Free, automated certificates are available from Let’s Encrypt.

HTTP vs HTTPS: How the Web Actually Communicates was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.