End-to-End Encrypted File Sharing Explained

End-to-end encryption is one of the most overused security terms in tech marketing. Plenty of services slap "E2EE" on a landing page when they really mean "we have HTTPS." Understanding the actual definition — and how to spot the fake versions — protects you from paying for something that isn't there.

The clean definition

End-to-end encryption means the data is encrypted on the sender's device, stays encrypted everywhere in transit and storage, and is only decrypted on the recipient's device. No party in the middle — including the service hosting the file — can read the contents.

That last clause is the whole point. Encryption-in-transit (HTTPS) and encryption-at-rest both leave the service provider holding the keys. They can read whatever they want, whenever they want. E2EE removes that possibility through math.

How it works on Zippd

Step by step:

1. You pick a file. Your browser generates a random 256-bit AES key.
2. The browser gzips and encrypts the file in chunks using AES-256-GCM. The plaintext is gone from RAM almost immediately.
3. Encrypted chunks PUT directly to S3-compatible storage. The server never holds an unencrypted byte.
4. The key gets base64-encoded and tucked into the URL fragment after #k=. Browsers never send fragments to servers.
5. You share the URL. Recipient's browser reads the fragment, fetches ciphertext, decrypts locally.

The key existed only on your device and your recipient's. Our infrastructure never had it. Subpoena us and we hand over ciphertext — useless without the key.

How to spot fake E2EE

Three tells when a service claims E2EE but doesn't deliver:

• Share URLs don't contain a key fragment. If the URL is short and clean (example.com/abc123), the server is doing the decryption. Real E2EE leaves a key in the URL.
• Server-side preview features. If the service can show a thumbnail or extract text from your encrypted file, they decrypted it. End of E2EE.
• "Password reset" for encrypted content. Real E2EE means losing the key loses the file. If they can reset your access, they have the key.

Why this matters beyond paranoia

E2EE protects against threats that "regular encryption" doesn't:

• Vendor data breaches. Even if our database leaked tomorrow, attackers would have only ciphertext blobs.
• Insider threats. A rogue employee with database access still can't decrypt your files.
• Legal compulsion. Subpoenas force us to hand over what we have. We have ciphertext.
• Service shutdown. If we ever shut down badly, no abandoned plaintext archive sits on someone's drive.

E2EE vs encryption at rest vs encryption in transit

The tradeoffs E2EE imposes

Real E2EE costs you some convenience features:

• No server-side search inside files. Can't index what we can't read.
• No "recover my lost file" button. Lose the key, lose the file. More on that here.
• No content scanning for abuse. We rely on download-page abuse reports and aggressive expiry instead.
• No "preview before download." The recipient must download to see the contents.

That's the deal. Privacy by design has costs. They're acceptable for the kind of files you should be sending E2EE in the first place.

FAQ

Is HTTPS the same as end-to-end?

No. HTTPS protects the network between you and the server. After the server receives your file, it can read it freely. E2EE prevents that.

How is this different from Mega's encryption?

It's not. Both use the same model (key in URL fragment, browser-side crypto). Zippd uses AES-256 instead of AES-128. Detailed comparison.

Can you legally be forced to break it?

A subpoena can force us to disclose what we have. We have ciphertext and an opaque metadata blob. We literally do not possess the key, so no court order can extract it from us.

Why don't all services do this?

Because content scanning is part of how they monetize (ads, "service improvement," AI training) or moderate (abuse, copyright). E2EE removes that lever. We chose the privacy tradeoff. Most consumer-grade services don't.

Try a real E2EE send

Upload a file on the homepage. Look at the URL afterward — the #k=... is your key, and it never reached us.