Feature

Client-Side Encryption: Encrypting Before the Network

Client-side encryption is a statement about *where* a computation happens. The algorithms are the same ones a server would use; the difference is that the plaintext and the key exist only on your machine, which changes who has to be trusted.

Last reviewed July 31, 2026Reviewed by Inkrypt Security Team

Client-side versus server-side, concretely

Both models produce encrypted data at rest. They differ in the window during which plaintext is visible to someone other than you.

The same note, under two architectures.
Stage	Server-side encryption	Client-side encryption
You type the note	Plaintext on your device	Plaintext on your device
Leaving your browser	Plaintext, wrapped in TLS	Ciphertext, wrapped in TLS
Arriving at the server	Plaintext, decrypted from TLS	Ciphertext — server cannot read it
Written to disk	Encrypted with the provider's key	Already encrypted with your key
Who can read it	You and the provider	Only whoever has the password

The same note, under two architectures.

The critical row is the third. Under server-side encryption there is a moment — however brief — when your plaintext exists in the provider's memory. Everything that touches that moment (application logs, error reporting, a debugging session, an APM tool capturing request bodies) is a potential exposure. Client-side encryption eliminates the moment entirely.

How Inkrypt does it in the browser

Encryption runs through the Web Crypto API — the browser's native cryptographic implementation, exposed as crypto.subtle. This matters for two reasons.

It is native code, not JavaScript. The primitives are implemented in the browser engine and are designed to avoid timing side-channels. A pure-JavaScript AES implementation is far harder to make constant-time.
Key material can be non-extractable. Keys derived through deriveKey are created with extraction disabled, so the key object cannot be read back out into JavaScript, even by our own code. It can be used to encrypt and decrypt, and nothing else.

API	crypto.subtle (Web Crypto)
Key derivation	PBKDF2-HMAC-SHA256, 310,000 iterations
Cipher	AES-256-GCM
Key extractable	false
Randomness source	Cryptographically secure browser RNG
Plaintext transmitted	Never

What client-side encryption costs you

Every property in that table is paid for. The costs are not hidden and you should weigh them before choosing this model.

No recovery. The provider cannot restore access, because the provider has no key. A forgotten password is a destroyed note.
No server-side features on content. Search, previews, format conversion, virus scanning, deduplication — anything requiring the server to read your data is off the table permanently.
Work happens on the weakest device. Key derivation runs on the user's hardware. Choosing 310,000 iterations means accepting a real pause on an older phone.
Trust shifts to code delivery. You no longer have to trust the provider with your plaintext, but you do have to trust the code they serve you. See the limitations section — we do not think this should be glossed over.

When server-side encryption is the better choice

If you need full-text search, multi-user collaborative editing, guaranteed account recovery, or server-side compliance scanning, server-side encryption with well-managed keys is a legitimate and often better answer. Client-side encryption is not universally superior — it is superior for a specific set of goals.

How to check whether a service really does this

Open your browser's developer tools, go to the Network tab, and create an item. Inspect the outgoing request body — if you can read your own text in it, encryption is not happening client-side.
Look for a password-reset flow that preserves existing content. Its presence tells you the provider holds a key.
Check whether the service can search inside your content. If it can, it can read it.
Read the security documentation for named algorithms and parameters. A service doing this properly will state them; one that talks only about "bank-level encryption" is telling you nothing.

That first test works on Inkrypt too, and we would rather you ran it than took our word for it.

Frequently asked questions

Is client-side encryption the same as end-to-end encryption?

They overlap but are not identical. End-to-end encryption describes a message readable only by sender and recipient. Client-side encryption describes where the operation runs. Inkrypt is client-side encrypted, and behaves end-to-end when you share a note, since only password-holders can read it.

Can I verify that my text is encrypted before upload?

Yes. Open your browser's developer tools, watch the Network tab while saving a note, and inspect the request body. You will see a base64 ciphertext blob, a salt and an IV — not your text.

Does encryption in the browser slow things down?

The AES step is effectively instant. The noticeable part is key derivation — 310,000 PBKDF2 iterations — which takes a moment on slower devices. That cost is the point: it applies to every attacker guess as well.

What happens if JavaScript is disabled?

Encryption cannot run, so the notepad cannot function. This is inherent to browser-based cryptography: the code performing the encryption is the code that has to execute.

Is the encryption key ever sent to your servers?

No. The key is derived in the browser and created as a non-extractable CryptoKey, meaning it cannot be read out of the browser's crypto layer into JavaScript at all — including by our own code.

Write your first encrypted note

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

Open the notepad