A PDF that will not open is usually not destroyed, only broken at the end. A download stopped short, a copy over a flaky connection, a file edited in place by a tool that did not update its index, or a mail gateway that appended a footer after the end marker: each leaves the pages intact and the map to them wrong. This tool re-reads the file object by object, ignores the broken map, and writes a clean PDF from whatever it finds.

It reports what came back. You see how many pages were recovered and whether the damaged tail of the file had to be cut off to get there, and when it was, the result is labelled as a partial recovery. The whole job runs in your browser; nothing is uploaded.

What kinds of damage it fixes

Three failures cover most broken PDFs. A truncated file is missing its cross-reference table and trailer, so a reader cannot find the pages. A file with a bad startxref offset has the table but points to the wrong place, common after in-place edits. A file with junk after %%EOF confuses readers that check the end marker, which mail systems and some content management systems cause by appending text.

In each case the page objects are still in the file. The repair parses tolerantly, skipping anything it cannot read, collects the objects it can, and rebuilds the document from them. For a file cut inside its cross-reference table, every page usually comes back, because the pages were written before the table was.

When the tail has to be cut

If the tolerant parse still fails, the tool cuts the file back to the last complete object and tries again. That discards the damaged bytes at the end. The report says how many bytes were removed, and the result is marked as a partial recovery, because any page whose objects lived in that discarded tail is gone.

The tool cannot know how many pages the original had. The part of the file that said so is often the missing part. So compare the recovered page count with what you expected before relying on the file, and treat a shortfall as pages lost in transit, not as pages the tool declined to include.

What it cannot recover

A file whose page objects are themselves destroyed, such as one overwritten with zeros or a file that was never a PDF, cannot be rebuilt by anything running in a browser or elsewhere. The tool says the structure is too damaged, and produces no output, instead of handing back an empty document.

A file that opens but shows blank or garbled pages is a different problem. Its structure is fine; its content streams or fonts are broken, and reconstructing those is beyond what a structural repair does. The output of this tool in that case will open, and will show the same blank pages.

Text stays text

The repair rewrites the document structure and keeps the content streams as they were. Text remains selectable and searchable, vector graphics stay sharp, and embedded fonts survive. Nothing is rendered to an image and reassembled, which is how some recovery tools work and why their output cannot be searched.

The output is compressed on save, so it may be a little smaller than the input even before any bytes were cut. The page count shown in the report is the count in the file you download, checked by re-reading the output after it is written.

Frequently asked questions