End-to-End Encryption Explained: A Beginner's Guide

End-to-end encryption (E2EE) means your file is scrambled on your device with a key that only the recipient can reconstruct. The transfer service moves ciphertext but never holds the decryption key, so staff, hackers, and government subpoenas can't read the contents. In practice, your browser generates a random 256-bit AES key, encrypts the file locally, uploads the ciphertext, and places the key in the share link after the # fragment — which browsers never send to the server. That's the whole trick, and it's what separates real privacy from marketing copy.

What "end-to-end" actually means

The two "ends" are you and your recipient. Everything between — ISP routers, CDN edges, the transfer company's servers, the recipient's ISP — sits in the middle. With E2EE, those middle hops see only encrypted bytes. Compare this to transport-layer encryption alone (TLS): TLS protects data from your browser to the server, then the server decrypts it, stores plaintext, and re-encrypts when the recipient downloads. WeTransfer's standard tier works this way. The company can (and by US and EU law sometimes must) hand over files on request.

With E2EE, even if a prosecutor hands the provider a warrant, the provider has nothing to surrender except random-looking bytes. That property is why journalists, lawyers, and doctors increasingly insist on it.

Why TLS alone isn't enough

TLS 1.3 is excellent at what it does: preventing a coffee-shop attacker or a rogue ISP from snooping on the connection. But TLS terminates at the server. Once the encrypted tunnel ends, the server processes the raw file. If that server is breached — as happened to Dropbox in 2022 when source code and some customer data leaked — TLS offers zero protection for files sitting in storage.

E2EE adds a second layer that survives server compromise. The file is encrypted before it touches the wire and stays encrypted until the recipient's browser decrypts it. Even a full database dump reveals only ciphertext and metadata.

The key exchange problem, solved

The tricky part of E2EE is getting the key to the recipient without the server seeing it. Modern browser-based services solve this with the URL fragment trick. A share link looks like:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

Browsers treat everything after # as a client-side fragment. When you click the link, the server receives only /download/abc123 in the HTTP request — the fragment never leaves your browser. JavaScript then reads the key from the fragment, fetches the ciphertext, and decrypts it locally using the Web Crypto API's crypto.subtle.decrypt().

This is simpler than RSA key exchange or Diffie-Hellman and works for anyone with a browser. The tradeoff: anyone who gets the link gets the file, so you still need to share links through a secure channel (Signal, in person, an encrypted email).

What the server sees vs. what it can't

With properly implemented E2EE, the server logs typically contain: a random file ID, ciphertext size, upload IP, upload timestamp, and the SHA-256 hash of the ciphertext for deduplication. It does not see: the filename, the file contents, the recipient's identity, or the decryption key. Filenames are often encrypted alongside the content and stored as part of the ciphertext header.

A useful test: ask the provider what they'd turn over under a warrant. An honest E2EE service will say "encrypted blobs and IP logs." If they can produce plaintext files, the encryption isn't end-to-end.

Algorithms under the hood

Real E2EE stacks converge on a short list of well-audited primitives:

• AES-256-GCM for bulk file encryption. GCM provides both confidentiality and authentication, so tampered ciphertext fails to decrypt rather than producing garbage.
• PBKDF2 with at least 100,000 iterations, or Argon2id, for deriving keys from user passwords when password protection is added.
• SHA-256 for integrity hashes.
• TLS 1.3 as the outer transport, because belt-and-suspenders is cheap.

Avoid services still using AES-CBC without HMAC (malleable), MD5 or SHA-1 (broken), or PBKDF2 with under 10,000 iterations (brute-forceable on modern GPUs).

E2EE for file transfer vs. messaging

Signal popularized E2EE for chat using the Double Ratchet protocol, which rotates keys after every message for forward secrecy. File transfer doesn't need that complexity because it's one-shot — you're not maintaining an ongoing conversation. A single symmetric key per file, generated fresh for each upload, is both simpler and easier to audit.

What file transfer needs that messaging doesn't: resumable chunked uploads (files can be 10 GB), integrity verification across chunks, and links that work without the recipient having an account. Tresorit, Proton Drive, SwissTransfer, and HexaTransfer all take this approach with minor variations.

Checking if a service is really end-to-end

Four practical tests before you trust a provider:

1. Open DevTools → Network while uploading a small file. If you see the plaintext in the request body, it isn't client-side encrypted.
2. Look for the key in the URL fragment (after #). No fragment key usually means the server holds the key.
3. Read the privacy policy for language like "we cannot access your files" paired with a technical description of why.
4. Check whether the client code is auditable — open source or at least documented. Closed binaries with E2EE claims are a yellow flag.

Services that pass all four: SwissTransfer (client-side encryption tier), Tresorit Send, Proton Drive share links, and HexaTransfer.

What E2EE doesn't protect against

E2EE is not magic. It doesn't protect you from:

• A compromised endpoint. If your laptop has malware, the attacker reads files before encryption.
• Leaked share links. Anyone with the link can download and decrypt.
• Weak passwords on password-protected transfers. PBKDF2 slows brute force, but "summer2024" still falls in seconds.
• Metadata correlation. Timestamps, file sizes, and IP addresses can still tell a story.

Pair E2EE with expiring links (24 hours is a sensible default), download limits (often 1–10 downloads), and strong passwords for sensitive transfers.

Putting it to use

For a quick sanity check: upload a 5 MB test file, open the share link in a private window without the fragment (delete everything after #), and try to download. A real E2EE service will fail to decrypt. If the file opens anyway, the server held the key all along.

Try it at hexatransfer.com — free, no account, 10 GB max.