How HTTPS actually works, step by step

HTTPS is HTTP (the protocol that fetches web pages) wrapped in TLS encryption. Before your browser requests a single piece of a webpage, it and the server perform a 'handshake' — a brief negotiation that sets up a secure, encrypted channel for everything that follows.

During that handshake, the browser and server agree on which encryption method to use, the server presents its certificate to prove its identity, and both sides generate a shared secret key used to encrypt the rest of the session — all of this typically happens in a fraction of a second, well before a page starts rendering.

Once the secure channel is established, the actual HTTP conversation happens exactly as it always did: the browser requests a page, the server responds with HTML, CSS, JavaScript and data — but every byte is now encrypted in transit. Beyond the page content, the server's response also includes HTTP headers, like `Strict-Transport-Security` (which tells browsers to always use HTTPS for this site) and `Content-Security-Policy` (which restricts what a page is allowed to load), both worth inspecting with a header checker when auditing a site's security posture.

The practical upshot: HTTPS protects data in transit between you and the server, but it says nothing about what the server does with your data once it arrives, or whether the server itself is trustworthy — those are separate concerns HTTPS was never designed to solve.