Diagnose a broken PDF and rebuild it with a fresh cross-reference table — structural recovery, entirely in-browser.
Drop a broken PDF for a five-point diagnosis and structural rebuild
Repair runs entirely in your browser with pdf-lib and pdf.js. Your file is never uploaded. Structural recovery has limits — a truncated file cannot regrow missing bytes.
A PDF is a graph of numbered objects plus a cross-reference table (xref) that maps each object number to its byte offset. Most "corrupted PDF" failures are structural: a bad xref after a botched download, an interrupted write that truncated the file, offsets shifted by an email gateway, or a trailer that lost its %%EOF. This tool runs two independent parsers — pdf.js (the tolerant renderer browsers use) and pdf-lib (a strict parser) — and when the strict parser succeeds, it re-serializes every object with a fresh xref table and trailer, which fixes bad offsets, orphaned references, and malformed trailers. What it cannot do is regenerate bytes that are simply gone: a truncated file stays truncated, and image data that never made it into the file cannot be re-invented. The diagnosis panel tells you which case you are in — five checks, each marked ok, warn, or fail with an explanation.
The rebuild rewrites the object graph with a new cross-reference table — the fix for most 'file is damaged' errors.
Dana's accounting system rejects a vendor invoice with "file is damaged", but the vendor insists it opens on their side.
To repair a damaged PDF: load the file and run the structural check — the header, object graph, and cross-reference table are rebuilt locally so the file opens again.
FreeToolHub PDF Repair is a free browser-based tool that diagnoses broken PDF structure and rebuilds the object graph and cross-reference table, no signup, no upload.
Repair broken PDF files online free. Five-point structural diagnosis and object-graph rebuild with a fresh cross-reference table. Salvage readable pages from damaged documents. 100% browser-based - no upload, no signup.
A PDF is a graph of numbered objects — pages, fonts, images, content streams — plus a cross-reference table mapping every object number to its byte offset in the file. Most corruption is not destroyed content but a broken map: an interrupted download loses the xref entirely, an email gateway shifts offsets by re-encoding the file, a crashed writer leaves a trailer without its %%EOF terminator. Viewers must then guess, and many refuse. The diagnosis panel separates these cases: header problems, render-layer failures, strict-parse failures, and truncation each point to a different fix.
When the strict parser succeeds, the repair loads the entire object graph into memory and re-serializes it from scratch: objects are written in a deterministic order, packed into object streams, and a fresh cross-reference table is computed from the new offsets. This is why the fix is robust — the output does not inherit any of the broken bookkeeping. If the strict parser fails but the tolerant renderer still shows pages, the file is past structural repair locally; the diagnosis says so honestly rather than shipping a file that pretends to be fixed.
Start with the diagnosis — it costs seconds and tells you which failure mode you are in. For a truncated download, request a fresh copy; no tool re-invents missing bytes. For a structurally-broken but complete file, download the rebuild and verify the page count in any viewer. For partially-recoverable files, note how many pages are readable and use PDF Split to keep the survivors, then merge with replacement pages. Keep the original: repair never modifies your source file, and a second repair pass with a different tool may extract more.
Structural damage is the target: broken cross-reference tables after interrupted downloads, shifted byte offsets from email gateways, missing EOF trailers, orphaned objects, and malformed xref entries. The repair re-parses the object graph and re-serializes it with a fresh xref and trailer, which fixes most "file is damaged" errors. What it cannot do is regenerate missing bytes — a file truncated at 80% stays missing its tail.
Header signature verifies the %PDF- marker; the render-layer check parses the file with pdf.js (what browsers actually use — if this passes, viewers can open the file); the object-structure check parses strictly with pdf-lib (if this fails but rendering works, the file opens but is structurally fragile); the encryption check flags password protection; and the EOF check looks for the %%EOF trailer whose absence indicates truncation.
For structural repairs, yes: the rebuild re-serializes the same page objects, so content, fonts, and images are untouched. The file size may change slightly (object streams are packed efficiently). If the damage destroyed content bytes, the rebuilt file contains what survived — the diagnosis tells you how many pages are readable so you know what to expect before downloading.
Check the diagnosis: if the render layer failed and no rebuild was possible, the damage is beyond local structural repair. Try extracting the text layer with the PDF Text Extractor to salvage content, or split with the render-layer page count if some pages parse. If the file is truncated, ask for a fresh copy — no tool can recover bytes that were never received.
Entirely in your browser: pdf.js and pdf-lib both run locally, and the rebuilt file is assembled in memory. Nothing uploads, which matters when the damaged document is a contract, a medical record, or anything confidential.
What do you call a nosy pepper?
No signups, no data sold. Every tool is free to use — the free tier allows 5 downloads or saves per day, and the optional Pro plan ($7/mo, $59/yr) adds unlimited downloads, batch processing, white-label exports and an ad-free experience.
☕Support me on Ko-fi— support the free tier100% of proceeds go towards hosting & building more free tools.