Some secrets shouldn't persist. A password, an API key, a recovery code — these should exist exactly once, then vanish. That's what burn-after-read is for: a link that deletes itself the moment it's opened.
You create a paste with burn-after-read enabled. The content is encrypted in your browser, and the server stores only ciphertext. When the recipient opens the link, the paste decrypts on their device and the server deletes the ciphertext immediately. The link is dead after a single view.
Chat apps and email keep permanent records. A password sent over Slack sits in the archive forever, searchable by anyone with access. A burn-after-read link leaves no trace — the content exists only in the recipient's browser, for one moment.
Paste your secret, check "burn after read", and share the link. No account, no signup, no cost. The recipient opens it once, reads it, and it's gone. For extra safety, combine it with an expiration timer as a fallback.
Burn-after-read (also called self-destruct or one-time-view messages) means the content is deleted from the server the moment it is viewed once. The recipient opens the link, reads the message, and the ciphertext is wiped — refreshing the page yields a 404 or an empty record. Unlike expiring messages that persist for a set time window, burn-after-read guarantees exactly one view. If the link was opened before your intended recipient got to it, they will know — the empty page is itself a signal that someone else read it first. That tamper-evidence is the feature's quiet superpower.
Most secret-leakage disasters aren't sophisticated breaches; they're secrets left lying around. A Slack DM with a production API key is searchable by every admin, synced to every device, retained according to workspace policy, and discoverable in litigation. A Gmail message lives on Google's servers and both parties' devices indefinitely. Burn-after-read collapses the exposure window from "forever, everywhere" to "one view, one person." The IBM Cost of a Data Breach Report 2024 found the average breach lifecycle — identification plus containment — lasted 258 days; secrets that delete themselves after first read simply aren't there to be swept up.
Burn-after-read is not magic DRM: a recipient can screenshot, copy, or photograph the content, and a malicious server operator could theoretically retain ciphertext (though with zero-knowledge encryption, they'd hold undecryptable bytes). Set expiry as a backstop — "burn on first read OR after 24 hours" — so unread secrets don't linger. And never put the decryption key anywhere but the link's URL fragment; if you paste the key into a chat message, you've defeated the encryption entirely.
What's the difference between burn-after-read and expiring messages?
Expiring messages delete after a fixed time regardless of reads; burn-after-read deletes on first view. Burn-after-read gives you tamper-evidence — if your recipient finds the link empty, someone else read it — while expiry is simpler for multi-person or delayed scenarios. Use both together: burn on read, expire in 24 hours as backstop.
Can burn-after-read be defeated by screenshots?
Yes — nothing prevents a recipient from photographing or copying what they see. Burn-after-read protects against server-side persistence and third-party exposure (breaches, logs, discovery), not against a trusted recipient intentionally preserving the content. Choose your recipient, not just your tool.
Why does the empty link matter if someone else read it first?
Because it tells you a compromise happened. With a normal paste, an attacker who intercepted the link leaves no trace. With burn-after-read, the legitimate recipient hits an empty page — an unambiguous alarm that the channel was intercepted, prompting you to rotate the secret immediately.