What 'end-to-end encrypted' actually means (and what it doesn't cover)

"End-to-end encrypted" is the phrase the messaging industry settled on a decade ago, and it has been doing a lot of work ever since. It is on the splash screen of WhatsApp every time you open a new chat. It is the headline feature of Signal, the marketing pitch of ProtonMail, the thing Apple keeps adding asterisks to about iCloud. It is also, for most people who repeat it, a phrase whose actual scope they have never had a reason to think about carefully.

The short version is that end-to-end encryption protects the contents of a message from the network the message travels over and from the server that relays it. That is a real and important protection, and it has changed the threat model for ordinary conversations in a way the world has not fully absorbed. It is also a smaller envelope than the phrase implies. It does not cover the metadata around the message. It does not cover the backups of the message on either end. It does not cover the screenshot the other person takes, the notification preview that surfaced on a lock screen, the device that gets unlocked under duress, or the cloud sync that quietly copied the conversation somewhere else.

This piece walks through what end-to-end encryption (E2EE) actually is in plain language, what each of the big messaging apps - Signal, WhatsApp, iMessage, Telegram - actually does behind the marketing, and the practical gaps that determine whether your conversation is really private or just feels that way.

What end-to-end encryption is, in one section

Imagine you write a letter, put it in a tamper-evident envelope, and hand it to a courier. The courier carries it across the country to the recipient, who opens the envelope and reads it. The courier could lose the envelope, could be compelled by a court order to hand it over, could even photograph the outside of it - but the courier cannot read the letter without breaking the seal, and you would know if they did. End-to-end encryption is the digital version of that envelope. The cryptography is set up so that only your device and the recipient's device hold the keys to decrypt the contents. The server in the middle - the courier - relays the encrypted bytes without ever seeing what is inside.

Contrast this with the older model, sometimes called encryption-in-transit or "server-side encryption". The message is encrypted between your phone and the messaging company's server, the server decrypts it (reads it, scans it, indexes it, stores it, re-encrypts it for delivery), and then sends it onward. Every website you visit over HTTPS uses encryption-in-transit. Most email between most providers uses encryption-in-transit. Default Telegram chats use encryption-in-transit. The server can read everything. That is not a defect in HTTPS; HTTPS was designed to protect against the public Wi-Fi snooping it does protect against. It is just a different scope than E2EE.

The two big practical consequences of moving from encryption-in-transit to end-to-end:

• A breach of the server stops leaking message contents. The Yahoo Mail breach of 2013-14 leaked the contents of three billion accounts because Yahoo's servers held the plaintext. If Signal's servers were breached tomorrow, attackers would get a list of phone-number hashes and approximately nothing else - the messages are not on the server in any readable form.
• A court order to the messaging company stops producing contents. The company can still be compelled to hand over what it has (account-creation date, IP logs, social graph), but it cannot hand over the messages because it does not have them. Signal's transparency reports are the cleanest demonstration: the response to a typical subpoena is two timestamps.

Those are real, large changes. They are also the entire scope of what the phrase "end-to-end encrypted" promises. Everything else in this article is about what falls outside it.

Signal: the smallest envelope, and the smallest amount of stuff outside it

Signal is the reference implementation of modern E2EE. The Signal Protocol - the underlying cryptography, which combines the Extended Triple Diffie-Hellman handshake with the Double Ratchet for forward-secret message chains - has been open-source and peer-reviewed since 2013, and is the same protocol WhatsApp licensed in 2014, Google adopted for RCS messages in Android Messages, and Meta is rolling out across Messenger and Instagram DMs. When cryptographers talk about "the Signal Protocol", they mean a specific, scrutinized, mathematically analyzed thing, not a vague marketing claim.

What sets Signal apart from the apps that use the same protocol is what sits around it. Signal's servers store the minimum necessary to deliver a message: a phone-number hash, the date the account was created, and the last time the account connected to fetch messages. There is no address book stored server-side (contact discovery is done in a way that keeps your contacts on the device), no profile graph, no group-membership database, no advertising stack. Signal's responses to grand-jury subpoenas - which the Signal Foundation publishes in full - have been consistent for years: account-creation timestamp, last-connection timestamp, nothing else.

Signal also encrypts the things that adjacent E2EE apps tend to leave in cleartext: profile names, profile photos, group titles, and group membership are all encrypted on the server, so Signal itself cannot read them. Group calls and one-to-one calls are encrypted with the same key material. Disappearing messages are implemented consistently across devices.

The trade-offs are real. Signal requires a phone number to sign up (the foundation is working on usernames, which exist now as an alternative discovery handle, but the phone-number tie still exists underneath). It has fewer features than WhatsApp - no Stories of the WhatsApp scale, no business messaging ecosystem, no rich integration with the rest of your phone's apps. And the network effect is smaller, which is the real reason most people who would benefit from Signal end up on WhatsApp anyway: their family is on WhatsApp.

WhatsApp: same protocol, much bigger envelope, much more outside it

WhatsApp uses the Signal Protocol for message contents. That part of the marketing is honest. Meta cannot read the body of a WhatsApp message any more than the Signal Foundation can read the body of a Signal message. The difference is everything else.

WhatsApp's servers see and retain a great deal of metadata. Who you message, when, how often, from which IP address, on which device, which groups you belong to, who is in those groups, and how the social graph of your contacts overlaps with the social graph of Facebook and Instagram accounts (because Meta is the same company). That metadata is the part advertisers, regulators, and law enforcement care about most, and it is fully readable to Meta in a way that Signal's equivalent is not. Meta's response to law enforcement requests routinely includes message timestamps, IP addresses, device identifiers, and the full contact graph. The contents are not in there. Everything else is.

The bigger gap is backups. For most of WhatsApp's history, the backup that WhatsApp pushed users to enable - iCloud on iPhone, Google Drive on Android - was not end-to-end encrypted. The plaintext messages were copied out of the E2EE envelope, encrypted only with keys that Apple or Google held, and stored in the respective cloud. If you used WhatsApp through 2020 and turned on backups, your messages are sitting in a form Apple or Google can decrypt. WhatsApp added an end-to-end encrypted backup option in October 2021, but it is opt-in - you have to go into Settings and turn it on, and pick either a 64-character key or a password you will not forget. If the person you are messaging has not done the same, the conversation lives on their cloud in a form Apple or Google can read. Either end of the conversation breaks the encryption story for both ends.

Then there are the Meta business additions. WhatsApp Business accounts can route messages through third-party providers (Twilio, Zendesk, etc.) on the business side; the encryption from your phone terminates at whichever provider the business uses. WhatsApp also introduced "Communities" and richer group features, expanded group sizes, and a Channels broadcast product, each of which has its own privacy posture worth understanding before assuming the chat-thread defaults apply.

For most people, the practical takeaway is: WhatsApp is fine for the conversations you would have on a phone call. It is not Signal. If you would not want Meta to see the metadata, you should be on Signal. If you would not want either Apple or Google to potentially be served the contents under a warrant against a backup, both ends of the conversation need to have turned on encrypted backups.

iMessage: end-to-end, with an iCloud-shaped hole that Apple now lets you patch

iMessage between two Apple devices has been end-to-end encrypted in transit since the product launched in 2011. Apple cannot read a message moving from one iPhone to another. The cryptography is Apple's own design rather than the Signal Protocol, but it has been independently analyzed and is, by all public accounts, sound.

The asterisk - the one that has caused most of the confusion - is iCloud Backup. Until December 2022, iCloud Backup stored a copy of your iMessage history alongside an encryption key that Apple held. Apple's official policy was that the company could be compelled by a valid warrant to hand over a decrypted copy of the backup, and the FBI's various battles with Apple over the years (notably the San Bernardino case in 2016) turned on exactly this: the device itself was hard to crack, but a backup of the device sitting in iCloud was retrievable. The Messages-in-iCloud feature added in 2018 changed the storage model but did not close the warrant gap, because the key protecting Messages-in-iCloud was itself stored in the iCloud Backup.

Apple's Advanced Data Protection (ADP), launched at the end of 2022 in the US and rolled out globally through 2023, finally closes that gap. Turning ADP on makes iCloud Backup, Messages-in-iCloud, iCloud Photos, Notes, and several other categories end-to-end encrypted, with the keys held only on your devices. Apple cannot read the backup; Apple cannot recover the backup if you lose the keys. The trade-off is exactly that: you take on the recovery responsibility (set up recovery contacts, write down the recovery key, do not lose all your devices simultaneously).

Two things follow. First, ADP is opt-in and the world default is still off - which means most iMessage conversations still have a readable-by-warrant copy in one or both participants' iCloud Backups. Second, the encryption story is only as strong as the weaker end: if you have ADP on but your conversation partner does not, their iCloud Backup still holds the readable copy.

Two more iMessage-specific gaps worth naming. The green-bubble SMS fallback is not encrypted at all - it is plain text over the cellular network, readable by the carrier. And the new RCS-over-iMessage rollout (iOS 18 introduced RCS support so iPhones can use rich features when messaging Android users) was, at launch, not end-to-end encrypted; Google's RCS implementation in Messages is, but the cross-platform interop is the part that has been catching up. Check the bubble color and the lock icon, not the rich features, to know whether a message is actually encrypted end-to-end.

Telegram: mostly not end-to-end encrypted, despite the reputation

Telegram is the most consistently misunderstood app in this list. Its public reputation - among journalists, activists, and a lot of otherwise careful people - is of a secure, encrypted messenger. Its actual behavior is that the default chats, the group chats, the channels, and the cloud-synced multi-device experience are not end-to-end encrypted. They are encrypted in transit between your device and Telegram's servers, the servers hold a copy in a form Telegram can read, and that is how the cloud sync works in the first place - your messages have to be on the server in plaintext (or in a form Telegram can decrypt) for the server to be able to ship them to a new device when you log in.

Telegram does offer end-to-end encrypted chats, branded as "Secret Chats". They have several limitations. They are off by default - you have to explicitly start a Secret Chat. They only work in one-to-one conversations; group chats cannot be Secret Chats. They only work between two specific devices; you cannot access a Secret Chat from a second device, even your own. And the protocol they use, MTProto (Telegram's in-house design), has been flagged by independent cryptographers over the years for unusual choices that have not been peer-reviewed to the same standard as the Signal Protocol. None of those flags have turned into a practical break that has been publicly demonstrated, but cryptographers prefer "well-analyzed and boring" to "novel and clever", and Signal Protocol is the former.

For most users in most situations, Telegram should be treated as a cloud chat product comparable to Discord or Slack - useful, fast, feature-rich, and visible to the company running it. The end-to-end-encrypted feature exists but is not what is happening in the conversation by default.

The metadata problem, in concrete terms

Even when the body of every message is end-to-end encrypted, the information around the messages tells a great deal of the story. General Michael Hayden, former director of the NSA and CIA, has been quoted (in a 2014 Johns Hopkins debate) saying "we kill people based on metadata". Whether that is rhetoric or fact, the underlying point holds: who you contact, when, how often, from where, with whom in common - that pattern is enough to map a person's life with high precision.

Concretely, a messaging company that holds your metadata can answer questions like: who do you message at 2am, and is it the same person across years; which group chats are you in and what is the overlap between their members; how often do you message a particular contact in the week before a layoff is announced; what is your travel pattern based on the IP addresses your messages originate from. None of those questions require reading a single message. None of those questions are blocked by E2EE on contents.

This is the central reason Signal is positioned the way it is. The cryptography on contents is the same as WhatsApp's; the metadata story is fundamentally different. Signal stores almost none of the information needed to answer those questions, and what little it stores it publishes when it is compelled to hand it over. The Signal Foundation is not the only entity that could implement that posture - it is the entity that has decided to.

The backup problem, in concrete terms

Every E2EE message has to exist in plaintext somewhere - on the sending device when you typed it, on the receiving device when the other person reads it. As soon as either device is backed up, the plaintext leaves the encrypted envelope unless the backup is itself end-to-end encrypted. This is the single most common way that "encrypted" conversations end up readable to a third party.

The practical map in 2026:

• iMessage: default iCloud Backup is not E2EE - Apple can be served a warrant for the contents. Turning on Advanced Data Protection makes it E2EE. Both ends of the conversation need it on for the protection to hold.
• WhatsApp: default iCloud or Google Drive backup is not E2EE. The encrypted-backup option exists and works well - turn it on in Settings, Chats, Chat backup, End-to-end encrypted backup. Save the 64-character key in a password manager. Both ends again need to have done it.
• Signal: there is no cloud backup. Backups are local-only on Android (a file you encrypt with a passphrase and save yourself) and migration-only on iPhone (transfer to a new device, no archive at rest). This is a deliberate design choice and is why losing your phone with Signal on it without a saved backup means losing the history.
• Telegram: the cloud sync IS the backup, and it is not end-to-end encrypted. Telegram has the messages.

The endpoint problem, which encryption cannot fix

The other end of the conversation has a copy of everything you wrote. They can screenshot it. They can read it out loud to a third party. They can paste it into another app that is not encrypted. They can hand their phone to someone. They can have an infostealer on their laptop that reads the WhatsApp desktop client's cache. The strongest encryption in the world does not change the social reality that the person you trusted with the message can share it.

Your own endpoint matters too. A phone that boots into a lock screen but has biometrics enabled can be unlocked at a US border crossing under the "border search" doctrine, which courts have generally read as not requiring a warrant for routine searches of the device itself. A phone unlocked with a six-digit PIN that you type in public can be shoulder-surfed (the iPhone theft pattern that became a New York Times story in 2023 turned on exactly this). Disk encryption that is unlocked the moment you boot the device is much weaker than disk encryption that requires a passphrase on first boot. Notification previews on the lock screen can surface the first line of an "encrypted" message to anyone glancing at the phone face-up on a table.

The endpoint problem is the most important gap in practice. It is also the one the encryption discourse spends the least time on, because it is unglamorous and the answers are habits rather than cryptography.

What "end-to-end encrypted" actually buys you

Putting it together, the protection E2EE provides - the real, concrete thing - is this:

• The messaging company cannot read the contents of the conversation, even if they are compelled to.
• A breach of the messaging company's servers does not expose the contents of the conversation.
• A nation-state passively recording internet traffic does not get the contents - they get the encrypted bytes and the metadata around them.
• The local network you are on (the cafe Wi-Fi, the hotel network, your ISP) cannot read the contents.

Everything else - the metadata, the backups, the screenshots, the endpoint, the social fact that the other person has a copy - is outside the envelope. None of those things make E2EE useless. Together they define the realistic scope of the claim.

A practical checklist

1. For genuinely sensitive conversations, use Signal. The metadata story is the difference and there is no good substitute for it elsewhere. If you cannot get the other person to install Signal, the conversation is not actually private at the level you think it is.
2. If you use WhatsApp, turn on end-to-end encrypted backups - Settings, Chats, Chat backup, End-to-end encrypted backup. Save the 64-character key in a password manager. Ask the people you message most to do the same.
3. If you use iMessage, turn on Advanced Data Protection in iCloud settings. Set up the recovery contacts and the recovery key first - the recovery flow is the part that locks people out if they skip it.
4. Do not treat default Telegram as encrypted. For casual chat, fine. For anything you would not put in a Google Doc shared with the company, use Signal Secret Chats or move off Telegram for that conversation.
5. Turn off lock-screen notification previews for messaging apps. iOS: Settings, Notifications, Show Previews, When Unlocked or Never. Android: per-app notification settings, hide sensitive content on lock screen.
6. Use disappearing messages as a default, not as a feature you turn on for the bad messages. A 90-day or one-year timer in your regular chats means the historical record naturally shrinks without you having to think about it.
7. Assume the other end is a copy. Anything you would not want screenshotted, read aloud, or pasted into another chat is something you should not write, no matter how strong the encryption.

Where this fits

Encryption is one layer of a privacy posture, not the whole thing. The browser leaks identity even before you sign in - covered in the piece on five things your browser sends to every site. The accounts you use to log in to those sites leak a different slice - covered in the social-login trade-offs piece. And the second factor that protects those accounts is its own story, in the passwords, MFA and passkeys piece. Together they are most of what an ordinary person needs to think about. End-to-end encryption is the part that covers the conversation; the rest of the stack covers everything around it.

Privvert's tools all run locally in the browser - no upload, no account, no server in the middle. The reasoning is on the privacy page, and the rest of the practical guides are on the blog.