What end-to-end encryption actually means when you upload a file

Nearly every service now writes "encrypted" somewhere on its page, but the word means completely different things depending on who holds the key. This article explains the difference in plain terms, and what end-to-end encryption means in practice when you upload a file.

Two very different things

Most sites say your files are "encrypted", and usually they mean encryption at rest: the file arrives at the server as-is, then gets encrypted there with a key the company owns. That protects you if someone steals the hard drives. It does not protect you from the company itself, or from whoever breaches it and takes the keys with them.

End-to-end encryption is fundamentally different: the file is encrypted on your device before it leaves, and the server never holds the key at all. What reaches it is meaningless data.

The practical difference: in the first case the server can read your file and promises not to. In the second it simply cannot.

How it works, step by step

When you switch the option on before uploading, this happens inside your browser:

1. A random key is generated for that one file.
2. The file is split into chunks and each chunk is encrypted with AES-GCM, an accepted global standard.
3. The filename is encrypted too — a detail many services skip. A name like severance-agreement-2026.pdf gives away plenty even when the contents are protected.
4. The encrypted data is uploaded, and the key is placed in the part of the link after the # sign.

Why the part after # specifically

This is not cosmetic. It is the whole basis of the security.

When your browser opens any link, it sends the path to the server — but it never sends what comes after the #. That fragment stays inside the browser. This behaviour is consistent across every browser and written into the web standards.

The result: the key lives in the link you share, but it never touches our servers or the hosting site's servers. It does not even appear in server logs.

Which is why: copy the whole link. Trim the last part off and the key is gone — nobody can open the file, and we cannot recover it either.

What it protects you from, and what it does not

Being clear here matters more than being reassuring.

It protects against:

• Staff at the hosting service reading your file.
• Data leaking if the hosting servers are breached.
• Any intermediary learning the file's name or contents.

It does not protect against:

• Whoever you share the link with. Anyone holding the full link holds the key. Encryption cannot tell a friend from a stranger.
• Your own device. If your computer is compromised, the file is readable before it is ever encrypted.
• Losing the link. There is no backup of the key anywhere. That is a feature and a liability at once.

When to turn it on, and when not to bother

Turn it on for personal or official documents, internal work files, or anything you would not want a stranger reading.

Skip it for files you intend to make public anyway — an image for a post, or something you want listed in the public catalogue. Encryption there only disables previews and complicates sharing for no gain.

One technical requirement

Encryption runs in the browser through the WebCrypto API, which browsers only expose on sites secured with an HTTPS certificate. On a site without one, the encryption option is disabled — not a fault, but a deliberate browser protection.

In short

End-to-end encryption means trust is no longer required: the server cannot read your file even if it wanted to. The only cost is that the link becomes your responsibility — keep it whole, and share it only with people you trust.

Try an encrypted upload, or read the guide to sending large files.