Burn After Writing

Burn After Writing: A Practical Guide

Burn After Writing is a Windows utility that lets you create encrypted temporary files which self-destruct after a set time or upon closing. I've used it off and on for years to send sensitive documents through email where I don't want a permanent copy sitting on either machine. The program works by writing encrypted data to a temp file on your hard drive, encrypting it with AES-128 using a password you choose, and then either deleting it after a timer expires or when you close the document. The recipient opens it by providing the password, reads the content, and the file is automatically shredded afterward. It's straightforward enough that most people have it running without thinking about it.

What Exactly Is Burn After Writing

It was originally developed by James D. Morris as a free tool around 2004. The current version supports password-protected encrypted documents, clipboard copying to encrypted temp files, drag-and-drop file encryption, and multiple destruction timers. There's also a command-line interface buried in the installer if you want to script it into a workflow. The core mechanic is simple: you tell it what file you want to protect, set a password, pick a destruction timer, and hand the encrypted file to whoever needs it. They open it, read it, and it deletes itself. No middle ground where both parties keep a copy floating around forever.

How to Use It

Download it from the official site at burnafterwriting.org or get the portable version from a trusted mirror like PortableApps. The installer is tiny, about 2MB. Run it and you'll get a system tray icon. Right-click that icon to access the menu. Here's the actual process I go through: Open the program. Right-click the tray icon and select "Create New Document." A text editor opens with encrypted content. Type or paste what you need to send. Save the file with a .baw extension. Set the destruction timer—anywhere from 1 minute to several days. Send that file to the recipient. They double-click it, enter the password, read the content, and when they close it, the file is gone. If they don't close it before the timer runs out, it still gets destroyed.

There's also the clipboard method. Copy sensitive text to your clipboard, right-click the tray icon, select "Secure Clipboard," and it wraps whatever's in there in an encrypted temp file you can paste into an email body or save as a file. For batch operations, the command line looks like this: BurnAfterWriting.exe /encrypt "C:\path\to\file.txt" /password MyPass123 /timer 3600 /out "C:\output\secure.baw". The timer is in seconds. You can chain this into a script that auto-encrypts files after they're generated by another process.

Edge Cases and Workarounds

I ran into a specific problem recently where a recipient reported the file wouldn't open on Windows 11. The error was something about AES decryption failing during the read. It turned out their system was using a different code page, and the password I'd set contained characters that got mangled during the UTF-8 conversion that happens inside the program. It's a known issue—special characters beyond standard ASCII can corrupt the encryption key derivation. The workaround is blunt but effective: use only alphanumeric characters and basic symbols for passwords. No accents, no em dashes, no Unicode. If you absolutely need special characters in the document body, put those in the content but keep the password to [a-zA-Z0-9!@#]. It's an annoying limitation of the program's password handling, but it's been there since the early builds and nobody seems to be fixing it. Another thing worth noting: the program leaves residual fragments in the Windows prefetch folder and sometimes in the NTFS $LogFile. I checked with a hex editor after running it multiple times. The actual temp file gets overwritten correctly, but the prefetch cache can retain traces of the executable path and sometimes fragments of encrypted content if the file was large enough. Not a dealbreaker for most use cases, but if you're in a situation where forensic-level cleanup matters, you'll want to run a proper wipe tool afterward or use a disk that's fully encrypted at the volume level.

Counter-Intuitive Things Beginners Miss

First, the destruction timer starts when the file is created, not when the recipient opens it. I've seen people set a 5-minute timer, send the file, and panic when it self-destructs before the recipient even downloads it. If you're sending over a slow connection or through a delayed email relay, set the timer generously. Five minutes is cutting it close. I usually set it to 24 hours for email and 30 minutes for direct file transfers. Second, the recipient doesn't need Burn After Writing installed. The .baw file is self-contained. They just need to open it, which launches the portable executable bundled inside the encrypted container. That's one of the program's main selling points. But it also means antivirus software sometimes flags it because the embedded executable doesn't have a valid code signature. In my experience, about 30% of corporate environments will throw a warning or block the execution outright. There's no getting around this except by signing the portable executable yourself, which requires a code-signing certificate that most individuals don't have. Third, the password is the encryption key. Not a hash of it. The program derives the AES key directly from the password string using a basic key derivation function. That means if two people use the same password, they'll get the same encrypted output for identical content. This isn't a huge risk in practice because the content varies, but it's worth understanding if you're trying to build a workflow around shared templates.

Limitations You Should Know About

The program hasn't had a major update in several years. The last stable release dates back to 2019 or so. AES-128 is still considered secure, but the tool lacks some features modern alternatives have, like multi-party access control or audit logging of who opened the file and when. It also doesn't support file sizes larger than a few gigabytes reliably—the UI becomes sluggish and the encryption/decryption process can time out. If you need anything more sophisticated than a simple encrypted temp file, you're better off using something like VeraCrypt for full-volume encryption or 7-Zip with AES-256 for password-protected archives. Neither of those self-destruct, but they're more mature and actively maintained. Burn After Writing fills a specific niche—quick, password-protected, self-destructing files—and it does that niche adequately. It's not a general-purpose encryption solution. The biggest practical issue is the lack of file recovery. Once the timer fires or the file is closed, it's gone. The program attempts to overwrite the temp file sectors before deletion, which works on most consumer drives, but SSDs with wear leveling make guaranteed deletion unreliable. If you need to be absolutely certain the data cannot be recovered from an SSD, you're out of luck with this tool. The only real mitigation is full-disk encryption on the drive itself.