"End-to-end encryption" is the kind of phrase that means very different things depending on which page of which provider you’re reading. We’ll be specific: ReTransfer runs two layers of crypto, and they’re solving two different problems.
Layer 1 — at-rest envelope
Every file we receive gets its own AES-256-GCM data encryption key, wrapped under a master key the API process owns. The wrapped key is stored in the database; the ciphertext is stored in object storage. If someone walks off with a disk at the storage provider, they get nothing readable.
This layer is automatic and you don’t configure it. The trade-off: the API process holds the master key, so a compromised API box is a worst case here. That’s why we run the second layer too.
Layer 2 — end-to-end (your toggle)
Flip the E2E switch on the send screen and the upload looks the same to you but isn’t to us. The browser derives a key from a 10-character passphrase via Argon2id (with a fresh salt per transfer), encrypts the file under that key, and only then uploads. The server stores the same envelope shape as Layer 1 — but the data key inside is, from our side, opaque.
If you lose the passphrase, your files are gone. We can’t recover them, and that’s the whole point.
On the recipient side the link includes the verification metadata in URL params; the passphrase you share over a separate channel completes the picture. The recipient’s browser does the decryption locally — neither preview nor download routes ever touch plaintext on our infrastructure.
When to flip the switch
For most sends the at-rest envelope is enough. The cases where E2E earns its keep: client deliverables, anything regulated (legal, medical, finance), or anytime you’d shrug and say "I’d rather the host couldn’t read this if it wanted to." It costs you one passphrase you have to remember to share. That’s the whole tax.