What end-to-end encryption actually protects — and what it does not

"Encrypted" is printed on almost every file service on the internet, and it means at least three different things. The distinction is not academic — it decides exactly who, other than your recipient, is able to open your file.

Three things "encrypted" can mean

Encrypted in transit (HTTPS/TLS). The file is protected while it travels between your device and the server. Anyone watching the network — the café Wi-Fi, your ISP — sees noise. But the server receives the file in plaintext, because it has to terminate the TLS connection to store anything. This is the baseline; every serious site has it, and on its own it says nothing about who can read your file afterwards.

Encrypted at rest. The file is stored encrypted on the provider's disks. This protects against someone stealing the physical drive or reading a raw backup. It does not protect against the provider, because the provider holds the key — that is the whole point of the design, since they need to decrypt the file to serve it back to you.

End-to-end encrypted. The file is encrypted on the sender's device before it is uploaded, and decrypted on the recipient's device. What the server stores is ciphertext it was never given the means to open. Whether that last part is actually true depends entirely on where the key lives, which is the only question worth asking.

The key is the whole story

The cipher is almost never the weak point. AES-256-GCM is the standard for this job, it is implemented directly in browsers through the WebCrypto API, and nobody is breaking it. Marketing pages love to lead with "AES-256" precisely because it is impressive and tells you nothing.

The question that matters is: who can get hold of the key? A service can encrypt with unbreakable AES and still be trivially able to read your files, if the key is generated on their server, or uploaded to it, or derived from something they also hold. When you evaluate a service, ignore the cipher name and ask where the key is created and what, exactly, is sent alongside the ciphertext.

This is also why a key placed in the fragment of a URL — the part after the # — is a real design and not a trick. Browsers never send the fragment to the server, so example.com/d/abc#key=… transmits the key to the recipient without the server ever seeing it in a request. It also means anyone who gets the full link gets the file.

Four things end-to-end encryption will not do for you

1. It does not protect the endpoints. E2EE secures the file between two devices. If either device is compromised — malware, a shared computer, a phone someone else can unlock — the file is readable at the point where it is decrypted, and no amount of cryptography in the middle changes that.
2. It does not stop the recipient. Once someone can decrypt your file, they can save it, screenshot it, forward it. E2EE controls who can open the file, never what they do afterwards. There is no technology that undoes handing someone a file.
3. It usually does not hide metadata. Even when file contents are unreadable, a server generally knows a transfer happened, roughly how big it was, from which IP, at what time, and when it was downloaded. For most people that is fine. If the fact that you communicated with someone is itself sensitive, encryption of contents is not the protection you need.
4. It does not survive a bad key hand-off. If you email the file to someone and then email them the password in the next message, the two messages sit in the same mailbox and you have gained nothing. The key has to travel by a different route than the file — a phone call, a message on a different app, spoken out loud.

A practical checklist

• Does the encryption happen in your browser or app, or after upload? If the site has a plain "upload" progress bar that starts instantly on a 2 GB file, nothing was encrypted locally first.
• Where does the key come from — your device, or their server?
• Can you use the service without giving it an account? An account ties every transfer to an identity, whatever the ciphertext says.
• When is the file deleted, and is that automatic or your responsibility?
• Is the client code inspectable? For anything browser-based you can open developer tools and watch whether a key ever leaves in a request body.

More guides