What is client-side encryption?

The short answer

Client-side encryption means your data is encrypted on your own device — your browser, your phone, your laptop — before it is sent anywhere. The "client" is the software in front of you. Because the scrambling happens on your side, the server receives data that is already locked, and never sees the readable original.

It is the opposite of server-side encryption, where you send your data in the clear and the server encrypts it after it arrives. With server-side encryption, there is a moment when the provider can read everything. With client-side encryption, there is no such moment.

How it works

Picture saving a note: "Settlement offer — £40,000." Follow it from your screen to the server.

1. Your device already has a key. It was derived from your password earlier, using a key derivation function such as Argon2id, and it lives only in your session — never on the wire.
2. You hit save. The app encrypts the note locally with authenticated encryption such as XChaCha20-Poly1305. "Authenticated" means the ciphertext is also tamper-evident: if a single byte is altered in storage or transit, decryption refuses to proceed.
3. "Settlement offer — £40,000" becomes ciphertext — something like "k7Qx…9fA". This locked block is what crosses the network.
4. The server stores the locked block. It can hold it, replicate it and send it back, but it cannot open it. The readable note never existed outside your device.
5. Later, your device pulls the block back and decrypts it locally, and only then do the words reappear — on your screen, for your eyes.

Sharing keeps the same shape. To share with a colleague, your device wraps the item's key for them using a key exchange such as X25519. The key travels from your device to theirs, encrypted the whole way, so the server still never sees a usable key.

What it changes

Client-side encryption removes the provider from the list of people who can read your data. That single change reshapes the risks that keep teams awake.

• Network snooping fails. Anyone intercepting traffic sees only locked blocks, even if other protections were misconfigured.
• A server breach leaks ciphertext. Stealing the database yields scrambled blocks, not your offers, contracts or records.
• Insiders are locked out. A system administrator with full access to the servers still cannot turn the stored blocks into words.

A note on doing useful work

A fair worry is that locking everything on your device makes the app useless. If the server cannot read your data, how can it search it, sort it, or run features on it? The answer is that the work moves to where the data is readable: your device. After your browser decrypts the note, it can search, index and display it locally, in your unlocked session. The server stays blind; your screen stays smart.

This is why the cost of client-side encryption is mostly engineering effort, not lost features. The hard part is rebuilding search, sharing and collaboration to run over data the server cannot see — not deciding to give those features up.

Client-side encryption vs zero-knowledge

These two are easy to confuse because they travel together. Client-side encryption is the act — locking data on your device. Zero-knowledge is the result at the system level — a provider that holds the locked data but none of the keys. You need client-side encryption to build a zero-knowledge product, but client-side encryption alone is not enough. If the app encrypts on your device and then quietly hands the key to the server, the data is locked but the provider can still open it.

So the test is not just "does it encrypt on my device?" but "where does the key go afterwards?" A true client-side, zero-knowledge design keeps the key with you. The deep dive on our <a href="security">security page</a> shows exactly where keys are made and where they stay.

One more honest point: client-side encryption protects data, not your device. If someone is sitting at your unlocked laptop, or your browser is infected, they see what you see — because at that moment the data is decrypted in front of you. That is not a flaw in the idea; no encryption can protect a screen you have already opened. It just means client-side encryption pairs with the ordinary habits that protect the device itself: a screen lock, a strong password, a patched browser.

Why it is the foundation

Almost every honest privacy promise rests on this one move: encrypt before you send. Get it right and the server becomes a place that stores noise on your behalf. Get it wrong and every other control is just a fence around an unlocked door. Zeromatics performs encryption in the browser, before your data leaves it, across every product — but the principle is universal, and worth checking for in any tool that touches sensitive work.