Burn After Reading: Self-Destructing Messages Explained

A burn-after-reading message is deleted after it is opened. This is useful when the message should exist long enough for one intended recipient to read it, but should not remain in a permanent inbox or paste history.

There is one habit worth adopting: warn the recipient before they open it. A one-time message is a poor place for “take a look whenever you get a minute,” because a preview, security scanner, or curious click may use the only view.

How it works

1. Paste the message into the editor.
2. Select Burn after reading.
3. Share the generated link or PIN.
4. When the paste is opened, it is removed after the view.

Use the feature for one-time access codes, temporary passwords, private contact details, or short instructions. Confirm the recipient is ready before opening the link because the content may not be available again.

Use a password for stronger protection

Burn-after-reading controls retention; it does not prove who opened the link. Password protection adds another barrier if the link or PIN is accidentally forwarded. Send the password through a separate channel.

Important limitations

The recipient can still copy, photograph, or screenshot the message. Network failures and browser behavior can also affect the experience. Do not use a one-time message as a substitute for a managed secrets vault or an audited enterprise communication system.

For anything important, have a fallback plan that does not involve sending the same secret again in a hurry. If the message was opened by the wrong person, rotate the credential rather than assuming deletion solved the problem.

Warn the recipient first, every time

This is the step everyone skips and the one that causes the most pain. A normal link can be opened whenever. A burn link can be opened exactly once, and that one opening might happen when the recipient is half asleep, on a bad connection, or just curious what you sent. Send a message first: "I am about to send you a one-time link. Do not open it until you are ready to copy the code." Wait for a yes. Then send it. This tiny ritual prevents almost every "it says expired and I never saw it" disaster.

Link previews can eat your only view

Here is a trap most people never think about. Many chat apps fetch a preview when you paste a link, and some corporate email scanners open every link to check it. Each of those fetches can look like a view. A well-built burn service only counts a real browser view with confirmation, but not every service is careful, and you cannot control the recipient's apps. The defense is the same as above: warn first, and for anything critical, use a password too. A preview bot cannot type a password, so the content survives until the human arrives.

Screenshots beat every self-destruct timer

No disappearing message can stop the recipient's own device from recording it. Screenshots, screen recordings, a second phone taking a photo of the screen: all trivial, all undetectable. This does not make burn-after-reading useless. It still removes the server copy, kills the link, and stops casual forwarding. Just understand what it buys: it controls the future of the message, not the present moment. Only send a one-time secret to someone you already trust with it. The burn is a backstop, not a leash.

Burn versus expiration: pick the right one

People mix these up. Burn-after-reading deletes on first view, whenever that happens. Expiration deletes at a fixed time no matter what. Use burn when exactly one viewing should ever exist, like a one-time code. Use expiration when the recipient needs flexible timing, like notes they may read twice over two days. And you can combine them: a paste that burns on first view but also expires in a day covers both the "read it" and the "never got around to it" cases. When in doubt, the shorter life is the safer life.

When it goes wrong anyway

Sometimes the recipient opens the link too early, or the wrong person clicks it, or the page fails halfway. Do not resend the same secret in a panic. First, assume it is compromised and rotate it: change the password, revoke the token, issue a new code. Then send the fresh value through the proper two-channel routine. Mistakes happen; what matters is that a burned message forces you to make a new one instead of reusing an exposed one. That is the feature working as intended, even when it stings.