How SendMe encrypts your file in transit and at rest
A non-jargon explanation of the encryption layers that protect your transfers.
When you upload a file to SendMe, three different protections are wrapped around it. Understanding these helps you know exactly what is — and isn't — guaranteed.
Layer 1 — TLS 1.3 in transit
From the moment your browser starts uploading until the bytes arrive at our servers, the connection is encrypted with TLS 1.3 (the modern HTTPS standard). Anyone sniffing your Wi-Fi or sitting on the network path sees only ciphertext. The same applies on the receiver's side.
Layer 2 — Object-storage encryption at rest
We store your file on encrypted object storage (AES-256-GCM). Even if someone walked into the data centre and copied the raw disks, the file would be unreadable without our key-management infrastructure.
Layer 3 — Non-guessable URLs
Internally, your file lives at a path like /sendme/transfers/{transfer_id}/{uuid}.{ext}. Nobody — not even the receiver — sees this URL. Receivers only see your 6-digit code; our backend translates that to the storage path on demand.
What this does NOT protect against
End-to-end encryption (E2EE) is not yet enabled by default. That means we, the operators, have technical access to your file while it sits on our servers. We don't read it, we don't index it, and we don't train models on it — but we could, if compelled by lawful order. For truly secret content, layer additional client-side encryption on top: encrypt the file with a tool like 7-Zip + AES-256, then send the encrypted archive through SendMe, and share the archive password separately.
E2EE-by-default is on our 2026 roadmap. Pro subscribers will get early access.