← All guides
Burn-after-reading notes, explained
The idea behind a self-destructing note is simple: a message with a strict budget of reads. Here's how ours works mechanically, where the limits are, and how to pick settings for what you're actually sending.
Last updated: September 2026 · 6 min read
Mechanically, what happens
On Burning Notes, you write text or attach a file (up to 10 MB) and choose a read limit between 1 and 10. The note is stored encrypted (in the standard mode the service holds the encryption key — the zero-knowledge option below changes exactly that) and the note's URL is all your recipient needs. Every view consumes one read from the budget; when the budget hits zero, the content is gone from the database. There is no "trash" and no undo.
Two optional switches change the character of the note:
- A password locks the note before it can be opened. The recipient needs both the link and the password — which you send through a second channel. Wrong passwords are tolerated ten times; after that the note locks itself for a while rather than handing an attacker an unlimited guessing machine.
- Client-side encryption ("zero-knowledge" mode) encrypts the content in your browser before it's uploaded. The decryption key travels in the part of the link that browsers never send to a server. In that mode, nobody on our side — including us, including someone who later reads the database — can open the note. That's covered in its own guide: Client-side encryption for normal people.
What read limits protect against
- Permanent history. The message doesn't sit in an inbox, a chat backup, or a cloud archive waiting for a breach or a divorce lawyer.
- Accidental re-reading (and that's most of it). After the burn, the link is a dead end for everyone — including whoever finds it later in a browser history or a forwarded email.
- The slow spread of a secret. One link, one opening, done — instead of a password that's still sitting readable in a group chat three years from now.
What read limits don't protect against
The recipient is the boundary. Anyone who can read the note can also copy it, screenshot it, photograph the screen, or retype it. Read limits manage exposure windows; they don't manage people. Treat a note as "handed over once", not "controlled forever".
- Screenshots and copies. By design there's nothing technical stopping them. If the content is too sensitive for that risk, the problem isn't the note format — reconsider whether it should be sent at all.
- Link previews in chat apps. A preview bot fetching the link generally does not consume a read (our preview fetch isn't a browser opening the note), but if a one-time link's first "opening" matters, don't leave it to chance in channels that fetch links automatically. Send it when the recipient says they're ready.
- Letting the wrong person get the link. Whoever opens the link uses a read from the budget. A read limit of 1 shared with three people is a race; the first one wins the content, the others get an error.
Choosing the settings
- Reads: 1 for anything unique — a password, a one-time code, a document going to one person. Reads 2–3 when the recipient may need a second look or is not experienced with the flow. More than that starts defeating the point; if you need ten reads, you probably need a different channel with access control instead.
- Password: on whenever the content would be embarrassing or expensive if a link leaked — either from the chat channel or from the recipient's screen in public. Send the password separately. It costs the recipient five seconds.
- Zero-knowledge mode: on for the genuinely sensitive tier — credentials, contracts, anything where "even the service can't read it" is worth the one real trade-off below.
The trade-off that surprises people: with client-side encryption, the link is the key. Lose the link before sending it and the note is unrecoverable — by you too. Use it for the message you're sending right after creating it, and for longer-term storage use a tool built for that instead.
Good, honest use cases
- Guest and WiFi credentials to visitors — one read, no password, gone after use. Far better than taping the admin password to the router.
- Credentials to a colleague — password lock on, link and password in two channels.
- Draft documents and legal or HR material between individuals — file upload, limited reads, no permanent shared folder.
- Plans and surprises — birthdays, proposals, anything ruined by snooping. (This is the fun use case, and it's real.)
What self-destructing notes are not is a secure messenger replacement. They're a lighter, more careful alternative to dropping a secret into a permanent channel — and measured that way, they remove one of the most common ways ordinary people leak ordinary secrets. That's the whole claim, and it's enough.