What Is the Difference Between SSL, TLS and HTTPS?

If you've ever bought a certificate, read a hosting plan, or wondered what the padlock in your browser actually means, you've run into three terms that everyone seems to use interchangeably: SSL, TLS, and HTTPS. Articles mix them up. Hosting companies sell you "SSL" when they mean something else. It's genuinely confusing — and it wasn't always this messy.

Here's the short version, then the full story in plain English: SSL is a dead protocol from the 1990s. TLS is its living successor and the encryption that actually protects your site today. HTTPS is just regular web traffic (HTTP) running inside that TLS encryption. Nobody runs SSL anymore — but the name stuck around, which is where most of the confusion comes from.

The 30-Second Answer

If you remember only one thing: when anyone today says "SSL," they almost always mean TLS. The words got stuck in the 90s; the technology moved on.

What SSL Actually Was

SSL — Secure Sockets Layer — was developed by Netscape in the mid-1990s to do something the early web desperately needed: encrypt the connection between a browser and a server so passwords and credit card numbers couldn't be read by anyone listening in between. There were two public versions: SSL 2.0 and SSL 3.0.

Why SSL is dead and must stay off

Both SSL versions turned out to have serious cryptographic weaknesses. The most famous was the POODLE attack (2014), which let attackers decrypt supposedly secure SSL 3.0 connections. The industry response was total: SSL was formally deprecated, and every modern browser and server now refuses to speak it. Security standards are blunt about it — the OWASP TLS cheat sheet states that SSLv2 and SSLv3 "must always be disabled," and payment-card rules (PCI DSS) have forbidden them for years.

So: SSL is not an option you choose between. It's a retired protocol that belongs in a museum. If a server somewhere still accepts SSL connections, that's a security problem, not a feature.

What TLS Is (the Real Protocol Today)

TLS — Transport Layer Security — is what replaced SSL. Fun fact: when the industry standardized what would have been "SSL 3.1," it renamed the protocol to TLS 1.0 for political and technical reasons (the naming history is worth a read if you're curious). So TLS 1.0 was, in a real sense, SSL's direct continuation — just with a new name.

TLS has gone through several versions. Here's where each one stands:

TLS 1.0 and 1.1 — retired

Released in 1999 and 2006 respectively, these versions were formally deprecated by RFC 8996 in March 2021 and are now disabled in every major browser. They also relied on outdated cryptography (like SHA-1 and CBC-mode ciphers) that modern attacks can break. Like SSL, they should be switched off everywhere.

TLS 1.2 — still in use, in feature freeze

Released in 2008, TLS 1.2 is still extremely common — a huge share of the web's servers support it. It's fine if configured properly, because TLS 1.2 is flexible: it allows strong modern ciphers alongside older, weaker ones, so a badly configured server can still be insecure. As of July 2026, TLS 1.2 entered an official feature freeze (RFC 9851): it will only receive urgent security fixes from now on, and new developments like post-quantum cryptography are being built for TLS 1.3 and later only. Think of TLS 1.2 as a reliable older car — it still drives, but nobody's adding new features to it.

TLS 1.3 — the current standard

Finalized in 2018 (RFC 8446, with a minor revision in RFC 9846 in 2026), TLS 1.3 is the version everything is moving toward, and it's a genuine leap:

• Faster connections: the handshake takes one round trip instead of two, so pages start loading sooner.
• Stronger by default: weak ciphers, static RSA key exchange, and compression were all removed — there's no "bad configuration" option the way there was in TLS 1.2.
• Forward secrecy is mandatory: every session uses fresh, throwaway keys. Even if someone recorded all your encrypted traffic today and stole the server's private key five years from now, they couldn't decrypt those past sessions.
• More privacy: in TLS 1.2 the server's certificate was sent in the clear; in TLS 1.3 it's encrypted, so passive observers can't even see which certificate was presented.

If you're setting up anything new, TLS 1.3 is the target, with TLS 1.2 kept on for compatibility with older clients.

What HTTPS Is

HTTPS is simpler than people think: it's just HTTP carried inside a TLS connection. HTTP is the normal language of the web — the requests and responses your browser exchanges with a server. HTTPS wraps all of that inside TLS encryption, which gives the connection three properties:

1. Confidentiality — nobody in the middle can read the data.
2. Integrity — nobody can silently modify it in transit.
3. Authenticity — the server proves it really is who it claims to be, using a certificate.

That third point is what the padlock represents. When your browser shows the padlock, it has verified the site's certificate against a trusted authority and confirmed the connection is encrypted.

What the padlock does — and doesn't — prove

A common misconception: the padlock means a website is trustworthy. It doesn't. It means the connection is encrypted and the site proved ownership of its domain name to a certificate authority. A phishing site can absolutely have a valid certificate and a padlock — it just proves your conversation with the scammer is private. The padlock protects the pipe, not the person at the other end.

How SSL, TLS and HTTPS Fit Together

A simple analogy

Think of sending a letter:

• HTTP is the letter itself — the message, written in plain language anyone could read.
• TLS is the tamper-proof sealed envelope — it hides the contents and proves the letter wasn't opened in transit. (SSL would be the old, broken envelope design that thieves learned to open.)
• HTTPS is the act of mailing the letter inside that sealed envelope.

The handshake in plain English

Before any page loads over HTTPS, your browser and the server perform a quick negotiation called the handshake:

1. Agree on the rules: the browser says "I speak TLS 1.3 and 1.2, here are the ciphers I know." The server picks the strongest version and cipher they share.
2. Prove identity: the server sends its certificate. The browser checks that it chains to a trusted authority, matches the domain name, is within its validity dates, and hasn't been revoked. If any check fails, you get a warning.
3. Agree on keys: both sides derive the same secret session keys without ever sending them across the wire.
4. Encrypted browsing begins: from here on, every HTTP request and response travels inside the encrypted tunnel — that's HTTPS.

All of this happens in milliseconds, before the first byte of the actual page.

Why Everyone Still Says "SSL" (the Naming Mess)

If SSL has been dead for years, why does every hosting company, certificate seller, and tutorial still say "SSL certificate," "SSL error," and "enable SSL"?

Because the name never died — only the protocol did. "SSL" became the generic word for "website encryption" in the 90s and 2000s, and the industry never bothered to retrain everyone's vocabulary. Even the padlock-era documentation, browser error messages, and product pages kept the term. Technically minded people will say "TLS" and mean the current protocol; everyone else says "SSL" and means the same thing.

"SSL certificates" are really TLS certificates

The thing you buy or get for free (from Let's Encrypt, for example) and install on your server is technically an X.509 certificate used with TLS. Calling it an "SSL certificate" is like calling a modern car a "horseless carriage" — the name describes a bygone era, but everyone knows what you mean.

What to actually ask your host for

When shopping for hosting or talking to support, don't ask for "SSL." Ask:

• "Do you support TLS 1.2 and 1.3?"
• "Is HTTPS enabled by default, with a free certificate (e.g., Let's Encrypt) and auto-renewal?"
• "Are TLS 1.0, 1.1, and all SSL versions disabled?"

Those questions get you precise answers; "do you have SSL?" gets you a marketing answer.

Which Version Should Your Website Use?

The practical rule, matching current industry guidance (OWASP, Mozilla's server-side TLS recommendations):

• Enable TLS 1.3 — it's the modern default.
• Keep TLS 1.2 on — for compatibility with older devices and clients that don't speak 1.3 yet.
• Disable TLS 1.0, TLS 1.1, SSL 3.0, and SSL 2.0 — all deprecated and insecure.
• Use strong cipher suites (the AEAD family: AES-GCM or ChaCha20-Poly1305).

You don't need to hand-configure this on most modern hosting — any decent host or CDN applies a sane profile by default. But it's worth knowing, because a surprising number of misconfigured servers still allow old versions.

How to check what your site is running

The easiest free check is SSL Labs' SSL Test (ssllabs.com/ssltest): enter your domain and it grades your configuration from A+ to F, listing exactly which protocol versions and ciphers your server accepts. It's the standard tool the industry uses, and it takes about a minute.

Frequently Asked Questions

Is SSL the same as TLS?

Not exactly, but in everyday language, yes. SSL was the original protocol (1990s, now dead); TLS is its successor and what actually runs today. When someone says "SSL" in 2026, they mean TLS 99.9% of the time — the old name just stuck.

Is HTTPS more secure than HTTP?

Yes — enormously. HTTP sends everything in plain text: anyone on the same network (a café Wi-Fi, for example) can read it. HTTPS encrypts the connection with TLS, so the content is private and tamper-proof. There's no reason to run a public site on plain HTTP anymore.

Do I still need an "SSL certificate" if TLS replaced SSL?

Yes — you need the certificate, just not the old protocol. The certificate is what lets your server prove its identity during the TLS handshake. What you buy (or get free) is technically a TLS/X.509 certificate; "SSL certificate" is just the legacy name everyone still uses.

Which TLS version should I use in 2026?

TLS 1.3 as the primary, with TLS 1.2 enabled for compatibility. TLS 1.0 and 1.1 are deprecated (RFC 8996) and disabled in all modern browsers; all SSL versions must be off. TLS 1.2 is now in feature freeze (RFC 9851), so plan new deployments around 1.3.

Does the browser padlock mean a website is safe?

It means the connection is encrypted and the site verified its domain identity — not that the site itself is honest. Phishing sites can and do use valid certificates. The padlock protects your data in transit; your judgment still has to evaluate who you're dealing with.

Why do browsers show "Not Secure" instead of just breaking the connection?

Browsers warn rather than silently block because some sites (old intranets, local devices) legitimately run without HTTPS, and hard-blocking everything would break them. The "Not Secure" label is the compromise: it tells you the connection is unencrypted so you can decide whether to proceed — and you generally shouldn't enter passwords or payment details on such pages.

Comparing hosting for a new site? Check that TLS 1.2/1.3 and free auto-renewing certificates come standard — not as paid add-ons. Our guide to choosing a hosting plan walks through what to look for (and what to watch out for) beyond just the headline price.