What end-to-end encryption actually means for the files you send

Almost every file service says it encrypts your files. Very few of them mean the same thing by it, and the difference decides something quite specific: whether the company holding your file can open it.

This is what the phrase actually means, how to tell the two apart from the outside, and when the stronger version is worth its one real cost.

Two things called encryption

Encryption at rest means the file is stored scrambled on the provider's disks, with a key the provider also holds. If somebody walks out of a data centre with a drive, they get noise. That is genuinely worth having, and it is what most services mean.

What it does not do is put the file beyond the provider. They hold the key, so they can open it: to scan it, to comply with a court order, or by accident through a misconfigured bucket. An employee with the right access can read it. So can anyone who compromises that access.

End-to-end encryption means the file is sealed before it leaves your device, with a key that never reaches the service at all. What arrives on their servers is ciphertext. They cannot open it, not because policy forbids it but because they do not have the key.

At rest protects the file from a stolen disk. End to end protects the file from the company.

How to tell which one you are being sold

The marketing language is nearly identical, so ignore it and look for these instead.

• Can they show you a preview of your own file? Thumbnails of a document in a web dashboard mean the server can read it. That is not end to end, whatever the page says.
• Can they reset access if you lose your key? If a support agent can recover your files, so can anyone who convinces them they are you. Real end-to-end encryption has no recovery path — that absence is the proof.
• Do they search across your content? Full-text search of file contents requires reading them.
• Where does the key appear? In a genuine system you are given a key, or a link containing one, and told it cannot be retrieved later. If a key is never mentioned, there is not one that is yours.

The link fragment trick

If the service never receives the key, how does the recipient get it?

One good answer hides in a corner of the URL specification. Everything after the # in a URL — the fragment — is handled by the browser and never sent to the server. It was designed for jumping to a heading on a page, but it means a link can carry a secret past the very server that hosts it.

So a share link looks like this:

https://betterfiletransfer.com/d/7fq2xk#k=wxrt-9m4k-pqz3-h7bn

The part before the hash reaches us and tells us which sealed bundle to send. The part after it stays in the recipient's browser and unlocks it there. Our logs contain the first half and cannot contain the second.

The obvious caveat: the link is now the key. Anyone you forward it to can open the file, so a link like this belongs in a message to one person, not in a channel with forty. When that is not good enough, the key can travel separately — the link carries nothing, and the download page asks for the key you pass along by another route.

What the sealing actually does

The mechanics are worth a paragraph, because they explain the limits.

A key is derived from your secret with PBKDF2 at 250,000 rounds against a random salt. Stretching matters: it makes guessing a typed secret hundreds of thousands of times more expensive, which is the difference between a weak passphrase being brute-forced in an afternoon and not.

Each chunk of the file is then sealed with AES-256-GCM. GCM authenticates as well as encrypts, so a chunk that has been altered fails to open rather than decrypting into garbage. The chunk's position is mixed in as associated data, which means chunks cannot be reordered or swapped between files without the tampering being detected.

The filename is sealed too. It sounds fussy until you consider that redundancy-list-final.xlsx gives away nearly everything the encryption was protecting.

What it does not protect

Being precise about this is part of the point.

• It does not hide that a transfer happened. We know a file of a certain size was uploaded and when it was downloaded. That metadata is how the service works at all.
• It does not protect a device. If the recipient's laptop is compromised, the file is readable the moment they open it. Encryption in transit and at rest ends where the file is used.
• It does not survive a shared key. Paste the key into a group chat and it protects nobody.
• It cannot rescue a bad secret. Stretching buys a lot of time against a guessable passphrase. It does not buy immunity.

The one real cost

There is no recovery. Lose the key and the file is gone — not withheld pending verification, not restorable by support, gone. We hold bytes we cannot read and no amount of asking changes that.

This is the trade in its entirety. A service that can rescue you can also be compelled, tricked or breached into opening your files for somebody else. You cannot have one property without losing the other, and any service claiming both is describing the weaker one.

Practically: for a transfer where losing access would be a catastrophe and secrecy is not critical, sending it unencrypted is a legitimate choice. For anything you would not want read by a stranger, take the trade.

When to use which

• End to end for contracts, identity documents, medical and financial records, unreleased work, anything covered by an NDA, and anything about a person who did not choose to be in it.
• Either is fine for a public marketing asset, a photo set you would happily post, or a file that is already published elsewhere.

On this service encryption is on by default and takes no extra steps, so the question is usually whether to turn it off — and the answer is only when the consequence of a lost key outweighs the consequence of the file being read.

More on the surrounding decisions: how to send large files covers the methods themselves, and how long a link should last covers the other control that matters. Our privacy policy states exactly what is stored and for how long.