Back to Security Insights

Why we encrypt in the browser (and what happens to your password)

Client-side encryption isn’t just a feature—it’s the only way we can promise we never see your data.

Inkrypt · Security Insights

Encryption happens in your browser using the Web Crypto API. Your password never leaves your device. We derive a key from it with PBKDF2, use that key for AES-256-GCM, and send only the ciphertext and the public parameters (salt, IV) to the server. The key is discarded after the request.

What “client-side” actually means

It means the critical operations—key derivation and encrypt/decrypt—run in JavaScript in the user’s tab. We don’t have a “secure server” that does crypto for you; that would require sending your password or key to us. So we never see plaintext or keys.

Trade-offs we accepted

We can’t do “forgot password” or “reset via email.” We can’t search your notes on the server. We can’t show you a list of your notes unless you had a way to authenticate (we don’t). Those limitations are the direct result of not having your key—and we’re fine with that.

FAQ: Why we encrypt in the browser

Q1. Why not just encrypt on the server?

If we encrypted on the server, we’d need your password or key there, which means we—or an attacker or legal request—could decrypt your notes. Browser-side encryption keeps keys on your device only.

Q2. How does browser encryption actually work?

We use the Web Crypto API to run PBKDF2 on your password (310k iterations) and derive a key, then encrypt with AES-256-GCM using a fresh IV. Only ciphertext, salt, IV, and parameters go to the server.

Q3. Does encrypting in the browser make things slower or less reliable?

There’s a small, intentional delay during key derivation, but on modern hardware it’s still fast enough for note-taking. The benefit is a much smaller trust surface.

Q4. What features do we give up by encrypting client-side?

We can’t do server-side search across notes, can’t reset passwords, and don’t maintain a list of your notes tied to an account. Those missing features are trade-offs we accept for zero-knowledge.

Q5. Is browser-based crypto really safe?

Used correctly, the Web Crypto API with standard algorithms like AES-256-GCM and PBKDF2 is significantly safer than rolling our own crypto. The main remaining risks are compromised endpoints and malicious extensions, not the primitives themselves.

Where to go next

To explore more of the implications of client-side, zero-knowledge encryption: