HTTP vs HTTPS: What Actually Changes When You Add the S
What the S Stands For
The S in HTTPS stands for TLS — Transport Layer Security, the successor to the older SSL protocol. When you connect to a website over plain HTTP, every byte of the request and response travels in the clear. That includes the URL you requested, the cookies your browser sends, and the full content of the page coming back. Anyone between you and the server — your ISP, a coffee-shop Wi-Fi operator, a compromised router — can read all of it.
HTTPS wraps that same HTTP exchange inside a TLS tunnel. The two ends negotiate a shared secret using public-key cryptography, then encrypt everything that follows. An observer on the network can still see that you connected to a particular server (the DNS lookup and server IP are visible), but they cannot read the specific path, the headers, the cookies, or the response body.
What TLS Actually Gives You
TLS provides three guarantees bundled together: confidentiality, integrity, and authentication. Confidentiality means the content is unreadable to intermediaries. Integrity means the content cannot be tampered with in flight without the browser detecting it. Authentication means the server has proved it controls the domain you typed, via a certificate issued by a trusted authority.
That last piece is what the padlock in the address bar really denotes — not that a site is safe, but that the connection is genuinely to the named domain. HTTPS does not make a malicious site honest; it makes eavesdropping and substitution much harder. It also matters for more than passwords: it protects reading material, search queries, and anything else that would be embarrassing or risky to expose to the network.
The Edge Review publishes plain-English explainers. This is an overview, not a deployment guide; production TLS setup involves certificate authorities, configuration, and ongoing rotation specific to your stack.