Skip to content
vanishnote

We can’t read your notes. Here’s exactly why.

Not because we promise not to look, but because we never get the key. This page sets out what our servers see, what they never see, and the limits of what that protects against.

Anatomy of a Vanishnote link

https://vanishnote.example/n/3q2-7wLk0aZb1xYcPn8T4g#Vx4mP9qL2rT8wZ0kB5nH7cJ3fD6sA1yE

The address
Sent to our server so it can find the locked note. On its own it unlocks nothing.
The key, after the #
Made in your browser. Browsers never send this part to a server, so it goes from you to your recipient and never reaches us.

What our servers see

  • The encrypted note (ciphertext), its 96-bit IV, and, for password-protected notes, a random salt.
  • Your settings: expiry time, number of views left, and whether a password was used.
  • Your email address, only if you asked to be notified, and only until the note is deleted.
  • A SHA-256 hash of your destroy token (not the token itself).
  • As with any website, your IP address while a request is being handled. We use it for rate limiting and don't store it.

What our servers never see

  • The text of your note.
  • The decryption key. It lives in the link's fragment (after the #), which browsers don't send to servers.
  • Your password, or any hash of it.

Cryptography

  • Encryption: AES-256-GCM via the browser's built-in Web Crypto API, with a fresh random key and IV for every note.
  • Passwords: PBKDF2-SHA256 with 600,000 iterations and a random 16-byte salt. The result is combined with the link key using HKDF-SHA256, so decryption needs both the link and the password.
  • IDs and tokens: note IDs carry 128 bits of randomness; destroy tokens carry 256 bits.

Burn after reading, done properly

Fetching and deleting a note happen in a single atomic database operation. Two simultaneous attempts to read a single-view note can't both succeed. We test this on every change. A note that is missing, already read, or expired always produces the same message, so nobody can tell which happened.

Hardening

  • A strict Content Security Policy: only our own scripts run, and no inline scripts.
  • Referrer-Policy: no-referrer, so note URLs are never passed to other sites.
  • Note pages and API responses are marked no-store and noindex.
  • No analytics, ads, third-party fonts or third-party scripts anywhere.
  • Decrypted text is displayed as plain text, never interpreted as HTML.
  • We don't log request bodies, full note IDs or email addresses, and request logging is switched off at the platform level.

What Vanishnote can't protect against

  • Someone who gets the link first. Anyone holding the full link can open the note. Add a password and send it separately to guard against an intercepted link.
  • A compromised device on either end: malware, a malicious browser extension, or someone looking over a shoulder.
  • A recipient who keeps a copy. Once a note is shown, they can copy or screenshot it.
  • Weak passwords. If someone steals the link and opens the note, they get the encrypted data and can guess passwords offline. A long passphrase makes that impractical.
  • A malicious server. Like any web app, you trust us to send you honest code each time you load the page. Browsers can't yet verify that automatically.

Reporting a vulnerability

Please email security@vanishnote.example and give us a reasonable chance to fix the issue before you disclose it publicly.