How PDF Repair Actually Works
No invented engine names — just what genuinely happens when a repair tool fixes a broken PDF.
You double-click a PDF and get: "The file is damaged and could not be repaired." The text, images, and fonts are often still physically inside the file — what broke is the index that tells a reader where to find them.
The four parts of a PDF
1. Header
First line, e.g. %PDF-1.7 — declares the spec version.
2. Body (objects)
The actual content: text, fonts, images, form fields.
3. Cross-reference (XREF) table
An index of byte-offsets — where each object physically sits in the file.
4. Trailer
Points to the XREF table and ends with %%EOF.
Why PDFs break
PDF readers jump straight to the end of the file, read the trailer, find the XREF table, then jump to specific objects using its offsets. If anything shifts the byte layout — a truncated download, an interrupted save, encoding changes during email transfer — the XREF table now points to the wrong locations, and the reader either errors out or shows garbage.
What PDFTeq's Repair tool actually does
Our Repair PDF tool uses pdf-lib, a JavaScript library — not WebAssembly, not a custom byte-scanning engine. The mechanism is simple but genuinely useful:
- pdf-lib parses your file and builds an in-memory model of every object it can successfully locate.
- When you save, pdf-lib writes a brand-new, valid XREF table and trailer for exactly the objects it found — this isn't marketing language, it's just what serializing a document from scratch does.
So if your file's damage is limited to the trailer/XREF section — a very common outcome of interrupted saves — and the body objects are still intact, this genuinely fixes it. That's a real, verifiable mechanism, not a proprietary algorithm.
Where this approach hits a wall
pdf-lib is built for creating and editing well-formed PDFs, not forensic recovery of severely damaged ones. If the corruption is bad enough that pdf-lib's parser can't locate objects at all — which includes some "file is damaged" cases — loading fails here too, and you'll get an error instead of a fixed file. We'd rather say that plainly than imply a guarantee we can't back up.
Other things this can't do: recreate image or text bytes that are physically missing (e.g. from a download that stopped partway through), or repair AES-encrypted content without the correct password.
Frequently asked questions
Can it repair a password-protected file?
Not currently — if the file requires a password to open, unlock it first, then try repairing the unlocked copy.
Will it restore missing images?
Only if the image data is still physically present in the file. Data that never made it into the file can't be recreated.
Why is the repaired file a different size?
Re-serializing the document through pdf-lib often produces a more compact structure than the original, since it writes a clean object layout rather than any accumulated incremental-save bloat.