Zero-Knowledge vs End-to-End vs Encrypted at Rest: The Concrete Differences (2026)

You are comparing two note apps, two cloud drives, or two backup tools. Both say "encrypted." One says "encrypted at rest with AES-256." Another says "end-to-end encrypted." A third says "zero-knowledge." They sound like three ways of saying the same thing. They are not. The practical question underneath all three is simple: if this company is hacked tomorrow, or gets a court order, can a human being read your files? That single question separates the three terms, and the answer changes what you should trust a tool with.

This guide explains the three terms in plain language, shows exactly what leaks in each model when things go wrong, and gives you a short checklist to tell marketing copy from real protection.

Quick Answer

Encryption at rest means your data is stored scrambled on the provider's disks, but the provider holds the keys and can decrypt it at will (to index it, show it in a web app, or hand it to authorities). End-to-end encryption (E2EE) means data is encrypted on your device and only decrypted on the recipient's device, so intermediaries in transit and storage never see plaintext. Zero-knowledge describes the same guarantee from the provider's point of view: the service literally cannot read your data because the key never reaches it. In short: encryption at rest protects against a stolen hard drive; end-to-end and zero-knowledge protect against the provider itself. If a breach or subpoena hits, encryption at rest can expose readable documents, while a true zero-knowledge system exposes only unreadable ciphertext.

Why this distinction actually matters to you

Most people never think about encryption terminology until one of two things happens: they read about a data breach affecting an app they use, or they handle data that is not only theirs (client files, patient notes, source material, employee records). At that moment the marketing word "encrypted" stops being reassuring and starts being a question: encrypted from whom?

Here is the uncomfortable reality. Almost every serious cloud service encrypts data at rest. It is table stakes, and it protects against a narrow threat: someone physically steals a server or a decommissioned drive. It does essentially nothing against the threats people actually worry about in 2026: the provider being breached through its own live systems, a rogue employee, an overbroad government request, or the provider quietly scanning your content. That is because in the encrypted-at-rest model, the provider keeps the keys next to the locked data. A breach that reaches the running application usually reaches the keys too.

The terms end-to-end and zero-knowledge exist precisely to describe the stronger promise: the provider does not have the keys, so it cannot read your data even if it wants to, even if it is hacked, even if it is compelled. Understanding which promise a tool actually makes is the difference between "my documents leaked" and "unreadable noise leaked."

The three models, precisely

1. Encryption at rest

Data sitting on the provider's storage is encrypted with a symmetric cipher (usually AES-256). The provider owns and manages the keys, typically in a key management service. When you log in through a web app, the server decrypts your data to render it, re-encrypts it to store it, and can search or preview it because it holds the key.

• Protects against: stolen physical disks, lost backups, storage-layer theft.
• Does NOT protect against: the provider reading your data, an application-layer breach, a rogue admin, or a legal order compelling disclosure.
• Who has it: essentially everyone (Google Drive, Dropbox, Notion, iCloud by default). Notion, for example, encrypts at rest but holds the keys and is not end-to-end, which is exactly why the answer to "is Notion encrypted?" is "yes, but not from Notion."

2. End-to-end encryption (E2EE)

Data is encrypted on the sender's device and can only be decrypted on the intended endpoints. The classic frame is messaging (Signal): the two phones hold the keys, and everything between them (servers, network) sees only ciphertext. E2EE is fundamentally about who the endpoints are and guaranteeing nobody in between can read the payload.

• Protects against: interception in transit, server compromise, the provider reading message content.
• Watch out for: metadata (who talked to whom, when, file sizes) is often not covered, and "endpoints" can quietly include the provider if key handling is sloppy.

3. Zero-knowledge

Zero-knowledge is the same guarantee described from the storage provider's perspective: the service stores and syncs your data but has zero ability to read it, because the encryption key is derived from a secret (your password or passphrase) that never leaves your device in usable form. The server sees opaque blobs and nothing else. In practice, a well-built zero-knowledge storage app is client-side end-to-end encryption where one of the "ends" is just your own other devices.

• Protects against: provider breach, rogue employees, subpoenas, silent content scanning.
• The trade-off you must accept: if the key is truly only yours, then losing your password (with no recovery mechanism) can mean losing your data. That is the honest cost of the provider being unable to help you, because the same property that stops attackers stops the provider from resetting your access.

The terms overlap heavily and are often used loosely. If you want the precise boundary between the last two, we wrote a dedicated breakdown of end-to-end vs zero-knowledge encryption. The short version: end-to-end is about the communication path, zero-knowledge is about the provider's inability to read stored data. A tool can be one, both, or neither.

Side-by-side

	Encryption at rest	End-to-end (E2EE)	Zero-knowledge
Where data is encrypted	On the server	On your device	On your device
Who holds the key	The provider	The endpoints	Only you
Can the provider read it?	Yes	No (payload)	No
What leaks in a server breach	Readable data (if keys reached)	Ciphertext	Ciphertext
Survives a subpoena to the provider?	No, provider can hand over plaintext	Yes for content	Yes
Metadata protected?	Usually no	Often no	Depends on design
If you lose your password	Provider can reset	Depends	Often unrecoverable without a recovery key
Typical examples	Google Drive, Dropbox, Notion	Signal, WhatsApp	Proton, Standard Notes, Filarr

One nuance worth stating plainly: these are not mutually exclusive. A good zero-knowledge app is also encrypted at rest and also uses end-to-end principles. The distinction that matters is not "which of the three" but "does the provider hold a key that can read my data." If yes, you have encryption-at-rest-grade protection no matter what the marketing says. If no, you have the strong guarantee.

What actually leaks when things go wrong

This is the part that turns terminology into a decision. Imagine the same incident hitting each model.

Scenario: the provider is breached and the attacker reaches the live application layer.

• Encrypted at rest: the running app can decrypt, so the attacker's path often can too. Expect readable documents. Under GDPR this is typically a reportable personal-data breach.
• Zero-knowledge / E2EE: the attacker gets blobs. Without your key, the ciphertext is computationally useless. We walked through this exact contrast in what changes when your data leaks under local versus cloud encryption: one model leaks readable files, the other leaks noise.

Scenario: a lawful order lands on the provider.

• Encrypted at rest: the provider can comply and hand over plaintext.
• Zero-knowledge: the provider can only hand over ciphertext it cannot decrypt. It genuinely has nothing readable to give.

The honest caveat: zero-knowledge protects content, not necessarily metadata, and it never protects a device that is already compromised. If your laptop has malware while you are logged in and decrypted, no server-side model saves you. Encryption of stored data and endpoint security are different jobs.

What this means concretely: how to evaluate any tool

Marketing copy will not tell you the truth directly, so test the claims yourself with these questions:

1. Can you use the full product in a web browser with just a password, including previews and search across everything? If yes, the server almost certainly holds a usable key. That is closer to encryption at rest than zero-knowledge, whatever the homepage says.
2. When you reset your password, do you keep access to old data? If a simple password reset restores everything with no recovery key, the provider can decrypt your data. Real zero-knowledge systems force a trade-off here and give you a recovery phrase.
3. What algorithm and key derivation are named? Look for a named authenticated cipher like AES-256-GCM and a slow password-hashing function (PBKDF2 with a high iteration count, or Argon2). "Bank-grade encryption" with no specifics is a red flag.
4. Is there a per-file or per-item key hierarchy, or one global key? A two-layer design where each file has its own key wrapped by a master key limits the blast radius if one key is exposed. We explain why in KEK and FEK, per-file encryption explained.
5. Is the claim auditable? Open source, a public threat model, or a security whitepaper beats a marketing adjective. If the mechanism is described in enough detail that a skeptic could verify it (for example, a walkthrough of how the sync stays zero-knowledge in the actual code), that is a much stronger signal than a badge.

A practical rule of thumb: convenience and readability by the provider are two sides of the same coin. The more effortlessly a cloud service reads, previews, indexes, and reshares your content for you, the more certainly it can read it without you. That is not automatically bad (plenty of data does not need zero-knowledge), but you should choose it knowingly rather than assume "encrypted" meant "private from the company."

Where Filarr fits (honestly)

Filarr is a local-first encrypted workspace for notes and files, so it sits firmly in the zero-knowledge camp, and it is worth being precise about what that does and does not buy you.

Every file is encrypted on your device with AES-256-GCM using a separate key per file. Each per-file key (FEK) is wrapped by a master key (KEK) derived from your password via PBKDF2-SHA512 at 600,000 iterations (the OWASP 2024 guidance), with Argon2id available as an option. The data lives encrypted on your own disk first; cloud sync is optional. When you do sync, files are already encrypted before they leave the device, and the backend (Cloudflare R2) stores only opaque blobs. Your key never reaches the server in cleartext, which is what "zero-knowledge" means in the sync code. Recovery is handled by a 24-word BIP-39 phrase, which is the deliberate trade-off from the table above: the provider cannot reset your access for you, so you keep the phrase safe.

What Filarr does not do, and no encrypted app can: it does not protect a device that is already compromised while you are logged in, and it is not, by itself, GDPR compliance or legal advice. Encryption is one strong control inside a larger picture. It is also younger than Obsidian, has fewer plugins, and its mobile app is still in progress. If you are comparing options across the whole category, our honest guide to encrypted note apps in 2026 puts Filarr next to Standard Notes, Notesnook, Joplin, Proton Docs and others without pretending one tool wins every row.

Filarr is free forever for local use; optional cloud sync starts at 4 EUR per month.

FAQ

Is encryption at rest useless, then? No. It genuinely defends against stolen or improperly decommissioned physical storage, and it is a baseline you should expect from any serious provider. It simply does not protect you from the provider itself, from an application-layer breach, or from legal compulsion. Match the guarantee to your threat model.

Is zero-knowledge just a marketing word for end-to-end encryption? They overlap but describe different things. End-to-end is about the communication path (only the endpoints can read the payload). Zero-knowledge is about the storage provider's inability to read your data at all. A storage app can be zero-knowledge by applying end-to-end principles where your own devices are the endpoints.

If a zero-knowledge provider gets hacked, is my data safe? Your content is protected because the attacker gets ciphertext without your key. Two caveats: metadata (file names, sizes, timing) may not be encrypted depending on the design, and a truly zero-knowledge model cannot help if your own device was compromised while unlocked.

What happens if I forget my password on a zero-knowledge tool? That is the honest cost of the provider having no key: there may be no way to recover the data without a backup or a recovery key. Serious tools mitigate this with a recovery phrase (Filarr uses a 24-word BIP-39 phrase). Store it offline and treat it like the key to a safe.

How do I quickly tell which model a product uses? Check whether a plain web login gives full access with previews and search, and whether a password reset restores all your old data. If both are true, the provider can read your data (encryption-at-rest grade). If a reset requires a recovery key and the web experience is limited, it is likely genuinely zero-knowledge.