End-to-end encrypted file transfer
By the WispFile team · Updated 24 September 2026
End-to-end encrypted file transfer means a file is encrypted on your device and can only be decrypted on the recipient’s, with a key the service in between never holds. The test is simple: could the company that moves your file read it if it wanted to? With most cloud and transfer services the answer is yes. With end-to-end encryption, it is no.
Key facts
- “Encrypted in transit” and “at rest” still leave the provider holding the keys.
- End to end: only the sender and recipient ever have the key.
- WispFile: AES-GCM per piece, a 256-bit key made in your browser.
- The key travels in the link’s fragment, which browsers never send to servers.
Three kinds of “encrypted”
| Claim | What is protected | Can the provider read your file? |
|---|---|---|
| Encrypted in transit (HTTPS/TLS) | The connection between you and the server | Yes |
| Encrypted at rest | The copy on the provider’s disks | Yes, they hold the keys |
| End-to-end encrypted | The file itself, from your device to theirs | No |
Most services legitimately describe themselves as encrypted because they do the first two. That protects against someone tapping the network or stealing a hard drive. It does not protect against the provider, a breach of the provider, or a legal demand made to the provider.
How to tell if a service is really end to end
- Where is the key made? It should be generated on your device, not by the service.
- How does the recipient get it? In a link fragment, a password you share, or a key exchange between devices, but never stored by the service.
- Can the service preview your file? If it can show thumbnails, scan contents or recover your files without you, it can read them.
- Is the design published? Services that are end to end usually explain exactly how.
How WispFile encrypts a transfer
- When you create a link, your browser generates a random 256-bit key with the Web Crypto API.
- The key goes into the link after the
#. Browsers keep this fragment to themselves: it is never included in requests to WispFile, and WispFile never logs it. - Each 256 KB piece of each file is encrypted with AES-GCM and a fresh random IV before it leaves your device, and carries a SHA-256 fingerprint of its contents.
- The recipient’s browser decrypts each piece, checks the fingerprint, and writes it to disk. A piece that fails is requested again.
On top of this, the direct browser connection is itself encrypted by WebRTC (DTLS). That protects the connection; WispFile’s own layer protects the file even if something in the middle (a relay, or a compromised signaling server) were hostile.
Adding a password
Anyone with the whole link has the key. For a second lock, set a password: the link then carries the key wrapped with a key derived from the password (PBKDF2, 600,000 iterations, all in the browser). Share the password by a different channel than the link. A wrong password is detected in the recipient’s browser; nothing about it is ever sent to WispFile.
What end-to-end encryption does not do
It does not hide that a transfer happened, or the file names and sizes WispFile shows the recipient, or the network addresses of two devices that connect directly. And it cannot protect a file after it is decrypted on the recipient’s device. It removes the service from the list of parties who can read your file, which for most confidential handovers is the part that matters.
Further reading: NIST’s recommendation for GCM, and MDN on the Web Crypto API.
Frequently asked questions
What does end-to-end encrypted file transfer mean?
The file is encrypted on the sender’s device and can only be decrypted on the recipient’s, with a key that the service in between never has. The service can move or store the encrypted bytes, but cannot read them.
Is “encrypted in transit and at rest” the same as end to end?
No. In transit means the connection is encrypted (HTTPS); at rest means the stored copy is encrypted on disk. In both cases the provider holds the keys and can decrypt the file. End to end means the provider never has the key.
Where is the key in a WispFile link?
After the # in the link. That part, the fragment, is kept by the browser and never sent to any server in a request, so WispFile cannot see it. Anyone with the whole link has the key, which is why you can add a password as a second lock.
What happens if I lose the link?
Nobody, including WispFile, can recover the key. Create a new link and send it again; the files are still on your device.
Related guides
- Secure file transfer without cloud storage — Confidential documents, and why the safest copy is the one never made.
- WebRTC file transfer, explained — Signaling, NAT traversal, data channels and what can go wrong.
- Peer-to-peer file sharing: how it works and when it’s safe — P2P without the torrent baggage: what it is and what makes it safe.
Send it directly now
Open WispFile, add your files and share the link. No account, nothing uploaded, nothing stored. Free.
Send files with WispFile