End to end encryption makes a narrow and strong guarantee. Between the sender's device and the recipient's, the content is unreadable to anyone in between, including the operator of the service.
That guarantee is genuinely valuable and it is frequently extended, in casual description, to cover things it does not touch.
What is and is not covered
| Concern | Protected | Why |
|---|---|---|
| Interception in transit | Yes | Content is unreadable without the keys |
| Operator reading messages | Yes | The operator does not hold the keys |
| Who contacted whom | No | Routing requires it |
| When and how often | No | Timing is observable |
| A compromised device | No | Content is plaintext at the endpoint |
| An unencrypted backup | No | The copy leaves the protected path |
| The recipient's actions | No | They can forward or screenshot |
Five of the seven rows are outside the guarantee, and each of them is where practical compromise usually occurs.
The endpoints are the weak point
Encryption protects the path, and the path is rarely what is attacked. A message must be readable where it is read, so on both devices it exists as plaintext on screen and usually in local storage.
Anything with access to the device therefore has access to the content. Malicious software, an unlocked phone, a device backup, or a person with physical access all bypass the encryption entirely rather than defeating it.
Backups are the common failure
This deserves separate mention because it is the most frequent way strong encryption is undone by ordinary use.
If message history is backed up to a cloud service without separate encryption, that copy is readable by the backup provider and obtainable through the same processes that would have failed against the messenger. The conversation is protected in transit and available at rest, which is the outcome the encryption was meant to prevent.
Trust rests on key exchange
The mathematics is sound and depends on each party holding the correct key for the other. Establishing that is where the practical trust sits.
In nearly all consumer messengers the service distributes the keys, which means the service could in principle supply the wrong one and relay a conversation while both parties believe it is private. This is why verification codes exist, allowing two people to confirm out of band that their keys match, and why a warning appears when a contact's key changes.
Almost nobody performs the verification, so in practice the guarantee rests on trusting the operator's key directory, which is a weaker position than the encryption itself suggests.
Metadata remains, and it is structured
The service still needs to know which accounts are exchanging messages in order to deliver them, along with timing, frequency, and often message size.
Those records describe a person's associations precisely without revealing a single word, and they are stored in a form that is trivially queryable. Some services deliberately minimise what they retain here, and the difference between implementations is substantial and rarely advertised.
Groups and multiple devices widen the surface
The guarantee is between endpoints, and both features increase how many endpoints exist.
A group conversation is encrypted to every member, so its confidentiality is bounded by the least careful participant rather than by the encryption. Linking additional devices to an account creates further copies of the plaintext, each with its own storage and its own exposure.
Neither weakens the cryptography and both enlarge the set of places the content exists, which is the practical measure that matters.
Where scanning changes the picture
Proposals to examine content on the device before encryption, rather than in transit, are debated periodically in several jurisdictions.
The technical observation, independent of the policy argument, is that such a mechanism sits outside the guarantee entirely. Encryption is unaffected while content is inspected before it applies, which is why the debate is not about weakening encryption in the mathematical sense.
Note: the useful question is not whether a service is encrypted, since most now are. It is what the service retains, whether backups are separately encrypted, and whether the endpoints are trustworthy, because those decide the outcome.