Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningThe short answerHTTPS is HTTP sent inside an encrypted TLS connection, so machines between you and the website cannot read or change what you send, and the browser can check it is talking to the real site; plain HTTP sends everything as readable text, so use HTTPS for every site, always.
Hypertext Transfer Protocol
the postcard
HTTP over TLS (Transport Layer Security)
the sealed, signed envelope
Read across a row to compare one thing. Every word that may be new is explained just below the table.
| Aspect | HTTP | HTTPS |
|---|---|---|
| What travels on the wire | Readable text. Our wiretap saw POST /login and the password. | Encrypted TLS records. Our wiretap saw neither. |
| Can someone on the path change it? | Yes, silently: inject ads, scripts or a fake login form. | No. Any change breaks the encryption check and the connection fails. |
| Proof of the server's identity | None. | A certificate for the domain, checked by the browser. curl refused our self-signed one. |
| Default port | 80 | 443 |
| Extra setup cost | None. | A TLS handshake per new connection. TLS 1.3 needs one round trip. Ours: 0.82 ms of computing on one machine. |
| What still leaks | Everything. | The site name (via SNI and DNS), the server's IP address, sizes and timing. Not the path, headers or body. |
| Browser label | "Not secure" in Chrome since version 68 (July 2018). | No warning. A padlock or site-info icon. |
| Search ranking | No boost. | Google announced HTTPS as a ranking signal in August 2014. |
| Defined in | RFC 9110 (June 2022), the http URI scheme. | RFC 9110 for the https scheme, RFC 8446 (August 2018) for TLS 1.3. |
Real situations, and the pick we would make in each one.
Over HTTP our wiretap read the password in plain text. Over HTTPS it could not.
Without HTTPS anyone on the path can change the page, for example add a script. Browsers also mark it "Not secure".
API tokens are passwords too, and phones join public Wi-Fi all day. That is exactly the wiretap in our lab.
Traffic to 127.0.0.1 never leaves the machine, so plain HTTP is fine for quick tests. Use HTTPS once it is reachable from a network.
Keep listening on port 80 only to redirect visitors to the HTTPS address. Serve nothing else over HTTP.
Internal networks are not automatically safe. Many teams now encrypt service-to-service traffic too, often with mutual TLS.
we ran this, here is what happened
Most pages say HTTP is "not secure". We wanted to show what that means in bytes.
We ran one small Python web server twice on one laptop: plain HTTP on one port, and HTTPS with a self-signed certificate on another. Then we sent the same login form, user=asha&password=hunter2, with curl -v and recorded what each side printed.
To see what a machine on the path sees, we placed a relay between curl and the server that writes down every byte the client sends. That is all a cafe Wi-Fi router or a network provider receives. We could not use tcpdump, because it needs admin rights on macOS. Finally we timed 20 fresh connections each way.
Where it ran: Apple M4, macOS 15.6, curl 8.7.1, OpenSSL 3.6.3 for the certificate, Python 3.13.15 http.server and ssl. Everything on 127.0.0.1. Two full runs on 4 October 2026.
openssl req -x509 -newkey rsa:2048 -nodes -days 1 -subj "/CN=localhost" \
-addext "subjectAltName=DNS:localhost" -keyout "$D/key.pem" -out "$D/cert.pem" 2>/dev/null
python3 http_vs_https_lab.py relay 9780 8780 "$D/wire-http.bin" & PIDS+=($!)
python3 http_vs_https_lab.py relay 9743 8743 "$D/wire-https.bin" & PIDS+=($!)
curl -s -o /dev/null -d "$BODY" --connect-to localhost:8780:127.0.0.1:9780 http://localhost:8780/login
curl -s -o /dev/null --cacert "$D/cert.pem" -d "$BODY" --connect-to localhost:8743:127.0.0.1:9743 https://localhost:8743/login
for w in http https; do
f="$D/wire-$w.bin"
echo "--- $w: $(wc -c <"$f" | tr -d ' ') bytes captured"
printf 'contains "hunter2": '; grep -q hunter2 "$f" && echo YES || echo no$ curl -sS -d 'user=asha&password=hunter2' https://localhost:8743/login
curl: (60) SSL certificate problem: self signed certificate
$ curl -sv -4 --cacert cert.pem -d 'user=asha&password=hunter2' https://localhost:8743/login
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* subjectAltName: host "localhost" matched cert's "localhost"
* SSL certificate verify ok.
> POST /login HTTP/1.1
< HTTP/1.0 200 OK
{"login": "ok"}
medians, in milliseconds:
http connect 0.176 tls_handshake 0.000 total 0.343
https connect 0.206 tls_handshake 0.817 total 1.229
--- http: 178 bytes captured
contains "hunter2": YES
contains "/login": YES
contains "localhost": YES
--- https: 599 bytes captured
contains "hunter2": no
contains "/login": no
contains "localhost": YES| What we measured | HTTP | HTTPS |
|---|---|---|
| Password visible to the wiretapgrep for hunter2 in the captured bytes | yes, as plain text | no |
| URL path (/login) visiblethe path is inside the encrypted request | yes | no |
| Site name visiblesent before encryption, in the TLS hello (SNI) | yes | yes |
| Median time per new connection (2 runs)the TLS handshake took about 0.82 ms | 0.34 to 0.36 ms | 1.23 to 1.24 ms |
| Self-signed certificate, not trustedthe identity check works | no check at all | refused (curl error 60) |
What this shows
Over HTTP, the wiretap held our password in readable text after one request. Over HTTPS it held 599 bytes of noise, apart from the site name, which TLS sends in the clear so the server knows which certificate to show. The price was about 0.8 milliseconds of computing per new connection on this laptop. That is the whole trade, and it is not close.
What this test does not show: One machine, so there is no real network delay. On a real link the handshake also costs a round trip: with TLS 1.3 that is one extra trip before the first request, and resumed connections can skip most of it. A self-signed certificate stands in for a real one; the encryption is the same. The script is scripts/labs/compare/http_vs_https.sh in our repository.
"My site has no logins, so HTTP is fine."
Anyone on the path can still change the page, add scripts or swap download links. HTTPS also stops that, not just snooping.
"HTTPS hides which sites I visit."
It hides the path and content, not the site name. Our wiretap still found localhost in the HTTPS bytes, because SNI is sent before encryption starts.
"HTTPS is too slow."
Our handshake cost 0.82 ms of computing. On a real network add one round trip per new connection with TLS 1.3, and keep-alive connections reuse it for many requests.
Turning off certificate checks (curl -k, verify=False) to make an error go away.
That keeps the encryption but drops the proof of who you are talking to, so an attacker can sit in the middle. Fix the certificate instead.
Serving the page over HTTPS but loading scripts over HTTP.
Browsers block or warn about this "mixed content", and a single HTTP script can be replaced to take over the page. Load everything over HTTPS.
HTTPS, in every case that faces a network. It is the same HTTP inside encryption, so people on the path cannot read or change it, and the browser can check the site's certificate. Our test cost about 0.8 ms per new connection for that.
Because it travels as plain text. In our lab a simple relay saw the full request, including the password hunter2, after one login. Anyone running a Wi-Fi network or a router on the path can do the same, and can change the page on its way back.
Some old or internal sites do. Most public sites still listen on port 80, but only to redirect visitors to the HTTPS address. Chrome has marked every HTTP page "Not secure" since Chrome 68 in July 2018.
HTTP itself did not change; sites added TLS around it. Free certificates, browser warnings from 2018 and Google's 2014 announcement that HTTPS is a ranking signal pushed most of the web to switch.
Not quite. TLS (the newer name for SSL) is the encryption layer. HTTPS is HTTP running on top of TLS. Our curl run used TLS 1.3, defined in RFC 8446.
They can usually see the site names (through SNI and DNS) and how much data moves, but not the pages, paths, searches or passwords. A device your employer controls is different: it can be set up to inspect traffic.
From the System Design course, in the order we would read them.
Primary sources only: standards, vendor docs and our own runs. Each one shows its date and the day we opened it.
HTTP vs HTTPS is one row in a much bigger table. Our System Design course has 770 lessons on networks, databases, caching, scaling, messaging, security and reliability, each drawn step by step, so you can explain the trade-off in an interview and pick right at work. 18 lessons are free to read, with no card needed.
the hands-on parts are real runs, like this one
course 1
From absolute beginner to principal engineer, drawn step by step.