Zero-knowledge encryption
AES-256-GCM in the browser, PBKDF2-SHA-256 (300k) key derivation. The decryption key lives in the URL fragment (#…) and never touches our servers.
Sealed Transfer
End-to-end encrypted transfers
thesend.app Sealed Transfer is a separate paid add-on for medical, legal and other high-trust workflows. Your browser encrypts files with AES-256-GCM before upload. Our servers never see the plaintext, the PIN, or the original filename.
PIN on top of the link
A 6+ digit PIN is baked into the key derivation. The link alone is never enough. 5 wrong PINs → 15-minute lock.
Mandatory recipient verification
Each invited email must confirm ownership with a 6-digit one-time code (10-min validity, 5 attempts) before decryption metadata is released.
Per-transfer audit log
Every open, OTP request, PIN attempt and download is logged with hashed IP/UA. Export to CSV from /account/sealed-transfer.
Sensible defaults
1–10 recipients per transfer, per-recipient download quota (default 3, max 10), expiry up to 30 days, 5 GB payload cap.
Sealed Transfer · two tiers of encryption
Tier 1
Standard
Encrypted by default — every transfer
- · TLS 1.2+ in transit
- · AES-256 at rest
- · EU hosting (Cloudflare R2)
Included in every thesend.app transfer
Tier 2 · upgrade
Sealed Transfer
End-to-end · zero-knowledge — even thesend.app can't open it
- · AES-GCM-256 in the browser
- · Key derived from PIN + URL fragment
- · Key never reaches our server
Add-on · included with Pro & Brand
Sealed Transfer
What makes Sealed Transfer different?
Every file you send through thesend.app is already encrypted in transit and at rest — the same level WeTransfer, Dropbox and SwissTransfer provide. Sealed Transfer goes one step further: end-to-end, zero-knowledge. Even thesend.app cannot open your file.
| What we compare | Tier 1 · StandardStandard transfer (thesend.app · WeTransfer · Dropbox) | Tier 2 · Sealed TransferSealed Transfer (thesend.app) |
|---|---|---|
| Encryption in transit | TLS 1.2+ | TLS 1.2+ |
| Encryption at rest | AES-256 on the server | AES-GCM-256, key derived in the browser |
| Who holds the decryption key? | The hosting provider | Only sender and recipient |
| Can thesend.app open the file? | Technically yes, with server access | No — mathematically impossible |
| Filename visible to the server? | Yes | No, encrypted |
PIN + URL fragment together derive the key via PBKDF2-SHA-256 (300k iterations). The fragment (after #) never reaches our server. The PIN is shared through a separate channel.
How is Sealed Transfer different from WeTransfer, Dropbox or a normal transfer?
Every thesend.app transfer is already encrypted in transit (TLS) and at rest (AES-256), on EU infrastructure. That matches WeTransfer or Dropbox. Sealed Transfer adds end-to-end, zero-knowledge encryption: the file is encrypted in your browser with AES-GCM-256 using a key derived from your PIN + a URL fragment secret. thesend.app, Cloudflare R2, or anyone with database access only sees ciphertext — the file cannot be decrypted without the PIN and the fragment (which never touches our server).