How Does HTTPS Work? TLS and SSL Explained
HTTPS encrypts traffic between your browser and a server using TLS. Learn how the TLS handshake works, what certificates do, how symmetric and asymmetric encryption are combined, and what the padlock in your browser actually means.
The one-sentence explanation
HTTPS is HTTP with a TLS layer underneath — it encrypts every request and response so that nobody between your browser and the server can read or tamper with the data.
HTTP vs HTTPS
Plain HTTP sends everything as readable text. Anyone on the same network — a coffee shop router, an ISP, a misconfigured proxy — can see the full request including headers, cookies, and body. HTTPS wraps the HTTP traffic in TLS (Transport Layer Security), which encrypts it end-to-end.
| HTTP | HTTPS | |
|---|---|---|
| Port | 80 | 443 |
| Encrypted | ✗ No | ✓ Yes |
| Tamper-proof | ✗ No | ✓ Yes |
| Server identity verified | ✗ No | ✓ Yes (via certificate) |
| Password safe in transit | ✗ No | ✓ Yes |
Two types of encryption working together
TLS uses two different styles of encryption — asymmetric at the start, symmetric for the actual data transfer.
Asymmetric encryption (key exchange)
Uses a public key and a private key. Data encrypted with the public key can only be decrypted with the private key. The server's certificate contains its public key — anyone can see it. The private key never leaves the server. This is used at the start of a connection to securely agree on a shared secret.
Symmetric encryption (data transfer)
Uses a single session key that both sides know. Much faster than asymmetric encryption — practical for encrypting megabytes of traffic. The session key is derived during the handshake and discarded afterwards.
The TLS handshake, step by step
Before any HTTP data is exchanged, the browser and server complete a handshake to establish a secure channel. With TLS 1.3 (the current version) this takes one round trip.
Client Hello
The browser sends the TLS versions it supports and a list of cipher suites (encryption algorithms it can use), plus a random value.
Server Hello
The server picks a cipher suite and TLS version, sends its certificate (containing its public key), and its own random value.
Certificate verification
The browser checks the certificate is valid, not expired, and signed by a trusted Certificate Authority. If anything is wrong, the browser shows a security warning.
Key exchange
Using the server's public key, both sides derive a shared session key without ever sending it directly across the network (via Diffie-Hellman key exchange).
Encrypted traffic begins
From this point on, all HTTP requests and responses are encrypted with the session key. The handshake is complete.
What certificates actually do
A TLS certificate does two things: it contains the server's public key, and it proves the server is who it claims to be. The proof comes from a Certificate Authority (CA)— a trusted organisation (like Let's Encrypt, DigiCert, or Sectigo) that has verified the domain owner controls the domain and has signed the certificate with their own private key.
Your browser ships with a list of trusted CAs built in. When it receives a certificate, it checks the CA's signature. If the signature is valid and the CA is trusted, the certificate is accepted.
SSL vs TLS — what's the difference?
SSL (Secure Sockets Layer) was the original protocol, developed in the 1990s. TLS (Transport Layer Security) is its successor and replacement — all SSL versions are now deprecated and considered insecure. When people say "SSL" today they almost always mean TLS. The term SSL persists because it became the common name before TLS replaced it. Certificates are still often called "SSL certificates" even though they are used with TLS.
| Version | Status |
|---|---|
| SSL 2.0 / 3.0 | ✗ Deprecated — do not use |
| TLS 1.0 / 1.1 | ✗ Deprecated — disabled by most browsers |
| TLS 1.2 | ⚠ Still supported, being phased out |
| TLS 1.3 | ✓ Current standard — faster and more secure |
What HTTPS does not protect against
- Malicious servers — HTTPS ensures the connection is encrypted and the certificate is valid, but not that the server is honest.
- Data once it arrives — if the server stores your data insecurely, HTTPS does not help.
- Malware on your device — if something intercepts traffic before it is encrypted (e.g. a compromised browser extension), HTTPS provides no protection.
- Metadata — the domain name you are connecting to is visible (via DNS and the SNI field in the TLS handshake), even over HTTPS. Only the path and content are hidden.
Related guides
Generate SHA-256 hashes instantly
SHA-256 is the hash algorithm at the heart of TLS certificate signatures
Open SHA-256 Tool →