How NotepadAnon Works

The Short Version

NotepadAnon encrypts your note in your browser, uploads only the unreadable ciphertext, and puts the decryption key in the URL. The server never sees the key. The recipient’s browser decrypts the note locally. After reading, the ciphertext is deleted. The whole process makes it cryptographically impossible for NotepadAnon — or anyone else — to read your notes.

Step-by-Step Walkthrough

1. 1

   You write your note

   You type your message (and optionally attach an image) directly in your browser. At this point, nothing has been sent anywhere. The content exists only on your device.

2. 2

   Your browser generates a random key

   NotepadAnon uses the Web Crypto API — a native browser cryptography interface — to generate a cryptographically secure random AES-GCM 256-bit key. This key never leaves your browser.

3. 3

   The note is encrypted client-side

   Your note is encrypted in the browser using AES-GCM with the generated key. AES-GCM produces ciphertext (unreadable encrypted data) plus an authentication tag that prevents tampering. Only the ciphertext is prepared for upload.

4. 4

   Only the ciphertext is uploaded

   NotepadAnon sends the encrypted ciphertext to the server. The key is never included in this request. The server receives only data it cannot read, stores it with a generated note ID, and returns that ID.

5. 5

   The link is assembled with the key in the fragment

   NotepadAnon constructs a sharing link in the format notepadanon.com/note/[id]#[key]. The key is placed after the # (the URL fragment). Browsers never send the fragment in HTTP requests — it is only available to client-side JavaScript.

6. 6

   The recipient opens the link

   When the recipient clicks the link, their browser loads the page. JavaScript on the page reads the key from the URL fragment (which was never sent to the server) and fetches the ciphertext for that note ID.

7. 7

   Decryption happens in the recipient's browser

   The recipient's browser decrypts the ciphertext using the key from the URL fragment. The plaintext is displayed. At no point did the server ever hold the key or the decrypted content.

8. 8

   The note is deleted

   If burn-after-read is enabled, the server deletes the ciphertext immediately upon the first fetch. The note ID becomes invalid. Even if the link were shared again, there would be nothing to retrieve.

The URL Fragment Trick — Why It Works

The security of NotepadAnon hinges on a well-established browser behaviour: the URL fragment ( everything after #) is never sent to the server in HTTP requests. This is specified in RFC 3986 and implemented consistently across all major browsers.

This means the decryption key embedded in a NotepadAnon link is processed entirely on the client. Even NotepadAnon’s own server logs cannot capture it because browsers simply never transmit it.

Open Source

NotepadAnon is open source. You can review the complete client-side encryption code to verify that the key generation, encryption, and decryption all happen exactly as described. Trust through transparency — not through promises.

Related Reading

• NotepadAnon Security — Full Security Model
• What Is NotepadAnon?
• Frequently Asked Questions