End-to-end vs zero-knowledge encryption: what's the difference?

Q: What does each protect against?

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 E2EE for sharing (see below).

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, under your account key (the FEK), with a fresh random value for each file, and uploaded as opaque blobs. The server stores the encrypted blobs, the copies of your FEK wrapped under your password and your recovery phrase, and a bcrypt hash that checks your sign-in; it never sees your FEK in cleartext or any file contents. Since October 16, 2026, an up-to-date app signs in with a key derived from your password, not the password itself. During a transition of about two months, an account that hasn't signed in again yet, or an older app version, still sends the password (over HTTPS), where a compromised server could capture it.
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.
Sharing. Since this article was first published, Filarr has shipped sharing, and it is E2EE. A share link carries its key after the #, which a browser never sends to the server; a shared vault's key is sealed for each member's personal key pair, and the server only relays it sealed.

What Filarr's server can see: opaque encrypted blobs, blob sizes, sync timestamps, account email, the wrapped copies of your key, a bcrypt hash that checks your sign-in. What it cannot see: file contents, file names, folder structure, note titles, the names of shared vaults and share links, or your key in cleartext.

Read Filarr's full security architecture for the precise parameters and the threat model behind each design choice.