Client-side encryption for normal people

"Encrypted" is one of those words that sounds like one thing and means about five. The distinction that matters most is boring and simple: who holds the key — the server, or you?

Last updated: September 2026 · 5 min read

Two ways to lock the same box

Server-side encryption works like a bank deposit box where the bank also keeps a copy of your key. When you save something, the server encrypts it on the way to disk. That protects against some things — a stolen hard drive, a snooping cleaner — but not against the server itself, and not against anyone who can compel or compromise the server. In practice: the operator can read your data; they just promise not to. Most "we encrypt your data" claims are this.

Client-side encryption moves the locking to your device. Your browser encrypts the content before it's sent, and the key never travels with the content. The server receives ciphertext plus a meaningless ID. When someone opens the note, the decryption happens in their browser — the server can serve the locked box, but it never sees inside. When correctly built, this survives not just hacks but subpoenas and a future change of heart by the operator. That's what "zero-knowledge" is supposed to mean, and it's the mode worth checking for whenever a service uses the term.

How our version works, concretely

• Encryption happens in your browser using a standard, well-reviewed algorithm (AES-GCM, via the same browser cryptography every serious web tool relies on). The plaintext leaves your device only after it's ciphertext.
• The key rides in the link's fragment. Open a note link and you'll see a # followed by a long string. Everything after a # stays in the browser — it is not sent to the server when the page loads. That's not a quirk of our site; it's how the web works, and it's exactly what makes this design possible.
• The server keeps the box, not the key. It stores the ciphertext, an ID, and basic lifecycle metadata (when it was created, how many reads remain). It cannot decrypt even if asked — the key was never there.

What zero-knowledge does not promise

• It doesn't protect you from your recipient. Once decrypted on their screen, it's on their screen: copyable, screenshottable, photographable. Encryption protects the trip and the storage, not the destination.
• It can't be recovered. There's no reset, no support override, no "we'll decrypt it for you". Lose the link and the content is gone forever — including for you. That's the price of nobody else having the key, and it's not negotiable at any price.
• Metadata still exists. The server can't read your note, but it necessarily knows the note exists, roughly how big it is, and when it's opened. Anyone claiming otherwise is overselling. Encryption hides content, not existence.
• The page you're served could in principle lie. The universal caveat of web crypto: you're trusting that the code in the browser does what it says. It's worth knowing it exists, even though for a small self-hosted tool on ordinary secrets it's a much smaller worry than the leaked-passwords-in-chat problem it solves.

Which mode, when

• Everyday secrets — WiFi passwords to visitors, a note to family, a temporary code: default server-side mode is fine, and simpler. The threat you're actually avoiding is the message surviving in a chat history, not a world-class adversary.
• Things where "the service can't read it" is the point — credentials, contracts, personal documents: switch on zero-knowledge mode, use 1 read, and treat the link carefully.
• Anything with a long life — passwords you'll need next year, documents you may need to revisit: a self-destructing note of any mode is the wrong tool. Use a password manager or proper encrypted storage; those are built for persistence, this is built for passage.

That's the honest version of the pitch. Client-side encryption here isn't a marketing layer over ordinary storage — it's the real construction, with the real trade-offs. Knowing which box you're locking puts you ahead of most people using encrypted tools.