What “end-to-end encrypted” really means

By Hein de Wilde·1 August 2026·4 min read

End-to-end encryption means the service never holds the key and therefore cannot read your files — not even if compelled. Most services that describe themselves as encrypted do something weaker and entirely respectable: they encrypt your files with keys they hold. The difference is not marketing. It changes what the service can do for you and what it can be forced to do to you.

The three levels

Encrypted in transit. Nobody can read the file as it crosses the network. This is HTTPS. Every service does it, it is table stakes, and any provider listing it as a feature is padding a page.

Encrypted at rest, provider holds the key. The file is encrypted on disk, and the service holds the key that opens it. This protects against a stolen drive or a misconfigured storage bucket. It does not protect against the provider, or against anyone who can lawfully compel the provider.

End-to-end encrypted. The key is derived on your device and never sent. The provider stores bytes it cannot interpret. Compelling them yields ciphertext.

Almost every file transfer service is at level two. That is the normal, sensible design for this category. The problem is that level two is often described using level three's vocabulary.

Three questions that tell you which you have

You do not need to read a whitepaper. Ask these:

Can it show a preview or thumbnail of my file? If yes, something decrypted it. The provider holds the key. This is the fastest and most decisive test.

Can it scan my files for viruses? Same logic. Scanning requires reading.

If I forget my password, can they restore my files? If yes, they hold the key. If the honest answer is "no, your data is gone" — that is what real end-to-end encryption costs, and a provider willing to say it plainly is telling you the truth.

Any service offering both password recovery and end-to-end encryption is claiming two things that do not fit together.

What each is good for

Level two is not a compromise you should feel bad about. Provider-held keys are what make possible:

Previews, so a client can look through a gallery instead of downloading 40 GB
Virus scanning, which protects your recipients
Search across your own files
Recovery when you lose a password
Server-side zipping of a large folder into one archive

Those are real benefits, and for most work they are worth more than the stronger cryptographic property.

Level three is what you want when the provider itself is part of your threat model: source material a government might demand, journalistic material, legal files under privilege, or anything where "we were compelled" is an outcome you must engineer against rather than trust against.

The costs nobody advertises

If a service is genuinely end-to-end encrypted:

No previews. Your client downloads to look.
No virus scanning. Neither you nor the service can check what is inside.
No recovery. Lose the key and the file is unrecoverable. This is not a bug.
Sharing is harder, because sharing a file means sharing a key, and every mechanism for doing that has trade-offs.
Metadata usually leaks anyway. File sizes, timing, and who talked to whom are often visible even when contents are not.

That last one matters more than people expect. Perfect content encryption with visible metadata still reveals a great deal.

Where I stand, since I sell one of these

Yungle, which I build, is level two by design: every file is encrypted at rest with its own key, using AES-256-GCM, and the service holds the keys. I say "always encrypted" rather than the stronger phrase, deliberately, because previews and virus scanning happen server-side and both require decryption. Claiming otherwise would be false in a way that is trivially disprovable — you can see the previews.

There is also an opt-in mode where the browser seals the file before it is uploaded and the key never reaches the server, for the cases where the provider should be part of your threat model. It costs exactly what the section above says it costs.

I am spelling this out because "end-to-end encrypted" has become a phrase that gets attached to products that are not, and the least useful thing I could do on a page like this is add another one.

How to evaluate a claim

Apply the three questions. Previews, scanning, password recovery.
Ask where the key is derived and where it is stored. A straight answer is a good sign in itself.
Ask what happens if they receive a lawful demand. "We would provide the encrypted data, which we cannot read" is a specific answer. "We take privacy seriously" is not.
Look for a transparency report.
Check whether the code is auditable, if the claim really matters to you.

And be clear with yourself about which property you actually need. If the risk you are managing is "the wrong person receives this link" — which it usually is — encryption is not the control that helps. Expiry, revocation and access limits are. How to send large files securely is the practical version of that argument, and the secure services comparison covers who offers what.

For anything where lawful access is the concern rather than accidental access, the question is not really cryptographic at all — it is which government can compel the provider.