What actually happens when you hit the burn button?
Lots of apps say they "delete your data." Then you find out there's a 30-day grace period, a backup somewhere, a log that remembers. We're going to tell you exactly what BurnChat does when someone presses burn — step by step, no hand-waving.
Someone in the room hits the burn button. They get a confirmation popup — "Burn this room? All messages and images will be destroyed instantly and everyone will be disconnected." They confirm. Here's what happens next, in order, and it all takes less time than it took you to read this sentence.
The server sends a "room-burned" signal to every connected user in the room. Their screens immediately switch to the burn confirmation page — a big fire emoji and the words "Room burned. All messages and images have been destroyed." Nobody gets to send one last message. It's instant.
The server loops through every socket connection in the room and forcefully disconnects each one. Not a gentle "please close the connection" — a hard disconnect. The connection is severed from the server side. Nobody can send or receive anything from this room anymore because the connections no longer exist.
Every room has two background timers: one for auto-cleanup (if everyone leaves) and one for the 24-hour hard expiration. Both get cancelled immediately. They're no longer needed because there won't be a room to clean up.
The message array — every text message, every base64-encoded image — gets its length set to zero. This doesn't just mark things for later deletion. It removes every reference to every message object right now. The data is orphaned — nothing points to it anymore.
The map of connected users — their socket IDs and nicknames — gets wiped. There is now no record of who was in this room.
The room object itself gets removed from the server's room registry. The room ID — that random string in the URL — no longer maps to anything. If someone tries to visit that link now, they'll get a fresh empty room with no connection to what existed before.
This is the part that happens automatically. Once nothing references the message data, the user data, or the room object, JavaScript's garbage collector reclaims the memory. The bytes that held your conversation get overwritten by whatever the server needs that memory for next. This isn't something we trigger — it's just how memory management works. Unreferenced data gets recycled.
How long does all of this take?
Steps 1 through 6 happen in a single function call. We're talking single-digit milliseconds. Step 7 happens whenever the JavaScript engine decides to run garbage collection — usually within seconds, always within minutes. But it doesn't really matter when GC runs, because after step 6, there's already no way to access the data. It's dereferenced. It exists as meaningless bytes in unallocated memory, rapidly getting overwritten.
Can the data be recovered?
Short answer: no.
Longer answer: still no, and here's why. The messages were never written to disk. They lived exclusively in RAM. RAM is volatile memory — it only holds data while it's powered and actively referenced. Once the references are gone, the memory slots get reused almost immediately by other processes. There's no "recycle bin" for RAM. There's no journaling file system keeping track of what used to be there. The data isn't marked as deleted and waiting for someone clever to undelete it. It's overwritten with new data as fast as the CPU needs the space.
Compare this to a normal chat app where messages are stored in a database on a hard drive. Even after you "delete" a database record, the data often stays on disk until new data physically overwrites those sectors. With the right tools, deleted files and database records can be recovered for hours, days, or even weeks after deletion. That's how digital forensics works.
None of that applies here. There are no disk sectors to scan. There are no database records to undelete. There are no backups to restore. The conversation existed as electrical charges in silicon, those charges have been repurposed, and that's the end of it.
What about our server's operating system?
Fair question. Wouldn't the OS keep some trace of what happened? Not in our case. We disabled access logging on the web server. We disabled the system journal. The Node.js process doesn't write log files. There is no file on the server that records which rooms existed, when they were created, who connected, or what was said. The operating system has no more record of your conversation than it does of any other transient block of memory.
What about screenshots?
We can't prevent screenshots. Nobody can — it's a fundamental limitation of displaying information on a screen. If someone in the room takes a screenshot, that exists on their device and there's nothing our server can do about it. Some apps try to detect or block screenshots, but those are trivially bypassed with a second phone or a camera.
We're honest about this. BurnChat guarantees that we don't keep your data. We can't guarantee that every person in the room is trustworthy. That part's on you — which is why you should only share the room link with people you actually want to talk to.
That's the whole process
Button, confirm, wipe, disconnect, delete, garbage collect. Less than a second for the parts that matter. No databases to purge, no backups to shred, no cache to invalidate, no CDN to flush, no third-party analytics to send deletion requests to. Just clear the memory and move on.
We built it this way because we think "delete" should mean delete. Not "delete, but actually we keep it for 30 days." Not "delete, but it's still in our backup from last Tuesday." Not "delete, but our analytics partner has a copy." Delete. Gone. Empty. Done.
See it for yourself
Create a room. Send something. Burn it. Then try to find any evidence it ever existed.
Create a room