End-to-end encrypted file transfer

What is end-to-end encryption?

Most transfer services encrypt your files in transit (TLS) and at rest on their servers. That protects against outsiders, but the service itself holds the keys and could technically read the files. End-to-end encryption (E2EE) moves the encryption to the ends: your browser encrypts before upload, your recipient’s browser decrypts after download, and what sits on the servers in between is unreadable without a key that is not stored there.

The practical difference: with E2EE, a breach of the storage, a mistaken access or a legal request to the service can only ever produce encrypted data. For a gentle introduction to the concept, read end-to-end encryption explained.

How to send an end-to-end encrypted transfer

1. 1

   Step 1

   Add your files

   Open Transfr and drop your files, up to 100 GB per transfer on the free plan.

2. 2

   Step 2

   Turn on end-to-end encryption

   Switch it on in the transfer options. Your browser generates a random key and encrypts each file as it uploads.

3. 3

   Step 3

   Optionally add a password

   The password is then mixed into the key, so even someone with the full link cannot decrypt without it.

4. 4

   Step 4

   Share the full link

   Copy the complete link, including the part after the #, or let Transfr email it to up to 10 people. Your recipient opens it and their browser decrypts the files.

How it works under the hood

• A fresh random key for every transfer, generated in your browser.
• AES-GCM encryption of every file, streamed in small records so large files never have to fit in memory. The scheme follows the design of Mozilla’s open-source Send project.
• The key goes in the URL fragment (after #). Browsers do not send the fragment when they open a page, so visiting the link does not hand the key to our servers.
• Names and messages are encrypted too: file names, file types, the transfer title and your message are only readable with the key.
• With a password, the decryption key is derived in the browser from the link secret and the password. The server only keeps a hash used to check the password.

What end-to-end encryption does not hide

Honest limits matter for security decisions. Even with E2EE, the server knows that a transfer exists, how large the encrypted files are, how many there are, when it was created and when it is downloaded. And anyone you give the full link to can decrypt it, which is why a password and a short expiry are good companions.

The link is also only as private as the place you put it. An email containing the full link sits in the recipient’s mailbox like any other message; a link pasted in a group chat is readable by the whole group. If that matters, copy the link yourself and send it through a channel you trust, and send the password through a different one. That way, intercepting a single message is never enough to open the files.

Trade-offs to know before turning it on

For a folder that must keep its structure, zip it first and send the archive end-to-end encrypted. For a 100 GB upload over a fragile connection, consider a password and a short expiry instead, so the upload can resume. See sending a folder and sending 100 GB.

When should you use end-to-end encryption?

• Legal, medical and financial documents: contracts, records, statements, IDs. See secure file transfer for law firms.
• Unreleased creative work: films, albums, campaigns under embargo.
• Personal data covered by the GDPR, where limiting who can read the data is part of your obligations. See GDPR-compliant file transfer.
• Anything you would not want to explain if a link leaked.

For everyday sharing of holiday photos, a standard transfer with a password is usually enough, and it keeps folders and resumable uploads. Our page on secure file transfer compares every protection, and password protection explains how the two combine.