How browser encryption actually works in a private notepad

---

Disclosure: I built the notepad this article is about — Outsmart Notes. It comes up once, at the end, because the encryption design below is the one I shipped.

Most notes apps encrypt your notes "in transit and at rest", which sounds thorough until you ask the obvious question: at rest where, and who holds the key? If the server holds the key, the server can read your notes. The encryption protects you from everyone except the people running the service — which is exactly the party a private notepad should protect you from.

There is a stricter design: encrypt in the browser, with a key the server never sees. Here is how that actually works, and where it breaks.

1. The key never leaves the device

The vault is locked with a password you choose. That password is never sent to the server. Instead, the browser runs it through PBKDF2 — 100,000 iterations — to derive an encryption key. The iteration count is the point: it makes guessing the password expensive, even for someone who gets hold of the encrypted data.

The derived key lives in browser memory while the vault is open. It is never written to disk, never put in a cookie, and never sent in a request. When you close the vault, it is gone. Forget the password and there is no recovery — that is not a missing feature, it is the guarantee. A vault the operator can open for you is a vault the operator can open.

2. AES-GCM does two jobs at once

The cipher is AES-GCM with a 256-bit key. It encrypts the note and, in the same operation, produces an authentication tag — a short value that proves the ciphertext has not been tampered with. If a single byte changes, decryption fails loudly instead of silently returning corrupted text.

That matters because an attacker who can modify stored data is a realistic threat model for a web app: a compromised server, a malicious extension, a bad sync. Encryption without authentication would let tampered notes decrypt into garbage you might trust. GCM makes tampering detectable, not just unreadable.

3. Sharing without sharing the key with the server

Encrypted sharing has a harder problem: how do you send someone an encrypted note without giving the server the key? The answer is the URL hash. The encryption key travels in the fragment after the # in the link — and browsers never send the fragment to the server. The server stores the ciphertext and serves the page; the recipient's browser reads the key from the hash, fetches the ciphertext, and decrypts locally.

The server sees an opaque blob and a request for a page. It cannot decrypt the note, because it never receives the key. The trade-off is real too: anyone with the link has the key, so a shared link is only as private as the channel you send it through. Treat it like a password, not a permalink.

4. Local-first is the other half of private

Encryption is only half the design. The other half is where notes live by default: in the browser, in IndexedDB, on your device. Notes are stored locally first and synced only when you choose to. That means the ordinary case — writing, reading, searching your own notes — involves no server at all.

Local-first also changes the failure modes. There is no account to breach for notes that were never uploaded, and no outage that locks you out of your own writing. The cost is the same as the vault's: the device is now part of the trust boundary. Clear browser data and local-only notes go with it, so export matters — JSON or plain text, on your terms.

5. What this design does not protect you from

Honest limits, because a privacy claim that hides them is worse than no claim:

• It does not protect you from your own device. Malware, a compromised browser, or someone looking over your shoulder bypasses encryption entirely.
• It does not protect you from a weak password. PBKDF2 slows guessing; it cannot save "password123".
• It does not make shared links private. The key is in the link, so the link is the secret.
• It does not hide metadata. The server can still see that you use the service, when, and how much data you store — just not what it says.

A notepad that is honest about those limits is more trustworthy than one that claims "military-grade encryption" and stops there.

The test that matters

Ask any notes app three questions: who holds the key, where does decryption happen, and what happens if I forget my password? If the answers are "we do", "on our servers", and "we can reset it for you", your notes are encrypted against everyone except the company itself. If the answers are "only you", "in your browser", and "nothing — there is no recovery", the privacy claim is real, and the inconvenience is the price.

The notepad I built from these lessons is Outsmart Notes — https://outsmartnotes.com — and those three questions are the ones I would ask of any tool before trusting it with a private note.