The Problem with Persistent Messages
Every day, billions of messages are sent through email, chat apps, and collaboration tools. Most of these messages persist indefinitely. They sit in inboxes, chat histories, and server backups long after they have served their purpose. That password you texted to a coworker six months ago? It is probably still there, scrollable by anyone who gains access to either account.
This persistence creates a growing surface area for data exposure. The more sensitive information that lingers in digital channels, the greater the risk of it being seen by the wrong person, whether through a data breach, a shared device, or simple human error.
Burn-after-read is a concept designed to solve exactly this problem.
What Is Burn After Read?
Burn after read is a privacy mechanism where a message or note is automatically and permanently deleted after it has been viewed once. The name comes from the practice of destroying sensitive physical documents after reading them, a technique long used in intelligence and military communications.
In the digital world, burn-after-read means that once the recipient opens the note and reads its contents, the note is immediately destroyed on the server. No copy remains. There is no way to access it again. The link that was used to view it becomes permanently invalid.
This is fundamentally different from simply deleting a message manually. With burn-after-read, destruction is automatic and guaranteed. There is no reliance on the sender remembering to delete the message later, and no window where the content sits unprotected waiting to be cleaned up.
How Burn After Read Works Technically
The implementation of burn-after-read varies between services, but the core mechanism follows a consistent pattern.
The Creation Step
When a sender creates a burn-after-read note, the content is stored on the server and a unique link is generated. This link is the only way to access the note. The note is flagged in the database as a burn-after-read item.
The Viewing Step
When someone opens the link and the note content is retrieved from the server, the system immediately triggers a deletion process. The note content is permanently removed from the database. This happens as part of the same operation that serves the content to the reader.
After Viewing
Once the note has been viewed and deleted, the link returns a message indicating the note no longer exists. There is no way to distinguish between a link to a note that was burned and a link that never existed. Anyone who tries the link after the first viewer will see the same result.
What About the Viewer?
It is important to understand that burn-after-read protects the content on the server side. Once the note is displayed in the recipient's browser, the content exists in their browser memory and on their screen. The recipient could theoretically screenshot or copy the text. Burn-after-read ensures the server-side copy is destroyed, but it cannot control what happens on the recipient's device. This is a fundamental limitation shared by all digital communication.
Use Cases for Burn-After-Read Notes
Sharing Passwords and Credentials
This is the most common use case. When you need to send someone a password, API key, or login credential, you do not want it sitting in an email thread or chat history. A burn-after-read note ensures the credential is accessible exactly once and then disappears.
Sending Confidential Business Information
Financial figures, contract terms, legal details, or strategic plans that need to reach a specific person without leaving a trail. Burn-after-read ensures the information does not persist beyond its intended use.
Personal Sensitive Information
Social security numbers, medical information, bank account details, or other personal data that someone needs once but should not be stored in any communication channel.
One-Time Instructions
Setup instructions, access procedures, or configuration details that are needed once during onboarding or provisioning. After the recipient has followed the steps, the information does not need to exist anywhere.
Whistleblowing and Sensitive Tips
When someone needs to share sensitive information with a journalist, authority, or organization, burn-after-read provides an additional layer of protection by ensuring the original message does not persist on the sharing platform.
How sendnote.link Implements Burn After Read
On sendnote.link, enabling burn-after-read is a single toggle when creating a note. Here is how our implementation works:
- You write your note in plain text or markdown, just as you would any other note.
- You enable burn-after-read by toggling the option before creating the note.
- A unique link is generated that you share with your intended recipient.
- The recipient opens the link and sees the note content. At this moment, the note is permanently deleted from our database.
- The link becomes invalid immediately. Anyone who visits it afterward sees a message that the note does not exist.
The note is stored in our PostgreSQL database with a burn_after_read flag. When the note is requested via its unique ID, the server checks this flag. If it is set, the note content is served to the viewer and a delete operation is executed in the same request cycle. The database row is removed, and there is no soft-delete or recycle bin. The data is gone.
We also track view counts. A burn-after-read note will only ever have a view count of one before it is destroyed. If you combine burn-after-read with an expiry time, the note will be destroyed by whichever condition is met first: the first view, or the expiry deadline.
Burn After Read vs. Other Ephemeral Messaging
Disappearing Messages in Chat Apps
Apps like Signal, WhatsApp, and Telegram offer disappearing messages, where messages are deleted after a set time period. This is useful but fundamentally different from burn-after-read. Disappearing messages are time-based, not view-based. The message persists for the entire timer duration regardless of whether it has been read. It is also visible to both parties during that window and may be backed up by the chat application.
Expiring Links
Some services offer links that expire after a set duration, such as 24 hours or 7 days. This is also time-based and does not account for whether the content was actually viewed. An expiring link that has not been opened still contains accessible content until the timer runs out.
Burn After Read
Burn-after-read is event-based, not time-based. The trigger for deletion is the act of viewing, not the passage of time. This means the content exists for the minimum possible duration: only until it is read. For sharing sensitive information, this is the tightest window of exposure you can achieve with a server-based solution.
Combining Approaches
The strongest approach is to combine burn-after-read with a time-based expiry. On sendnote.link, you can enable both. If the recipient views the note, it is destroyed immediately. If the recipient never views it, the expiry time ensures it is still deleted after your chosen duration. This eliminates the risk of a note sitting unread on the server indefinitely.
Best Practices for Sharing Sensitive Information
Use Burn After Read for One-Time Secrets
If the recipient only needs the information once, there is no reason for it to persist. Always enable burn-after-read for passwords, API keys, and other credentials.
Confirm Receipt Through a Separate Channel
After sending a burn-after-read note, confirm with the recipient through a different channel that they received and saved the information they needed. Since the note will be gone after viewing, they need to store the information on their end if they will need it again.
Do Not Include Context in the Note
Keep the burn-after-read note focused on just the sensitive data. Send context, such as what the password is for or which account it belongs to, through your regular communication channel. This way, even if the note were somehow intercepted, the data alone would be less useful without context.
Set an Expiry as a Safety Net
Always pair burn-after-read with a reasonable expiry time. If the link is never opened, whether because you sent it to the wrong person or the recipient forgot about it, the expiry ensures the content is cleaned up regardless.
Verify the Recipient Before Sharing the Link
Make sure you are sending the link to the right person. Burn-after-read means the first person who opens the link gets the content, and then it is gone. If you send the link to the wrong chat window or email address, the intended recipient will never be able to access it.
Use Secure Channels for the Link Itself
While the note content is protected by burn-after-read, the link itself should be shared through a reasonably secure channel. Avoid posting burn-after-read links in public forums or group chats where unintended people might click them first.
Conclusion
Burn-after-read is one of the simplest and most effective tools for reducing the risk of sensitive information exposure. By ensuring that shared content is destroyed the moment it is read, it minimizes the window during which data can be accessed, copied, or leaked.
On sendnote.link, burn-after-read is built into the core sharing workflow. Combined with time-based expiry and the simplicity of shareable links, it gives you a practical, reliable way to share sensitive information without leaving a trace. The next time you need to send a password, a private key, or any piece of confidential data, create a burn-after-read note and share the link. Once it is read, it is gone.