← All posts

You closed the tab before saving your edits

You had twenty minutes of work in a PDF — a dozen fields filled in, two prices corrected, a signature placed — and then the tab went. You closed it by accident, or the browser fell over, or the laptop decided it was time.

You have looked in Downloads and there is nothing. You have opened the original file and it is exactly as it was. Somewhere between those two facts is the work you did, and nothing on your machine seems to know about it.

Here is what actually survives a closed tab, what does not, and why — plus the version of this question that a lot of people are really asking, which is how to stop a PDF asking to be saved when they never changed it.

Why a browser tool usually has nothing to recover

Word and Acrobat keep autorecovery files because they are programs running on your computer with the run of your disk. Every few minutes they write a copy of the open document somewhere in your profile, and on the next launch they look for it and offer it back.

A web page cannot do that, and does not. When you chose a PDF in a browser tool, the file was read into the tab's memory as a block of bytes. The pages you were looking at were drawn from that block. Your edits were held next to it, also in memory. Closing the tab ends the process that owned all of it, and the operating system reclaims the memory without asking what was in it. There is no temp file in %TEMP% or /tmp with your document in it, so searching for one is time you will not get back.

Two things follow from this, and the first is good news. Your original file was never touched. A browser tool cannot write back over the file you picked; it can only offer you a new one to download. Whatever else has happened, the document on your disk is intact. And most browser PDF tools keep nothing at all — they send each action to a server, hand back a file, and hold no draft anywhere. For those, the honest answer is that the work is gone.

The one thing that is small enough to keep

The document is large and it is yours. The list of what you did to it is neither: a few kilobytes of "delete this text run, draw these words at this coordinate, put this image on page 4".

That list is what our editor stores. While you edit, the plan — never the PDF — is written into IndexedDB in your own browser, keyed by the SHA-256 hash of the document you opened. It is debounced, so it is written about a second after you stop changing things rather than on every keystroke. The file itself is never put in local storage, partly because a 50 MB PDF has no business living in your browser's database, and partly because a browser will not let a page reopen a file from your disk later without you choosing it again.

Which explains the thing that surprises people about the recovery: it remembers what you did, not what you did it to. It will ask for the file again.

Getting the edits back

  1. Reopen the PDF editor in the same browser, on the same device, in the same profile, and not in a private window. The store is per browser, per profile. There is no account involved and nothing was uploaded anywhere, so a different machine has nothing to find.
  2. Look at the start screen. If there is an unfinished session from the last 48 hours it appears there: Unsaved changes to yourfile.pdf, with the time, and a Recover button.
  3. Press Recover. If your upload is still on our side this reattaches to it and puts you straight back in the document.
  4. If it says the upload has expired, add the same PDF again. Uploaded files are deleted after two hours, so past that window the button cannot find its document. Re-uploading is not starting over: the file is hashed as it goes in, the hash matches the saved plan, and you are asked whether to recover the changes. It must be the same bytes — a fresh copy re-exported from the source, or the same document downloaded again from a system that stamps it, will not match even with an identical name.
  5. Check the last thing you did is there before you carry on. The plan was saved about a second after your last change, so a final edit made in the moment before the tab died may not have made it. Undo history is not part of the plan and is not restored — you come back with the document as it stood, and an empty undo stack behind it.

When there is genuinely nothing left

Being straight about it, so you can stop looking:

Why you were not warned

Our editor does register the "leave site?" prompt, and it fires when there are unsaved changes. It is not a safety net, because the browser decides whether to show it. Chrome and Firefox only honour that prompt if you have actually interacted with the page, and nothing shows it at all when the browser is killed, the machine restarts, or a phone quietly discards a background tab to free memory. Not seeing the warning is not evidence that you had nothing unsaved.

If it was a desktop app that crashed mid-save

Different failure, different answer. If the crash happened while the file was being written, the PDF on disk can be half a file: the pages are there but the index at the end never got written. That is what Repair PDF is for — it ignores the broken index, walks the objects it can reach, and rebuilds a clean document around whatever was actually saved. It cannot invent the part that never reached the disk, and it tells you which pages were missing rather than pretending. Before uploading anything, qpdf --check broken.pdf will tell you locally, in one line, whether a file is damaged or merely unusual.

If you are trying to work out which of three copies in your Downloads folder is the edited one, our PDF inspector reads page count, page size, encryption and whether there is a real text layer, in your browser, without uploading anything. A copy with the page you added in it is the one you want.

The other question behind this search: making the save prompt stop

A good share of people who search for this are not recovering anything. They opened a PDF, read it, closed it, and Acrobat asked whether to save changes — to a document they never touched. So they either want that prompt gone, or they want to know what it was about to save.

Usually the document changed when it opened. A form with calculated fields runs those calculations on load. Annotations and fields that were stored without a drawn appearance get one generated for them. Document-level JavaScript runs. None of it is your editing, all of it modifies the in-memory document, and the application dutifully asks.

The fix is to remove the moving parts. Flatten PDF draws the field values and, if you ask, the annotations into the page itself and deletes the objects, so on the next open there is nothing interactive left to recalculate. The prompt stops, and as a side effect nobody can retype the answers either — which is the usual reason for flattening a filled-in form. It is one-way, so keep the original.

The habit that makes all of this unnecessary

Apply and download at natural stopping points rather than at the end. The editor is designed around a plan you build up and then write out in one go, and that is efficient, but it means the value of the session sits in the browser until you cash it in. Cash it in every ten minutes on a long job. The downloaded file becomes the thing you keep editing.

And if the idea of trusting a tab does not appeal for a long piece of work, use something that saves to your disk on its own timer. Xournal++ is free and offline, and for filling in and signing a form it is genuinely better than any browser for exactly this reason — its document is a file, not a session. It annotates rather than rewriting the text underneath, so for correcting a price in existing type you still want an editor that changes the file's own instructions — and if the document arrived as an attachment, start with the four checks here before you start typing into anything.

Tools this post uses: