End-to-end encryption explained: what it really protects

End-to-end encryption (E2EE) means your files are encrypted on your device before they leave it, and can only be decrypted by the people who hold the key, never by the service that stores and delivers them. Ordinary “encrypted” services protect files on the way and on their disks, but they hold the keys themselves; with end-to-end encryption, they only ever see scrambled data.

That difference sounds technical, but it decides who can read your files if a server is breached, if an employee looks where they should not, or if a legal request arrives. This guide explains the three kinds of encryption you will see advertised, how end-to-end encryption works in a file transfer, and its practical limits.

Three kinds of encryption, compared

Encryption in transit relies on TLS, currently TLS 1.3 (RFC 8446), which protects against eavesdropping on the network. Encryption at rest protects against someone stealing a disk. Both are standard and worthwhile, but in both cases the service can decrypt the files, because it manages the keys. End-to-end encryption adds a layer on top that the service cannot remove.

How end-to-end encryption works in a file transfer

1. 1

   Step 1

   A key is created in your browser

   When you turn on E2EE, your browser generates a random secret key. It never needs to be typed or remembered.

2. 2

   Step 2

   Files are encrypted before upload

   Each file is encrypted on your device with that key, using a modern cipher such as AES in GCM mode, which also detects tampering.

3. 3

   Step 3

   Only ciphertext is uploaded

   The service stores and delivers encrypted data it cannot read.

4. 4

   Step 4

   The key travels in the link

   The key is added to the download link after a # sign. That part of a URL stays in the browser.

5. 5

   Step 5

   The recipient’s browser decrypts

   When the recipient opens the full link, their browser downloads the encrypted files and decrypts them locally with the key.

Why the key after the # stays private

A web address can end with a fragment, the part after the # sign. The HTTP standard (RFC 9110) states that fragment identifiers are reserved for client-side processing and are not sent in requests: when the recipient opens the link, the browser asks the server for the page without the fragment, then reads the key locally. This is the design popularised by Mozilla’s former Firefox Send service, and it is how Transfr’s end-to-end encryption works.

What end-to-end encryption protects against

• A breach of the provider’s servers: stolen files are unreadable without the keys.
• Insider access: staff at the service cannot open your files.
• Requests to the provider: the service cannot hand over readable content it never had.
• Misconfigured storage: even if a storage bucket were exposed, the content would be ciphertext.

There is a regulatory upside too. Under the GDPR, a company does not have to notify affected individuals of a breach if the data was rendered unintelligible to unauthorised people, “such as encryption” (Article 34(3)(a)). The European Data Protection Board adds that this holds only for data that was properly encrypted and whose key was not compromised. See our guide to GDPR-compliant file transfer.

What it does not protect against

• A leaked link: whoever has the full link has the key.
• A compromised device: malware or a malicious browser extension on the sender’s or recipient’s computer can see files before encryption or after decryption. RFC 9110 itself notes that fragments remain visible to scripts in the page.
• Metadata: depending on the service, file names, sizes, dates and email addresses may remain visible to it.
• What the recipient does next: once decrypted and saved, the file is an ordinary file.

The trade-offs in practice

Because the service cannot read the files, it cannot do much with them either. On Transfr, for instance, turning on end-to-end encryption means:

• Files are encrypted in the browser with AES-128-GCM, and the key is placed in the link’s fragment. Storage encryption (AES-256 at rest) still applies underneath.
• Previews are generated in the recipient’s browser after decryption, for files up to 2 GB and only when the link includes the key; larger files must be downloaded.
• Folder structure is not kept, interrupted uploads cannot be resumed after a page reload, and files imported from Drime cannot be end-to-end encrypted, because Transfr copies them for you.
• The key is never stored on Transfr’s servers. But whenever Transfr emails a link, to your recipients or as the confirmation email signed-in senders receive, your browser hands it the full link, key included, so it can be placed in the email; it is used for that email only, then the email sits in mailboxes. For the strictest setup, copy the link yourself and share it through a channel you trust.

None of these are flaws: they are the direct consequence of a service that cannot see your content. For everyday transfers, a password and an expiry date are often enough; for confidential material, the extra protection is worth these trade-offs.

End-to-end encryption vs a password

They solve different problems, and they work well together. A password controls who can open the download page; the service checks it, so the service could still access the files. End-to-end encryption controls who can read the content at all, including the service. Combining both means a leaked link alone is not enough, and the provider never sees the content. Our article on share link expiry and passwords covers how to choose passwords and expiry dates.

When should you use end-to-end encryption?

End-to-end encryption in tools you already use

You probably rely on end-to-end encryption every day without noticing: WhatsApp encrypts messages and attachments between the people in a chat, and services such as Proton Drive, Tresorit Send and Wormhole encrypt files in the browser before upload. Mainstream cloud storage, on the other hand, generally encrypts files in transit and at rest with keys the provider manages. Our comparison of the best free file transfer services notes which ones offer end-to-end encryption for free, and our page for law firms shows how professionals combine it with passwords and short expiry dates.

How to check that a service really uses end-to-end encryption

• Encryption should happen before upload, in your browser or app, not “on our secure servers”.
• The service should say it does not store the keys; look for keys in the link fragment or derived from a secret only you know, and check what happens when it emails links for you.
• If the service can show you a server-side preview or scan of an encrypted file without the key, it is not end to end.
• Look for a description of the cipher and the design, not just “bank-level security”.

For a broader set of habits, from passwords to who should receive what, see our secure file transfer checklist and the page on secure file transfer.