How Transferify encrypts files in your browser

Every file you send with Transferify is encrypted in your browser before any of its bytes leave your device. The cipher is AES-256-GCM, run by your browser's built-in Web Crypto API, and the key is made on your device for each transfer. The sending modes differ in one thing only: where that key goes afterwards.

This post explains the mechanism for readers who want to check it: how the key is made, how a file is cut and sealed, what stops a stored file from being changed, and who can unlock it in each mode.

The key is made on your device

When you start a transfer, your browser asks the Web Crypto API for a new random 256-bit AES key. One key covers every file you send together. Files you add to a hosted transfer later get a new key of their own.

The key is not derived from your email address, your account or a password, so nothing about you can be used to guess it.

Files are encrypted as a stream, in chunks

Your browser reads each file as a stream and encrypts it piece by piece, so a file far larger than your device's memory still encrypts without being loaded whole.

• Hosted transfers use chunks of 8 MiB for most files.
• Very large hosted files use a larger chunk, a whole multiple of 8 MiB up to 256 MiB, so the file still fits the storage limit of 10,000 parts per file.
• Peer-to-peer transfers use chunks of 32 KiB by default, so each encrypted chunk fits in one data channel message that every WebRTC peer accepts.

Each chunk is sealed with AES-256-GCM, which encrypts it and adds a 16-byte authentication tag. If a single bit of the chunk changes, the tag no longer matches and decryption refuses the chunk.

Every chunk is tied to its place

Encrypting chunks one by one leaves a gap if nothing ties each chunk to its position: whoever holds the stored copy could reorder the chunks, drop the last one, or swap in a chunk from another file. Two things close that gap.

A unique nonce for every chunk. AES-GCM needs a nonce, a number used once, for every chunk it seals. Each file's encrypted stream starts with an 8-byte value that your browser picks for that file and writes into the stream's header, and each chunk adds its own 4-byte counter to it. Within a file, no two chunks share a nonce. Across files, the 8-byte values are random, or derived from a secret your browser holds, so a repeat is vanishingly unlikely. Reusing a nonce under the same key is the one thing AES-GCM must never do.

Authenticated position data. Every chunk is sealed together with a short label that names the transfer, the file, the chunk's index and whether it is the file's last chunk. The label is not stored with the chunk. The recipient's browser rebuilds it for the file it asked for, so a chunk only decrypts in the exact place it was sealed for.

A failed check stops the download and discards what was being written, so a recipient gets the exact file or an error, never a quietly damaged copy.

Senders' browsers have written this label since October 2026. Files stored before then carry an earlier label that names only the transfer and the chunk's index, and recipients' browsers still read them.

Where the key goes: three cases

The file is encrypted the same way in every case. What differs is how the recipient gets the key.

The same encryption in every mode; only the key's route differs. In the default mode our service can obtain the key. In Zero-Knowledge and peer-to-peer transfers it never does.

Hosted, default mode: the key is wrapped for our service

In the default mode, your browser wraps the file key before anything is sent. It encrypts the key with RSA-OAEP (SHA-256) under the public half of a 3072-bit RSA key pair, whose private half is held in AWS Key Management Service (KMS). The raw key is never part of any request. We store the wrapped key with the file's record.

When a recipient opens the link, our service first checks that the link has not expired and that the password is right, if you set one. Only then does it ask KMS to unwrap the key, and it returns the key to the recipient's browser over HTTPS. The recipient's browser does the decryption. Our service does not decrypt file contents.

So in this mode we are technically able to decrypt a hosted file, and we say so. In return you get a short link with no key in it, a link you can copy again from your list of transfers, and links our service can email to your recipients. A password you set in this mode is sent to our service, stored only as a hash, and checked before the key is released.

Hosted, Zero-Knowledge mode: the key stays in the link

With Zero-Knowledge mode, your browser sends no key material at all. The key goes into the share link after the "#" sign. Browsers do not send that part of an address when they request a page, so our servers never receive it. The recipient's page reads the key from the link, removes it from the address bar straight away, and decrypts the download on the recipient's device.

If you also set a password, the link carries a wrapped key instead of the raw one. Your browser derives a wrapping key from the password with PBKDF2 (SHA-256, 600,000 iterations, a random 16-byte salt) and seals the file key with it. The recipient's browser repeats that with the password they type. The password and the raw key never reach us, and a wrong password simply fails to unwrap on the recipient's device.

Because the key exists only in the link, our service cannot email a Zero-Knowledge link to your recipients: the email would carry a link without its key. You share a Zero-Knowledge link yourself, over a channel you trust.

Peer-to-peer: encrypted twice

A peer-to-peer transfer is never stored on our servers. Your browser still makes a key for each instant transfer, puts it after the "#" in the link, and seals every chunk with it before the chunk enters the WebRTC connection. That connection is itself encrypted with DTLS. The reason for the second layer is explained in how a peer-to-peer transfer works.

What the encryption covers, and what it does not

The encryption protects the contents of your files. What our service processes to run a transfer is set out in our Privacy Policy.

Two more limits are worth stating plainly:

• A link works for whoever holds it, so share it only where you would share the file, and send any password over a different channel.
• Encryption in the browser cannot protect a file on a device that is already compromised, at either end.

Try it

The encryption runs on every transfer, on every plan, with nothing to set up. Send a file now and the key is made in your browser the moment you start.