What kinds of PDF damage can this fix?

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.

What do the five diagnosis checks mean?

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.

Will the repaired file look identical to the original?

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.

The file still will not open after repair — what now?

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.

Where does the repair run — is my document uploaded?

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.

🩹

PDF Repair

Diagnose a broken PDF and rebuild it with a fresh cross-reference table — structural recovery, entirely in-browser.

100% LOCAL5-point diagnosisxref rebuildSalvage report100% local

Saved Reports· Auto-save on

▾

La calculadoraPage 1

🩹

Drop a damaged PDF here, or click to browse

Diagnosis reports what is broken; the rebuild fixes what can be fixed

🩹

Drop a broken PDF for a five-point diagnosis and structural rebuild

Data Source & Legal Disclaimer

Effective: 2026Last updated: 2026-09-08Update: Manual review

Sources: pdf-lib 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.

See all data sources & update policy →

Cómo funcionaPage 2

↩ Volver a la calculadora

What a PDF repair can and cannot fix — honestly

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.

Five checks → strict parse → object re-serialization → fresh xref

The rebuild rewrites the object graph with a new cross-reference table — the fix for most 'file is damaged' errors.

The invoice that would not open — Dana's recovery

Dana's accounting system rejects a vendor invoice with "file is damaged", but the vendor insists it opens on their side.

Diagnose:Three of five checks fail: the render layer parses zero pages, the strict parser rejects the object graph, and the EOF marker is missing — a classic truncated email attachment
Identify the cause:The diagnosis points to a gateway that cut the transfer at 80%: the missing 20% contains the xref and half the page objects
Partial recovery:Because the strict parser still walks the surviving objects, the rebuilt copy recovers 9 of 12 pages — the accounting system accepts it and the amounts match the PO
Prevent recurrence:She asks the vendor to resend as a zip; the diagnosis panel had already ruled out encryption and header issues, saving hours of guessing

↩ Back to repair

FAQ y detallesPage 3

↩ Volver a la calculadora

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.

Sobre esta herramienta

¿Qué es esta herramienta?

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.

5-point diagnosisxref rebuildSalvage report100% local

Por qué se rompen los PDF: la tabla de referencias cruzadas

Un PDF es un grafo de objetos numerados —páginas, fuentes, imágenes, flujos de contenido— más una tabla de referencias cruzadas que mapea cada número de objeto a su desplazamiento en bytes dentro del archivo. La mayoría de la corrupción no es contenido destruido sino un mapa roto: una descarga interrumpida pierde la xref por completo, un gateway de correo re-codifica el archivo y desplaza los offsets, un escritor que se estrella deja un trailer sin su terminador %%EOF. Los visores tienen que adivinar entonces, y muchos se niegan. El panel de diagnóstico separa estos casos: problemas de cabecera, fallos de la capa de renderizado, fallos de parseo estricto y truncamiento; cada uno apunta a una corrección distinta.

Cómo funciona realmente la reconstrucción

Cuando el parser estricto tiene éxito, la reparación carga todo el grafo de objetos en memoria y lo reserializa desde cero: los objetos se escriben en un orden determinista, se empaquetan en flujos de objetos, y se calcula una tabla de referencias cruzadas nueva a partir de los desplazamientos nuevos. Esta es la razón por la que la corrección es robusta: la salida no hereda ninguno de los libros corruptos. Si el parser estricto falla pero el renderizador tolerante todavía muestra páginas, el archivo ha superado el alcance de la reparación estructural local; el diagnóstico lo dice honestamente en lugar de entregar un archivo que finge estar reparado.

Un flujo de recuperación realista

Empieza por el diagnóstico: cuesta segundos y te dice en qué modo de fallo estás. Para una descarga truncada, pide una copia nueva; ninguna herramienta reinventa bytes perdidos. Para un archivo completo pero estructuralmente roto, descarga la reconstrucción y verifica el número de páginas en cualquier visor. Para archivos parcialmente recuperables, anota cuántas páginas son legibles y usa PDF Split para conservar las supervivientes, y luego mergea con las páginas de reemplazo. Conserva el original: la reparación nunca modifica tu archivo de origen, y una segunda pasada de reparación con otra herramienta puede extraer más.

Preguntas frecuentes

¿Qué tipos de daño en un PDF puede arreglar esto?

El objetivo es el daño estructural: tablas de referencias cruzadas rotas tras descargas interrumpidas, desplazamientos de bytes movidos por gateways de correo, trailers EOF ausentes, objetos huérfanos y entradas de xref malformadas. La reparación vuelve a parsear el grafo de objetos y lo reserializa con una xref y un trailer nuevos, lo que arregla la mayoría de los errores de «el archivo está dañado». Lo que no puede hacer es regenerar bytes perdidos: un archivo truncado al 80 % sigue sin su cola.

¿Qué significan las cinco comprobaciones del diagnóstico?

La firma de cabecera verifica el marcador %PDF-; la comprobación de la capa de renderizado parsea el archivo con pdf.js (lo que los navegadores realmente usan: si esta pasa, los visores pueden abrir el archivo); la comprobación de estructura de objetos parsea estrictamente con pdf-lib (si esta falla pero el renderizado funciona, el archivo se abre pero es estructuralmente frágil); la comprobación de cifrado detecta la protección con contraseña; y la comprobación de EOF busca el trailer %%EOF cuya ausencia indica truncamiento.

¿El archivo reparado se verá idéntico al original?

Para reparaciones estructurales, sí: la reconstrucción reserializa los mismos objetos de página, así que el contenido, las fuentes y las imágenes quedan intactos. El tamaño del archivo puede cambiar ligeramente (los flujos de objetos se empaquetan de forma eficiente). Si el daño destruyó bytes de contenido, el archivo reconstruido contiene lo que sobrevivió: el diagnóstico te dice cuántas páginas son legibles para que sepas qué esperar antes de descargar.

El archivo sigue sin abrir tras la reparación: ¿qué hago?

Mira el diagnóstico: si la capa de renderizado falló y no fue posible ninguna reconstrucción, el daño va más allá de la reparación estructural local. Prueba a extraer la capa de texto con el PDF Text Extractor para rescatar contenido, o a dividir con el conteo de páginas de la capa de renderizado si algunas páginas se parsean. Si el archivo está truncado, pide una copia nueva: ninguna herramienta puede recuperar bytes que nunca se recibieron.