End-to-end encryption means the service never holds the key, and therefore cannot read your files — not even if compelled. Most services that call themselves 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.
Three levels
Encrypted in transit. Nobody can read the file as it crosses the network. This is HTTPS. Every service does it; any provider listing it as a feature is padding a page.
Encrypted at rest, with the provider holding 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 anyone who can lawfully compel the provider.
End-to-end encrypted. The key is created on your device and never sent. The provider stores bytes it cannot interpret. Compelling them yields ciphertext.
Almost every file transfer service sits at level two, and that is the normal, sensible design for this category. The problem is that level two is often described with level three's vocabulary.
Here is what level two looks like when it is done carefully — one key per file, with those keys locked by a master key kept apart from them:
Three questions that tell you which you have
You do not need a whitepaper. Ask:
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 means reading.
If I forget my password, can it restore my files? If yes, it holds 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 so plainly is telling you the truth.
A service offering both password recovery and end-to-end encryption, for the same files, is claiming two things that do not fit together.
What each level is good for
Level two is not a compromise to feel bad about. Provider-held keys are what make these possible:
- previews, so a client looks through a gallery instead of downloading 40 GB
- virus scanning, which protects the people you send to
- search across your own files
- recovery when you lose a password
- zipping a large folder into one download on the server
For most work, those are worth more than the stronger property.
Level three is what you want when the provider itself is part of your threat model: material a government might demand, journalistic sources, legal files under privilege — anything where "we were compelled" is an outcome you have to engineer against rather than trust against.
What it costs, which 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 gone. This is not a bug.
- Sharing is harder, because sharing a file means sharing a key, and every way of 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 point matters more than people expect.
Where I stand, since I sell one of these
Yungle, which I build, is level two by design for ordinary files: 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 on purpose, because previews and virus scanning run on the server and both require decryption. Claiming otherwise would be false in a way you could disprove in seconds — you can see the previews.
Two things are end-to-end, and they are opt-in:
- An end-to-end encrypted transfer. The browser seals the file before it uploads, and the key travels in the part of the link after the
#, which browsers never send to a server. - The vault, locked with a passphrase that never leaves your browser. We cannot open it, and we cannot reset the passphrase either.
Both cost exactly what the list above says: no previews, no scanning, and no rescue from us if the key is lost — the vault gives you a recovery kit to keep yourself, precisely because we cannot help. The vault and secure sharing pages say so too. I spell this out because "end-to-end encrypted" gets attached to products that are not, and the least useful thing a page like this could do is add another one.
How to evaluate a claim
- Apply the three questions: previews, scanning, password recovery.
- Ask where the key is created and where it is stored. A straight answer is a good sign in itself.
- Ask what happens when they receive a lawful demand. "We would hand over encrypted data we cannot read" is a specific answer. "We take privacy seriously" is not.
- Look for a transparency report.
- Check whether the code can be audited, if the claim really matters to you.
And be clear about which property you actually need. If the risk is "the wrong person gets 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, and for when lawful access is the concern, the question is less cryptographic than it looks: it is which government can compel the provider. If this is why you are here at all, privacy-minded people is written for you.