What's the difference between HTTP and HTTPS?
HTTP (HyperText Transfer Protocol) is the protocol browsers and servers use to exchange requests and responses, but it sends everything in plain text. HTTPS (HTTP Secure) is the exact same protocol wrapped inside an encrypted connection (TLS), so anyone intercepting the traffic sees scrambled bytes instead of readable data. Same requests, same responses, same HTTP underneath. The difference is entirely about what happens to the data in transit.
That one-line answer is enough to pass a casual conversation, but not enough to actually understand what's protected, what isn't, and why the padlock icon exists in the first place. Let's go through it properly, with real request/response output at each step.
What Is HTTP?
HTTP is a request/response protocol: a client (usually a browser) sends a request for something (a page, an image, JSON from an API) and a server sends back a response. It's stateless by design, text-based, and has been the foundation of the web since 1991.
The problem: HTTP was designed for a web where nobody worried about someone reading the traffic in the middle. Every request, every response, every cookie, every form submission travels as plain, readable text across every network hop between the client and the server: your Wi-Fi router, your ISP, any network the packet passes through.
What Is HTTPS?
HTTPS is HTTP running inside a TLS (Transport Layer Security) connection. TLS is the modern successor to SSL (Secure Sockets Layer), which is why people still say "SSL certificate" even though actual SSL has been deprecated for years. TLS does three things: encrypts the data so eavesdroppers can't read it, verifies the server's identity via a certificate so you know you're actually talking to the real server, and detects tampering so a modified request or response gets rejected instead of silently accepted.
Crucially, HTTPS doesn't change HTTP itself. The same GET and POST requests, the same headers, the same status codes: they're just wrapped in an encrypted tunnel before they touch the network.
How an HTTP Request Actually Works
DNS Lookup
resolve the domain to an IP
TCP Connect
open a connection to the server
Send Request
GET /page HTTP/1.1
Get Response
200 OK + the page content
A Real HTTP Request and Response
Here's what actually travels across the network for a login form submission over plain HTTP, readable by anyone with access to any network hop in between:
The request
A POST request submitting a username and password, completely in plain text:
POST /login HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 29 username=john&password=hunter2
The response
The server's reply, including the session cookie that keeps you logged in, also in plain text:
HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: session=a1b2c3d4e5; Path=/ <html>Welcome, john</html>
Why HTTP Alone Is a Problem
That password, and that session cookie, traveled across the network exactly as shown above, as readable text. Anyone positioned on the network path (a compromised router, a malicious hotspot, an ISP, anyone on the same public Wi-Fi with basic packet-sniffing tools) can read the username, the password, and steal the session cookie to impersonate that logged-in user without ever needing the password at all.
This isn't a theoretical attack. It's the entire reason "don't log into anything important on public Wi-Fi" used to be common advice, and the reason that advice matters much less today is that most of the web finally moved to HTTPS.
What HTTPS Actually Adds
Run that exact same login request over HTTPS, and here's what a network observer sees instead: the request and response above, but after TLS encryption.
What travels across the network now
Encrypted bytes. No username, no password, no cookie value: none of it is readable without the session key, which only the client and server have.
17 03 03 00 a4 3f 8e 2c 91 6d 7a b3 0f 44 ... (TLS application data, opaque ciphertext, unreadable without the session key)
The TLS Handshake, Step by Step
Before any of that encrypted data flows, the client and server run a handshake to agree on encryption and verify identity. This happens once per connection, typically in one round trip on modern TLS versions, adding only a small amount of latency before the encrypted session begins:
Client Hello
supported ciphers + random value
Server Hello + Cert
picks a cipher, sends its certificate
Key Exchange
both sides derive a shared session key
Secure Channel
all further data is now encrypted
Common Mistakes Developers Make
- Mixed content: loading an HTTPS page that pulls in an image, script, or stylesheet over plain http://. Modern browsers block or warn on this, and it silently breaks pages that used to work.
- Not redirecting HTTP to HTTPS: leaving both accessible means anyone who types the plain http:// URL (or an old bookmark, or a link from years ago) gets the unencrypted version by default.
- Skipping HSTS: without a Strict-Transport-Security header, a user's very first request to your domain can still go out over HTTP before any redirect happens, leaving a brief window for interception.
- Assuming HTTPS means the site is secure: TLS only protects data in transit. It does nothing to stop SQL injection, XSS, weak passwords, or a vulnerable server. Those are separate problems that HTTPS was never designed to solve.
- Letting certificates expire in production: an expired certificate replaces the padlock with a full-page browser warning, which is exactly the kind of outage that's entirely preventable with automated renewal.
HTTP vs HTTPS, side by side
| Factor | HTTP | HTTPS |
|---|---|---|
| Default port | 80 | 443 |
| Data in transit | Plain text, readable | Encrypted, unreadable without the session key |
| Server identity verified | No | Yes, via certificate |
| Tamper detection | No | Yes |
| Browser indicator | "Not Secure" warning | Padlock icon |
| HTTP/2 and HTTP/3 support | Effectively no (browsers require TLS) | Yes |
| Google ranking signal | No | Small positive signal since 2014 |
| Protects against SQL injection / XSS | No | No, different problem entirely |
Why HTTPS Matters Beyond the Padlock
A few reasons HTTPS became effectively mandatory rather than optional, beyond just "it looks more trustworthy":
- Chrome has marked plain HTTP pages as "Not Secure" in the address bar since 2018: a visible warning on every single page load, not a one-time notice.
- HTTP/2 and HTTP/3, which meaningfully speed up page loads, are only supported by browsers over an encrypted connection, so sites stuck on HTTP can't use them at all.
- Google has used HTTPS as a (small) ranking signal since 2014.
- Free, automated certificates (Let's Encrypt, since 2016) removed the cost and manual-renewal excuse that used to make HTTPS a real burden for small sites.
Interview Questions
Questions that come up in real interviews on this topic, with full explanations rather than one-line definitions.
What's the fundamental difference between HTTP and HTTPS?
HTTPS is HTTP run inside a TLS-encrypted connection. The HTTP requests and responses themselves (methods, headers, status codes) are identical. What changes is that TLS encrypts the data in transit, verifies the server's identity via a certificate, and detects tampering, none of which plain HTTP does at all.
What does TLS actually protect against, and what does it NOT protect against?
TLS protects against eavesdropping (reading the data in transit), tampering (modifying it in transit undetected), and impersonation (a fake server pretending to be the real one). It does not protect against vulnerabilities in the application itself: SQL injection, XSS, weak authentication, a compromised server, or a user who gets phished into giving up their password on a legitimate HTTPS page. HTTPS secures the pipe, not what's built on either end of it.
Walk through what happens during a TLS handshake.
The client sends a "Client Hello" with the TLS versions and cipher suites it supports plus a random value. The server responds with a "Server Hello" picking a cipher, sends its certificate (proving its identity, signed by a trusted certificate authority), and its own random value. Both sides then use a key exchange algorithm (typically ECDHE today) to independently derive the same shared session key without ever sending that key itself over the network. Once both sides confirm they've derived matching keys, every subsequent message is encrypted with that session key.
Why do browsers show "Not Secure" for HTTP sites now but didn't always?
Historically browsers only flagged HTTPS problems (like an invalid certificate) and stayed neutral about plain HTTP. As HTTPS adoption grew and free certificates removed the main excuse not to use it, Chrome (starting in 2018) flipped the default: plain HTTP is now treated as the risky, worth-flagging case, shown as "Not Secure" directly in the address bar on every page load.
What's the difference between encryption and authentication in the context of HTTPS?
They're two separate guarantees bundled into one handshake. Encryption means the data can't be read by anyone intercepting it. Authentication (via the server's certificate, signed by a trusted certificate authority) means you can verify you're actually talking to the real example.com and not an attacker impersonating it. A connection could theoretically have one without the other: encryption without verifying who's on the other end wouldn't stop an attacker from just presenting their own valid certificate for a lookalike domain.
If HTTPS encrypts everything, why can an ISP still see which website you're visiting?
During the TLS handshake, the client sends the hostname it's connecting to in a field called SNI (Server Name Indication), and in most current deployments, that field is sent unencrypted, since the server needs it before the encrypted session exists to know which certificate to present. So an ISP can typically see the domain (example.com) but not the specific page, query parameters, or any content. Newer extensions like ECH (Encrypted Client Hello) aim to close this gap, but they aren't universally deployed yet.
Does HTTPS alone make a website secure?
No, and this is a common misconception worth correcting directly in an interview. HTTPS secures data in transit between the client and server. It says nothing about whether the server's code has a SQL injection vulnerability, whether passwords are hashed properly, whether the application is vulnerable to XSS, or whether the server itself is patched and configured correctly. A site can be fully HTTPS and still be completely insecure at the application layer.
The short version
HTTP and HTTPS carry the exact same requests and responses: the same methods, headers, and status codes. The difference is everything that happens to that data in transit: HTTPS wraps it in TLS, which encrypts it, verifies the server's identity, and detects tampering, none of which HTTP does on its own.
It's also worth being precise about what HTTPS doesn't do: it protects the connection, not the application. A vulnerable server is still vulnerable over HTTPS. TLS was never meant to solve that problem, and treating the padlock icon as a general security guarantee is exactly the kind of gap that shows up in a real security review.