Self-destructing · Encrypted · Zero-knowledge
Burn after reading.
Write a secret. Get a link. Send it. The moment it's read — it's gone. No trace in chat logs, email threads, or server backups.
5 free notes on registration. No credit card.
Why email and Slack aren't "burn after reading"
When you send a password over Slack, it lives in Slack's servers indefinitely — in both the sender's and recipient's message history, search indexes, audit logs, and potentially third-party integrations. Deleting the message doesn't remove it from logs. "Expiring" messages in Signal or iMessage still leave the plaintext accessible until the timer runs out.
True burn-after-reading means the secret is gone the moment it's read — not scheduled for deletion, not marked as deleted, not recoverable by the service provider.
How it works
- 1
Write your secret
Type a password, API key, private note, or any sensitive text. Set the view limit (1 to 100 reads) and an optional extra password for the recipient.
- 2
Your browser encrypts it — before it leaves your device
AES-256-GCM encryption runs entirely in your browser. A random decryption key is generated and embedded in the URL fragment. The server receives only ciphertext — it never sees the key, so it can never read your secret.
- 3
Send the link — it burns after reading
Share the URL via any channel. When the recipient clicks it, their browser fetches the ciphertext and decrypts it locally. The server immediately deletes the record. The note is gone — permanently, with no recovery path.
Compared to other options
| Method | Truly deleted? | Server can read? | Stays in logs? |
|---|---|---|---|
| Slack DM | No | Yes | Yes — forever |
| No | Yes | Yes — both ends | |
| iMessage / Signal (timer) | After timer | Until deleted | Partial |
| Privnote | Record deleted | Yes (server-side) | Until read |
| VoidNote | Yes — on read | Never (ZK encrypted) | Never |
What people burn after reading
Passwords
Share a temporary credential with a colleague without it living in chat history forever.
API keys
Hand off a key to a developer, a CI runner, or an AI agent — one use, then gone.
SSH keys & tokens
Provision access for a deployment without committing secrets to config files.
2FA recovery codes
Back them up once with a trusted contact. Once read, they can't leak.
Private messages
Write something that should only ever be read once by one person.
Legal & financial info
Bank details, legal drafts, contract terms — share once and destroy.
Common questions
Is this actually secure — or does the server just 'delete' a record?
Most burn-after-reading services store plaintext and delete the database row after reading. The service itself — and anyone with database access, including law enforcement with a warrant — can read the note before it's opened. VoidNote uses client-side AES-256-GCM encryption. The decryption key only exists in the URL fragment, which is never sent to our server. We hold ciphertext we cannot decrypt. This is verifiable: open DevTools, create a note, watch the network tab — no plaintext, no key.
Can a note be recovered after it's been read?
No. Once the view count reaches zero (or after 24 hours), the encrypted record is permanently deleted. Because we never held the decryption key, there is nothing recoverable — not by us, not by anyone.
What if someone forwards the link before I send it?
The link is single-use by default. If someone opens it first, your intended recipient gets an error — the note is gone. You can raise the view limit if multiple people need to read it, but that also increases the window during which the link is active.
Do I need an account?
No. You can create and share a burn-after-reading note without registering. Register for a free account to get 5 notes, view your note history (note: we only store metadata — never content), and buy more credits.
Ready to send something that actually disappears?
No account needed to start. 5 free notes when you register.