What is end-to-end encryption?

A plain-language explanation of end-to-end encryption — how it works, what it protects, and how it differs from “encryption in transit”.

End-to-end encryption (E2EE) is a method of protecting data so that only the sender and the intended recipient can read it. The information is encrypted on the sender's device and can only be decrypted on the recipient's device — everything in between (servers, networks, relays) sees nothing but unreadable ciphertext.

End-to-end encryption, defined

With E2EE, the “ends” are the two devices in a conversation or transfer. The encryption keys exist only on those devices. Because no one in the middle holds the key, no one in the middle can read the content — not the service provider, not your internet provider, not an attacker who breaches a server.

How end-to-end encryption works

A unique encryption key is generated on the sender's device.
The file (or message) is encrypted with that key before it leaves the device.
Only ciphertext travels across the network and through any servers.
The recipient's device uses the key to decrypt the data locally.

The security rests on one thing: the key must reach the recipient without passing through a server in a readable form. Well-designed tools solve this — for example, by placing the secret in the part of a link (the URL fragment, after #) that browsers never send to a server.

End-to-end encryption vs “encryption in transit”

These are often confused. Encryption in transit (HTTPS/TLS) protects data on the hop between your device and a server — but the server decrypts it and can read it. End-to-end encryption keeps the data unreadable to the server too. Most file-sharing services use encryption in transit and “at rest”, which still leaves a readable copy under the provider's control. E2EE removes that exposure entirely.

What it protects — and what it doesn't

Protects: the content of your files from anyone but the recipient.
Doesn't automatically hide: some metadata (that a transfer happened, its rough size, timing). Privacy-focused tools minimise this too, but E2EE is specifically about content.
Depends on key handling: if the provider can obtain the key, it isn't truly end-to-end.

Why it matters for file transfers

When you send a file, the real question is who can read it along the way. With end-to-end encryption and no stored copy, the answer is: only your recipient. That's exactly how SaferDrop works — files are encrypted in your browser with AES-256-GCM and stream directly to the recipient, so no server ever holds a readable copy. Learn the practical steps in our guide on how to send files securely.

Frequently asked questions

Is HTTPS the same as end-to-end encryption?

No. HTTPS (TLS) encrypts data in transit between your device and a server — but the server can still read it. End-to-end encryption means only the sender and recipient can read the data; every server and network in between sees only ciphertext.

Can the service read my files if they're end-to-end encrypted?

Not if it's done properly. In genuine end-to-end encryption the decryption key never reaches the service, so it cannot read your files even if compelled to. This is sometimes called zero-knowledge.

What encryption does SaferDrop use?

SaferDrop encrypts every transfer with AES-256-GCM, a strong, authenticated encryption standard. A unique key is generated in your browser for each transfer and never sent to our servers.

Is end-to-end encryption enough on its own?

The algorithm is only half the story — what matters is who holds the key. Strong encryption with a key the provider can access is not truly private. Always check where the key lives.

Send a file securely in seconds.

End-to-end encrypted, browser to browser, never stored. No account needed to receive.

Send a File