What Happens If Your Browser Crashes Mid-Redaction?

The redaction literature, including most of this site, is organised around one risk: that something you meant to hide survives into the file you hand over. That is the right thing to worry about, and it has produced a long list of specific failure modes — text under a drawn box, a filename in a footer, an identifier reachable by inference. Every one of those is a question about the document.

This page is about a risk with a completely different shape, and it is the one that actually ruins people's afternoons. Nothing has leaked. The document is fine. You have simply lost the work. The tab crashed under memory pressure on page sixty-three of an eighty-page scan, or a colleague's video call ate the laptop's RAM, or you reached for Undo and hit Clear page, or you reloaded out of pure habit. And there is no draft, no autosave, no recovery prompt, and no undo deep enough to help.

What makes this worth a page of its own is that the absence of recovery is not an oversight to be worked around until it gets fixed. It is a direct, inseparable consequence of the design that makes the tool trustworthy in the first place. An editor that could restore your half-finished redaction of a medical record would have to be keeping your half-finished redaction of a medical record somewhere — in browser storage at minimum, on somebody's server in the usual implementation. This tool keeps nothing, so it can restore nothing. Once you see the trade clearly, you stop hoping for a recovery feature and start working in a way that makes a crash cost minutes instead of hours.

What is actually held, and where

The useful mental model is that everything lives in one ordinary JavaScript object inside the page, and that object has exactly the lifetime of the tab. It holds your file's raw bytes, the parsed document, the current page number, and a map of redaction rectangles keyed by page number. Rectangles are stored as plain coordinates in the pixel space of the canvas you drew on.

That is the complete inventory. There is no second copy anywhere. The script contains no calls to localStorage, sessionStorage or IndexedDB, sets no cookies, and the site registers no service worker and ships no app manifest, so there is no offline app shell holding state either. Nothing you do in the editor writes to disk until you press Download, and what Download writes is a finished PDF, not a resumable project file.

Two further details follow from how the file is loaded, and they explain why a crash is likeliest on exactly the documents you least want to lose. Your file's bytes are held twice while you work, because the PDF renderer consumes the buffer it is given and the original is kept intact alongside it for the export. And the export itself renders every page — not only the pages you marked — into an offscreen canvas at double scale, encodes each as a JPEG, and assembles the whole output in memory before any of it reaches your disk. A big colour scan is therefore memory-hungry at precisely the moment you have the most work invested in it. The page-capacity guide covers that constraint in its own right; here it matters as the most common reason the tab dies.

Everything that destroys in-progress work

These all have the same outcome. It is worth knowing the full list, because several of them are things people do reflexively.

• A tab or browser crash. The usual cause is memory exhaustion during the export of a large document.
• Reloading the page. A fresh page load means a fresh, empty state object. Reloading is the instinctive response to a slow or stuck tab and it is the single most avoidable way to lose everything.
• Closing the tab, or navigating away and coming back. Including the back button. There is no warning dialog, because that dialog only appears for pages that register a beforeunload handler and there is no such handler anywhere on this site.
• The New PDF button. One click clears the file, the document and the stored boxes for every page, with no confirmation prompt — the script contains no confirmation dialogs at all. It sits in the toolbar immediately beside Download.
• The Clear page button. Empties every box on the page in front of you. Undo cannot bring them back: Undo removes the most recent rectangle from the current page's list, and after a clear that list is empty, so the button simply greys out. There is no redo and no cross-page undo.
• A tab the browser discards to free memory. Some browsers unload background tabs under pressure and reload them when you return. The reload is indistinguishable from any other, so the work is gone.

Session restore does not rescue any of this. Reopening a closed tab restores the address, which gets you a blank editor; it cannot restore the file you chose, because a file input cannot be repopulated with a file by script. That is a browser security rule rather than a choice made here, and no web page can work around it.

What survives

Less bleak than it sounds, and worth being precise about so you know where you stand after a crash.

Your original PDF is untouched. The tool reads your file's bytes and never writes back to the file you picked. Whatever happened to the tab, the source document is still exactly where it was, byte for byte. There is also no copy of it anywhere else — see whether HidePDF keeps a backup for why that cuts both ways.

Any export you already downloaded is a finished file. Redactions are burned into the pixels at export time, so a downloaded chunk is permanently redacted and independent of the session that produced it. It does not become provisional because the tab later crashed.

The libraries are usually still cached. The two scripts the page depends on are served from public CDNs with very long cache lifetimes, so reloading after a crash normally does not re-download them. Recovery is quick; it is just recovery to an empty editor.

A checkpoint workflow for long documents

1. Decide your checkpoint size before you open anything. Twenty to thirty pages is a reasonable unit on a desktop, fewer for dense colour scans or on a phone. The question to answer is how much re-work you are willing to absorb, and that is a decision, not a discovery.
2. Split first, redact second. Use a local splitter you trust, or print-to-PDF page ranges, to turn one long document into several short ones. Splitting afterwards is no help — the risk you are managing is losing work you have already done.
3. Finish a chunk, then download it immediately. Do not carry two chunks' worth of unexported marking at once. The download is your save button and it is the only one you have.
4. Name every export as it lands. The download is named after your original with -redacted appended, so three chunks of the same source produce three near-identical names. Rename each one to its page range the moment it arrives, while you still remember which is which.
5. Keep a written tally. A two-line note saying which ranges are done and verified. After an unexpected crash, the thing you most want is not your boxes back but certainty about where you actually got to.
6. Settle the window before you start and do not resize mid-chunk. The page is scaled to fit the viewer's width, so window size is effectively the zoom, and resizing rescales rectangles you have already placed. Browser zoom and rotating a phone both count. See the tool above and keep the geometry still.
7. Verify each chunk from the downloaded file, not the editor. Check it before you draw a single box in the next chunk, so a mistake in your method surfaces after twenty pages rather than after four hundred.
8. Merge locally at the end if the recipient needs one file. Merge only verified redacted chunks, and keep the original somewhere it cannot be confused with an export.

Common mistakes and misconceptions

Expecting a confirmation dialog to protect you. There are none, anywhere. Clear page and New PDF both act immediately. If you have ever relied on a browser's leave-site warning to catch a stray keystroke, that safety net is not present here.

Reloading a sluggish tab. This converts a recoverable annoyance into total loss. If the tab is slow but alive, try pressing Download and taking what you have — a partial export of a chunk is worth far more than a clean reload.

Treating a failed download as lost work. It usually is not. A cancelled or failed transfer leaves the editor's state completely intact; press Download again. It is only the browser's own Retry control that will not work, because the temporary address the download manager recorded is released about a second after the download starts.

Assuming an autosave exists because other web apps have one. Document editors you use daily autosave constantly, which is a reasonable thing to generalise from and wrong in this case. Those editors autosave to a server. The feature and the privacy model are the same mechanism viewed from two sides.

Hoping tab restore will bring the file back. It restores the page, never the file. Expecting otherwise tends to delay the moment you accept the re-work and start again.

Deleting the original once the first chunk exports cleanly. Tempting as tidiness, and it removes the only thing that makes recovery from any later problem possible. Keep the original until the whole job is delivered and verified.

Doing the long job on the machine with the least memory. If you have a choice of device, the browser with the fewest open tabs and the most RAM is the one that will not crash. This is the rare redaction decision where ordinary performance advice is the right advice.

Worrying that a crash sent something somewhere. It cannot have. The script makes no network requests at all, and no upload is required at any point, so there is no transfer for a crash to interrupt and no half-delivered copy to chase.

Related guides

See also, or use the redaction tool above:

• How Many Pages Can You Redact in a PDF at Once?
• Does HidePDF Keep a Backup of My Original PDF?

Frequently asked questions