What Is End-to-End Encryption, and Why Do Some Apps Have It and Others Don't?

Or: "Encrypted" Doesn't Always Mean the Company Can't Read It

Open almost any modern app and you'll see security promises. Your banking app uses 256-bit encryption. Your cloud storage provider says your files are encrypted at rest. Your messaging app advertises end-to-end encryption. Another proudly adds a padlock icon.

Those sound like variations of the same promise. They aren't.

The word encryption means information has been mathematically transformed so it can't be understood without the appropriate key. What it doesn't tell you is where that encryption begins, where it ends, or who possesses the keys needed to decrypt it. A service can truthfully say "your data is encrypted" while being perfectly capable of reading that data itself. End-to-end encryption is designed to change that relationship.

Where Ordinary Encryption Ends

When you type a message into a conventional web service, your browser typically establishes an HTTPS connection — encrypting the communication between your device and the company's server. Someone observing the network between you and the company can't simply read the message in transit. That's enormously valuable.

But look at where the encryption ends. The TLS connection terminates at the company's server so the server can process your request. The company may then have the message in readable form. That isn't a flaw in HTTPS — it's doing exactly what it was designed to do: protect communication between your device and the server. It wasn't designed to hide your information from the server itself.

Think of it like an armored delivery truck. Your letter is protected while it's traveling across town. The truck arrives at the company's office, the company opens it, and reads the letter. The transportation was secure. The recipient still accessed the contents.

Companies may also encrypt data stored on their servers — encryption at rest — which protects against stolen drives and unauthorized storage access. But if the company needs to routinely process that stored information, its systems may have access to the decryption keys. Encrypted at rest doesn't automatically mean the company can't read it.

What End-to-End Encryption Actually Changes

With end-to-end encryption (E2EE), information is encrypted on the sender's device and isn't decrypted until it reaches the recipient's device. The company carries the encrypted message, stores the encrypted message, and routes the encrypted message — but if the system is properly designed so the company doesn't possess the necessary decryption keys, the company can't open it and read the contents.

The armored truck analogy changes. Instead of putting a readable letter in the truck, you first put the letter in a locked box that only your recipient can open. You then put the locked box in the truck. The company transports the box. The recipient unlocks it. The courier never needed to know what was inside.

This is why three services might each truthfully say "we use encryption" while describing completely different security models. One may protect data only in transit. One may encrypt stored data but hold the keys. One may use end-to-end encryption where only the communicating users possess the keys. The question that cuts through the marketing is always: who has the keys?

How Two Devices Share Secrets Without the Company Knowing

End-to-end encryption has an apparent chicken-and-egg problem. Joe and Sarah need encryption keys. But if Joe simply sends Sarah a secret key across the internet, couldn't someone intercept it?

Modern cryptography solves this using public-key cryptography. Instead of one shared secret key, each participant generates a mathematically related pair: a public key that can be shared openly, and a private key that stays on the device.

The padlock analogy helps. Sarah generates a special padlock and keeps the only key, but shares copies of the open padlock with anyone. Joe puts his message in a box, closes Sarah's padlock on it, and sends the box. Joe never needed Sarah's private key — just something that let him securely lock something for her. Sarah's private key opens it.

Real protocols are more sophisticated. Modern messaging systems derive temporary session keys, rotate keys, and establish new keys as conversations continue — providing what's called forward secrecy. If someone somehow obtains a current key, that shouldn't automatically unlock every message you've ever sent. A properly designed system limits the damage one compromised key can cause.

The Real Limits of End-to-End Encryption

E2EE protects the message between the endpoints. It doesn't make the endpoints themselves secure.

Compromised devices: If malware is installed on your phone, an attacker can capture what you type before it's encrypted, or read what's displayed after it's decrypted. The strongest encryption in transit can't help if the attacker is already reading your screen.

Backups: Your live conversations might be beautifully end-to-end encrypted. Then your phone backs them up. If those backups are stored in a form the cloud provider can decrypt, an attacker can bypass the messaging encryption entirely by targeting the backup. This is why some messaging services offer end-to-end encrypted backup options — and why enabling them matters.

Recipient behavior: Cryptography controls who receives the key. It cannot control what an authorized recipient does afterward. They can screenshot the message, forward it, copy it, or show someone else their phone. Encrypted doesn't mean impossible to leak.

Metadata: End-to-end encryption can protect the contents of a message without hiding every fact about the communication. A service may still have information about who communicated with whom, when, from which device, and how large the messages were. The contents of the letter can be sealed while the envelope still carries addressing information.

Why Some Apps Don't Use E2EE

If end-to-end encryption provides stronger privacy, why wouldn't every service simply enable it? Because it changes what the service can do.

Search: If a server can't read your messages, it can't search your ten years of chat history for "beef stew recipe." Indexing has to happen locally on your device instead.

Account recovery: If you forget everything and lose all your devices, an E2EE provider that genuinely can't decrypt your data can't restore it. If they could always restore it, it would mean they held a master key the whole time — which is exactly the model E2EE is designed to avoid.

Content moderation and spam filtering: Detecting phishing links or illegal content across messages is straightforward when servers can scan text. True E2EE forces platforms to rely on client-side reporting, metadata analysis, and user reports instead.

AI features: Summarizing your conversations or generating smart replies requires access to plaintext. Processing either has to happen on your device, inside specialized hardware, or within a trusted environment — all of which require careful design.

Privacy isn't free. It changes what the service can offer.

The Recoverability Tension

This is one of the most honest things to say about end-to-end encryption: privacy and recoverability pull against each other, and cryptography can't satisfy both fully.

Users want "nobody else should be able to access my information." They also want "if I forget everything and lose all my devices, support should restore everything." Those goals conflict. If the company possesses a mechanism for decrypting your data whenever you lose access, someone else may be able to use or compel that same mechanism. If the company genuinely cannot decrypt your information, losing your keys can mean losing the data permanently.

When a service promises "only you and the people you communicate with can read these messages," that promise is undermined if the company secretly holds a master key as a backup. The architecture has to choose.

The Policy Debate

End-to-end encryption has generated significant political debate because it limits what service providers can produce when compelled. With conventional server-readable messaging, a provider may be capable of supplying message content when legally required. With properly implemented E2EE, the provider may not possess the keys needed to decrypt it.

The proposal that recurs is some form of exceptional access — a mechanism that authorized authorities could use when necessary. The technical problem is that this changes the security model. If a mechanism exists that can bypass end-to-end protection, then the system now contains another path to plaintext. That mechanism must itself be protected from criminals, foreign intelligence services, malicious insiders, and everyone else who would very much like access to it. Cryptography doesn't understand the moral character of the person presenting a key — it understands whether the key works. Creating exceptional access creates an exceptionally valuable thing to attack.

The Bard's Take

"Encrypted" is one of those words that sounds more definitive than it is. Your connection to a website can be encrypted while the website reads everything you send it. A company's database can be encrypted while the company retains the keys to decrypt it. Those are legitimate and important security protections — but they're not the same thing as end-to-end encryption.

End-to-end encryption changes the trust relationship. The service provider becomes a courier carrying locked boxes rather than a recipient opening every box before passing it on. The company may operate the servers, transport the messages, and store the data without possessing the keys needed to read the contents.

That doesn't make the system magically secure. Your device can still be compromised. The recipient can screenshot your message. Metadata may still reveal information. Backups can weaken the protection. And losing your own keys can create the genuinely uncomfortable situation where the company cannot help you recover your data.

But that's also the point. If a company promises "only you and the people you communicate with can read these messages," the company shouldn't secretly hold a master key that means "unless we need to."

So the next time an application proudly announces YOUR DATA IS ENCRYPTED — don't stop there.

Ask: where is it encrypted? Where is it decrypted? And most importantly: who has the keys?

Because encryption protects information from whoever doesn't possess the key. End-to-end encryption is about making sure the company in the middle isn't one of the people who does.

Sources

• A Deep Dive on End-to-End Encryption — EFF Surveillance Self-Defense
• End-to-End Encryption — Wikipedia — Wikipedia
• How Signal Works — Signal
• What Is Encryption? — Cloudflare