The One Sentence Definition
End to end encryption (E2EE) means a message is encrypted on the sender's device and only decrypted on the recipient's device. Everyone and everything in between, including the app maker's own servers, the network operators carrying the traffic, and anyone who breaches the servers later, sees only scrambled ciphertext they cannot read. The "ends" are the two people communicating. Nothing positioned in the middle, not even the company running the service, gets to look inside.
The Actual Technical Guarantee
The guarantee is narrower and more precise than "it's encrypted," which is why it is worth stating exactly. E2EE means the decryption keys exist only on the participating devices, never on the provider's servers in a usable form. A server can relay ciphertext, store it, route it, and time it, but it structurally cannot decrypt it, because it was never given the key to do so. This is different from a company simply promising not to read your messages. It means they could not read them even if legally compelled to, because the plaintext genuinely does not exist anywhere they have access to.
Encryption in Transit vs End to End Encryption
Most of the modern web already uses encryption "in transit," meaning HTTPS (our HTTPS and TLS explainer covers the mechanics). That protects your data as it travels between your device and the company's server, so someone snooping on the network in between sees nothing useful. But the company itself decrypts it on arrival to process, store, and often read it. E2EE adds a second, stronger boundary: the company's own servers never get to decrypt it either.
| Encryption in transit only | End to end encryption | |
|---|---|---|
| Protected from network eavesdroppers | Yes | Yes |
| Readable by the service provider | Yes, decrypted on their servers | No, never decrypted server side |
| Readable if the provider's servers are breached | Potentially, plaintext or recoverable data may be stored | No, only ciphertext is ever stored |
| Readable if the provider receives a legal demand for content | Yes, they can comply | No, they have nothing to hand over but ciphertext |
The Mechanism, Briefly
E2EE is built on public key cryptography, the same underlying family of math behind passkeys (see our FIDO2 and WebAuthn explainer). Each device generates a key pair: a public key it can share freely, and a private key that never leaves the device. To send you a message, the sender's app encrypts it using your public key. Only your matching private key, sitting only on your device, can reverse that encryption. The server in the middle only ever handles the encrypted version, so it has nothing meaningful to decrypt even if someone wanted it to.
The real test of genuine end to end encryption: if the company running the service received a legal order demanding the content of your messages, could they hand over anything readable? If the honest answer is no, only gibberish, that is what separates E2EE from ordinary server side encryption, no matter what marketing language a company uses.
Where This Actually Shows Up in Practice
- Messaging apps that use it by default: Signal, widely regarded as the reference implementation and the protocol other apps license, WhatsApp for message content, and iMessage for conversations between Apple devices.
- Messaging apps that do not, by default: Telegram's standard cloud chats are not end to end encrypted; only its separate, opt in "secret chats" feature is (our Telegram security guide covers this distinction). Most standard email is also not E2EE end to end unless you specifically add something like PGP on top.
- Backups: WhatsApp and iCloud both offer optional end to end encrypted backup modes, worth turning on deliberately, since an unencrypted cloud backup of an otherwise E2EE conversation is simply a readable copy of it sitting in someone else's storage.
- Password managers: reputable ones encrypt your vault end to end, meaning the company hosting your synced vault cannot read your stored passwords even in principle.
- Privacy focused email and storage providers: services like Proton build their offering specifically around this guarantee, in contrast to mainstream providers that decrypt content server side to power search and spam filtering.
What End to End Encryption Does Not Protect
- Your device itself. E2EE protects data while it is in transit and while it sits on someone else's server. It does nothing for a phone that is infected with spyware or physically unlocked in someone else's hands. Whoever controls an unlocked device simply reads the already decrypted messages directly.
- Metadata. Who you communicated with, when, how often, and for how long can remain visible to the provider even when the message content itself is completely unreadable to them. Signal deliberately minimizes how much metadata it retains; many other apps do not make the same effort.
- The person on the other end. Your recipient can screenshot a conversation, forward it elsewhere, or have their own device compromised. E2EE secures the pipe between two endpoints; it has no control over what either endpoint does with the message once it arrives.
- An unencrypted backup of an encrypted conversation. If you enable a plain cloud backup of chats that were end to end encrypted in transit, that backup is now a readable copy sitting on a server, quietly undoing the protection the conversation had while it was actually in transit.
Frequently Asked Questions
If E2EE is this much more secure, why doesn't every service just use it?
Because it trades away features that depend on the provider being able to read content. Server side search across your messages, automated spam and abuse filtering, and convenient account recovery when you lose your device all become much harder or outright impossible once the provider genuinely cannot decrypt anything. Many mainstream services choose that convenience deliberately; privacy focused ones choose the stronger guarantee instead, and accept the tradeoffs that come with it.
Is WhatsApp really end to end encrypted given that Meta owns it?
The message content itself is end to end encrypted by default using the Signal Protocol, meaning Meta genuinely cannot read the text of your conversations. That said, metadata about who you talk to and when is a separate matter from content, and an unencrypted cloud backup undoes the protection for whatever is stored in it. Enable WhatsApp's encrypted backup option specifically, and keep the distinction between content and metadata in mind.
Does having E2EE mean I no longer need 2FA?
No, they protect entirely different things and you need both. End to end encryption protects the content of your messages from anyone intercepting or storing them. Two factor authentication protects your account login itself. Without 2FA, someone who guesses or steals your password can simply log into your account directly and read your own E2EE conversations from inside your own app, no interception required. Our 2FA overview covers the login side of this.
What happens to my message history if I lose the device holding the encryption keys?
Since the private keys live only on that device, losing it can mean permanently losing message history, unless you had already enabled an encrypted backup option. This unforgiving failure mode is genuinely the cost of the stronger privacy guarantee: a provider that truly cannot read your messages also cannot restore them for you if you lose the only device holding the keys. Turn on your app's encrypted backup feature before you need it, not after.
Can end to end encryption itself be broken?
The well vetted implementations, the Signal Protocol in particular, have no known practical break of the underlying cryptography itself. Real attacks target the endpoints instead: a compromised or infected device, a screenshot taken by the person you are messaging, or tricking someone into verifying the wrong contact's key. The mathematics holds up; the humans and the devices at either end remain the softer target.
