# What Is HTTPS? How It Works and Why It Matters > A clear explainer on HTTPS: what it is and how it differs from HTTP, how TLS encrypts data in transit, the role of certificates and certificate authorities, what the padlock does and does not prove, HSTS and the move to HTTPS-everywhere, mixed content, and why HTTPS matters for both privacy and integrity. Source: https://playciso.com/blog/what-is-https · Published: 2026-10-23 · Publisher: PlayCISO (https://playciso.com) --- HTTPS is ordinary web traffic (HTTP) carried inside an encrypted, authenticated TLS connection, so that what passes between your browser and a website cannot be read or altered by anyone on the network in between. It is the difference between sending a postcard and sending a sealed, tamper-evident letter from a verified sender. ## HTTP versus HTTPS Plain **HTTP** sends everything as readable text: the pages you request, the data you type into forms, your passwords, your session cookies. Anyone who can see the network path — someone on the same public Wi-Fi, a compromised router, an internet provider, an attacker positioned in the middle — can read all of it, and can also change it before it reaches you. There is no protection at all. **HTTPS** carries that identical HTTP traffic inside TLS (Transport Layer Security). The visible signs are the "https://" scheme and a padlock, but underneath, TLS adds three guarantees: **confidentiality** (an eavesdropper sees only ciphertext), **integrity** (any tampering in transit is detected and rejected), and **authentication** (a certificate proves the server is who it claims to be). The absence of those three is exactly what makes HTTP dangerous, and their presence is the whole point of HTTPS. ## How TLS encrypts the connection When your browser opens an HTTPS connection, the two sides perform a TLS handshake. At a high level, they use asymmetric cryptography and a key-exchange to authenticate the server and agree on a shared secret without ever sending that secret in the clear, then derive a fast **symmetric** session key from it and use that to encrypt the rest of the conversation. This hybrid approach gets the trust and key-distribution benefits of public-key cryptography to set up the session, and the speed of symmetric encryption to carry the data. If you want the underlying mechanics, our [cryptography explainer](/blog/cryptography-explained-for-security-teams) walks through symmetric keys, asymmetric keys and the handshake in more detail. The practical consequence is that HTTPS directly defeats the classic network attack where someone sits between you and the server. Without encryption and server authentication, a [man-in-the-middle attacker](/blog/man-in-the-middle-attack-explained) can silently read and rewrite traffic; with properly validated TLS, they can do neither, because they cannot decrypt the data and cannot present a certificate your browser trusts. ## Certificates and certificate authorities Server authentication rests on **certificates**. A TLS certificate binds a domain name to a public key and is signed by a **certificate authority (CA)** — an organization that browsers and operating systems are configured to trust. Before issuing a certificate, the CA checks that the requester actually controls the domain; it then signs the certificate with its own key. Your browser accepts the certificate because it chains up through intermediates to a trusted root CA already in its trust store, and because the name on it matches the site you asked for and it has not expired. This is also why browser warnings matter. An expired certificate, a self-signed one, a certificate for the wrong domain, or one from an untrusted CA all break the chain of trust, and the browser stops you precisely because it can no longer prove who is on the other end. ## What the padlock does and does not mean The padlock is widely misunderstood. It means the connection is encrypted and the certificate is valid for that domain. It does _not_ mean the site is honest, reputable or malware-free. Domain-validated certificates are free and easy to obtain, so attackers put valid certificates on their phishing and scam sites as a matter of routine. A padlock on a fraudulent page is completely normal. Read the padlock as "nobody is eavesdropping on this connection," never as "this organization is trustworthy." Judging the organization itself is a separate question — the kind of thing a [reputation check](/tools/reputation-checker) is better suited to. ## HTTPS everywhere, HSTS and mixed content Modern practice is HTTPS for everything, not just login and checkout pages. Three pieces make that robust: - Redirect HTTP to HTTPS. Every plain-HTTP request should be redirected to its HTTPS equivalent so there is no usable cleartext version of the site. - Enforce HSTS. The HTTP Strict Transport Security header tells browsers to only ever use HTTPS for your domain for a set duration, so they refuse to downgrade even if a link or an attacker tries to force HTTP. This closes the small window where that very first request could be intercepted. - Eliminate mixed content. If an HTTPS page pulls in scripts, stylesheets or images over plain HTTP, those insecure resources can be intercepted and can compromise the whole page, so browsers block or warn on them. Every resource a secure page loads must itself be served over HTTPS. ## Why it matters Without HTTPS, credentials and session cookies can be stolen on any shared or hostile network, and pages can be silently rewritten to inject content or malware. With it, the connection is private, tamper-evident and tied to a verified server identity. That is why HTTPS is now effectively mandatory for any site, and why browsers mark plain HTTP as "not secure." If you are building or reviewing web services, enforcing HTTPS end to end is one of the cheapest, highest-leverage controls you have. ## Frequently asked questions **What is HTTPS?** HTTP carried over an encrypted, authenticated TLS connection, providing confidentiality, integrity and server authentication for web traffic. **How is it different from HTTP?** HTTP sends everything as readable text that anyone on the path can see or alter; HTTPS encrypts the same traffic and proves the server identity with a certificate. **What is a certificate and who issues it?** A signed document binding a domain to a public key, issued by a certificate authority after verifying the requester controls the domain and trusted via a chain to a root CA. **Does the padlock mean a site is safe?** No. It means the connection is encrypted and the certificate is valid. Attackers get valid certificates too, so it is not a trust signal about the organization. **What are HSTS and mixed content?** HSTS forces browsers to use only HTTPS for a domain; mixed content is a secure page loading insecure HTTP resources, which browsers block or warn on.