sendnote

Encrypted before it leaves your browser

When you write a note, your browser generates a random AES-256 key and encrypts the text locally using the Web Crypto API. Only the resulting ciphertext is sent to the server — the plaintext never leaves your device.

The link has two parts

https://sendnote.example/n/<id>#<key>

• /n/<id> is sent to the server — a lookup id for the stored ciphertext, meaningless without the key.
• #<key> is the decryption key. Browsers never send anything after a # to the server, so it's only ever seen by whoever opens the link.

This is called fragment identifier and is a standard part of URLs.

Opening the link makes your browser fetch the ciphertext for that id, then decrypt it locally using the key from the fragment. The server only ever handles ciphertext — it can't read your note even if it wanted to.

Optional password instead

If you protect a note with a password, the key is derived from that password (PBKDF2, 250,000 iterations) instead of being generated randomly — so it isn't carried in the URL at all. The link becomes /n/<id>?p=1, and whoever opens it needs the password you shared separately to decrypt the note.

Images are encrypted too

An attached image is encrypted in your browser with the same key as the note text, under its own random IV, before it ever leaves your device. The encrypted bytes are uploaded to blob storage — not the same database as the note text, since images don't fit well in it — and only a link to that ciphertext is stored alongside your note. The server that stores it never has the key, so it never sees the image either.

Notes don't stick around

Every note has an expiry you choose when you create it: read once (deleted the moment it's opened), or 1 hour / 1 day / 7 days (deleted automatically after that time, whether or not it was read). Notes are stored in Redis with a TTL matching the expiry, so nothing lingers past its own expiration and nothing is ever written to disk in plaintext.