Feature

Zero-Knowledge Encryption: What It Means and How to Verify It

"Zero-knowledge" has become one of the most abused phrases in privacy marketing. Used precisely, it describes a system where the operator cannot read user content even if it wants to. Used loosely, it describes a company that has promised not to look.

Last reviewed July 31, 2026Reviewed by Inkrypt Security Team

A precise definition

A service is zero-knowledge with respect to your content when no key capable of decrypting that content ever exists on the provider's systems. Not stored, not held in memory during processing, not derivable from anything the provider has.

The test is not about intent or policy. It is about capability. If a provider *could* decrypt your data under some circumstance — a court order, a rogue employee, a new feature — it is not zero-knowledge, regardless of what its privacy page says.

A note on terminology

Cryptographers use "zero-knowledge proof" for a specific and different construction — proving you know something without revealing it. The industry's use of "zero-knowledge" to mean "provider-blind storage" is a borrowing, not the formal term. We use the industry sense throughout, and flag it because the two get conflated constantly.

How to verify the claim on any service

You do not need to read source code to apply real pressure to a zero-knowledge claim. Four questions do most of the work.

1. Can they reset your password and preserve your data?

This is the highest-signal question. If forgetting your password means the provider can restore access to your existing content, they hold a key. Some services offer recovery keys or escrowed keys — those are legitimate designs with real usability benefits, but they are not zero-knowledge.

2. Do they offer server-side search or previews?

Full-text search across your content, server-generated thumbnails, or content-based recommendations all require the server to see plaintext. A service can genuinely have these features, or it can genuinely be zero-knowledge. Claiming both should prompt a very specific technical explanation.

3. Where does the encryption run?

Look for a clear statement that encryption happens client-side, before transmission. Phrases like "encrypted in transit and at rest" describe TLS plus disk encryption — both good, neither zero-knowledge, because the provider handles plaintext in between.

4. What exactly is stored?

A service confident in this claim will tell you precisely which fields exist in its database. Vagueness here is informative.

How Inkrypt answers those questions

Our own answers to the four verification questions.
Question	Inkrypt	Detail
Can you reset my password and keep my note?	No	There is no key to re-encrypt with. Lost password means lost note.
Do you offer server-side search?	No	We cannot read note bodies, so we cannot index them.
Where does encryption run?	In your browser	Web Crypto API, before any network request is made.
What is stored per note?	Four fields	Ciphertext, salt, IV, and a key-derivation parameter label.

Our own answers to the four verification questions.

The full field-level breakdown, including what our request logs do and do not contain, is on the security architecture page.

The honest limitations of browser-delivered crypto

Any web application that encrypts in the browser shares one structural weakness, and a page like this is not credible unless it names it.

We serve the code that does the encrypting. Each time you load the page, your browser fetches JavaScript from our servers and runs it. A malicious or compromised operator could serve a modified script that quietly transmits your password. Nothing about client-side encryption prevents that, because the client-side code arrives from the server.

This is a real and well-documented limitation of web crypto generally — it applies to every browser-based encryption tool, not just this one. Installed applications with signed, verifiable builds have a meaningfully stronger position here.

What it means in practice: browser-based encryption protects you strongly against database breaches, network interception, and legal demands for content. It protects you less well against a provider that has itself been fully compromised at the delivery layer.
What partially mitigates it: Subresource Integrity, strict Content Security Policy, reproducible builds, and independent auditing all raise the cost of a silent script swap.
What actually resolves it: a signed, installable client that you can verify once and re-verify on update. That is a different product shape, and we would rather say so than imply we have solved a problem we have not.

Match the tool to the adversary

If your threat model includes a state-level adversary who could compel a service provider to serve you targeted code, no browser-based tool is the right answer — including this one. See our threat model for where we draw that line.

Frequently asked questions

Does zero-knowledge mean nobody can ever read my note?

It means the provider cannot. Anyone you give the password to can read it, anyone who guesses a weak password can read it, and malware on your own device can read the plaintext as you type. Zero-knowledge describes the provider's position, not universal secrecy.

How is this different from 'encrypted at rest'?

Encrypted at rest means the provider encrypts data on its own disks with its own keys — protection against stolen hardware, not against the provider. Zero-knowledge means the key never exists on the provider's systems at all.

Can Inkrypt be compelled to hand over my notes?

We can be compelled to hand over what we hold, which is ciphertext, a salt and an IV. We cannot be compelled to produce a key we have never possessed. This is why the guarantee is architectural rather than a policy commitment.

Is browser-based encryption as strong as a desktop app?

Against database breaches and network attackers, effectively yes — the same algorithms run either way. Against a compromised provider serving modified code, no: an installed app with a verifiable signed build is stronger, because you are not re-fetching the crypto code on every visit.

Why can't you offer search across my notes?

Searching text requires reading it. Because note bodies only exist as ciphertext on our side, there is nothing for us to index. This is a direct, unavoidable cost of the design.

Write your first encrypted note

No account, no email address, no download. Type a note, set a password, share the link.

Open the notepad