End-to-end vs zero-knowledge encryption: what's the difference?
End-to-end encryption and zero-knowledge encryption are often used interchangeably, but they describe different things. Here's the precise difference, where they overlap, and which one to look for in your messaging app, password manager, and notes app.
Mathis Belouar-Pruvot
Quick Answer. End-to-end encryption (E2EE) is a property of communication: only the two endpoints can read the message; intermediates cannot. Zero-knowledge is a deployment model for storage: the server keeps your data encrypted with keys it doesn't have. Most modern privacy-first services implement both — Signal is E2EE for chat, Filarr is zero-knowledge for cloud sync. The terms overlap but aren't synonyms.
The two terms are used interchangeably in marketing copy, security blog posts, and even academic papers. They aren't the same thing.
This article gives the precise definition of each, shows where they overlap, where they don't, and how to evaluate the encryption claims of any privacy-focused service.
What is end-to-end encryption (E2EE)?
End-to-end encryption is a property of communication systems. The definition is simple: only the two endpoints can read the content; any intermediate system handling the message cannot.
The canonical example is Signal Messenger. When you send a message:
- Your phone encrypts the message with a key the recipient's phone holds (and that Signal's servers do not)
- The encrypted blob travels through Signal's servers
- The recipient's phone decrypts it
Signal's servers see encrypted bytes go in, encrypted bytes go out. They never see plaintext. Even if they wanted to, they could not — the keys never leave the user devices.
E2EE is not just about messaging. The same property applies to:
- Voice and video calls (Signal, FaceTime, WhatsApp)
- Email (Proton Mail, Tutanota)
- File sharing (Wormhole, Magic Wormhole, OnionShare)
- Collaborative editing (some E2EE-capable Google Docs alternatives)
The defining feature is always the same: the data is encrypted by one endpoint and decrypted only by the other endpoint. Servers in between are blind couriers.
What is zero-knowledge encryption?
Zero-knowledge encryption is a property of storage services. The definition: the server stores your data encrypted with keys it does not have.
Compared to E2EE, zero-knowledge has a different shape:
- E2EE is a property of a one-to-one or one-to-many communication between users
- Zero-knowledge is a property of a single user's relationship with their cloud storage
The textbook example is Bitwarden. Your password vault is encrypted on your device with a key derived from your master password. The encrypted vault is uploaded to Bitwarden's servers. They store an opaque blob. When you log in from another device, your master password decrypts the vault locally — Bitwarden's servers never see it.
Other zero-knowledge services: 1Password, Proton Drive, Tutanota Calendar, Filarr's cloud sync, Cryptomator (combined with any cloud).
If you re-frame zero-knowledge as a "communication" between your past self (when you uploaded) and your future self (when you download on a new device), it becomes a special case of E2EE. But the deployment patterns, threat models, and engineering challenges are different enough to warrant a different name.
Where do E2EE and zero-knowledge overlap?
In practice, modern privacy-first services often implement both at once.
A typical encrypted notes app:
- Uses zero-knowledge for personal storage — your notes are stored on the server encrypted, and the server can't read them
- Uses E2EE when you share a note with another user — the share link or invitation contains an encrypted key only the recipient can decrypt
So a single product can be both. Filarr, for instance, is zero-knowledge for storage (your encrypted blobs sit on Cloudflare R2 and the Filarr servers can't read them) and would be E2EE for any future sharing feature.
Where do they not overlap?
Three concrete cases.
E2EE without zero-knowledge. A messaging app that doesn't store messages on the server (or only stores them encrypted briefly for delivery). Signal is E2EE; the server keeps almost nothing.
Zero-knowledge without E2EE. A personal vault with no sharing or communication features. A solo Bitwarden user, a solo Filarr user without any sharing — the data is zero-knowledge encrypted on the server, but there's no "other endpoint" because there's no communication.
Neither. Most cloud services. Google Drive encrypts at rest, but Google holds the keys. Dropbox the same. iCloud the same (except for items behind Apple's Advanced Data Protection toggle, which is zero-knowledge).
Why does the distinction matter for users?
The distinction matters when you evaluate a privacy claim. Consider these statements:
"We use end-to-end encryption to protect your data."
This makes sense for a messaging app. For a notes app or password manager that stores data in the cloud, "end-to-end encryption" is technically a stretch — the term properly applies to communication. The right claim is "zero-knowledge" or "client-side encryption with no server-side key access."
When marketing teams use "E2EE" for storage products, it usually means the same thing as zero-knowledge in practice, but the looser usage can hide gaps. Read the architecture documentation, not the marketing page.
"Your data is encrypted in transit and at rest."
This says nothing about who holds the keys. A service can encrypt at rest with keys it controls — that's standard cloud security, not zero-knowledge. Always ask: does the service hold a copy of the decryption key?
"We will never share your data."
A promise, not a guarantee. With zero-knowledge or E2EE, the service literally cannot share your data because it cannot read it. Without one of them, you're trusting the service to keep its promise even under legal pressure.
What does each protect against?
| Threat | E2EE protects? | Zero-knowledge protects? | Server-side encryption protects? |
|---|---|---|---|
| Network eavesdropping | ✓ | ✓ (with TLS) | ✓ (with TLS) |
| Server compromised by hackers | ✓ | ✓ | ✗ (keys are on the server) |
| Service operator reads your data | ✓ | ✓ | ✗ |
| Government subpoena to the service | ✓ | ✓ | ✗ |
| Employee with database access | ✓ | ✓ | ✗ |
| Endpoint malware on your device | ✗ | ✗ | ✗ |
| Lost password / lost recovery key | ✓ but data unrecoverable | ✓ but data unrecoverable | ✗ (service can reset) |
Both E2EE and zero-knowledge offer the same threat protections in their respective domains. The difference is the what — communication vs storage — and the how.
What questions should you ask before trusting a service?
A short checklist when a service claims E2EE or zero-knowledge:
- Where is the key derivation documented? A serious service publishes its KDF parameters (Argon2id memory, PBKDF2 iterations) in its security or technical docs.
- What does the server see? Encrypted blobs, fine. Filenames in plaintext? Folder structure? Subject lines? Each leaked metadata point is a potential side channel.
- What happens on password reset? If the service can reset your password and let you back into your data, it's not zero-knowledge. Real zero-knowledge means lost password = lost data (recoverable only via your own recovery code).
- Is the code open source or audited? A claim with no public proof is a marketing claim. Independent audits and open code make claims verifiable.
- How does sharing work? If the service supports sharing, the sharing model should preserve E2EE — the server should never see the shared content unencrypted.
Apply these to any encrypted service before trusting it with your data.
How does Filarr classify on this scale?
Filarr is a local-first workspace where the cloud sync is zero-knowledge. To map onto the framework above:
- Local-first first. Your files live on your disk encrypted. No server is involved for the local app to work — there is no "communication" or "storage" for the cloud to mediate.
- Zero-knowledge cloud sync. When you opt in to cloud sync, your files are encrypted with AES-256-GCM using per-file FEKs, and uploaded as opaque blobs. The server stores the encrypted blobs and a password verifier; it never sees your password, your master key, or any file contents.
- Multi-device pairing. When you pair a new device, your existing device sends your master key to the new device through an ECDH handshake — encrypted by an ephemeral session key the server cannot derive. The server passes the encrypted key bytes through, sees nothing useful.
- No sharing yet. Filarr does not currently support sharing files between users. When sharing ships, it will be E2EE — keys will be exchanged client-to-client, not via the server.
What Filarr's server can see: opaque encrypted blobs, blob sizes (padded to bucket sizes), sync timestamps, account email, a password verifier. What it cannot see: file contents, file names, folder structure, note titles, anything else.
Read Filarr's full security architecture for the precise parameters and the threat model behind each design choice.