{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}:  {{ badge.value }} {{ summaryAnnouncement }}
PDF repair setup
Choose one PDF up to the Advanced work limit, or generate the safe local sample.
{{ dropzoneTitle }}
{{ dropzoneHelp }}
Choose the requested outcome before running the local parser.
Diagnostics-only mode keeps this name ready without producing a download.
{{ actionLabel }}
{{ workflowFeedback }}
Choose 10-200 MiB. The neutral default is 80 MiB.
MiB
{{ repairedArtifactTitle }}{{ repairedArtifactLine }}
{{ pdfExportAnnouncement }}
CheckStatusValueMeaningCopy
{{ row.label }}{{ row.status }}{{ row.value }}{{ row.detail }}
{{ tableExportStatus }}
{{ chartExportStatus }}

The chart renderer is unavailable. The same structure checks remain available in the diagnostic ledger.

{{ planCopyAnnouncement }}
  1. {{ row.title }}{{ row.status }}

    {{ row.detail }}

A PDF can fail for several different reasons. Extra bytes may have been appended during transfer, a cross-reference pointer may be stale, the file may be truncated, or the page tree may contain objects a particular reader cannot follow. The same symptom—an upload rejection or a blank reader window—does not identify which failure occurred.

Light repair depends on a parser being able to recover the page tree. If the pages can be loaded, saving the document again may produce cleaner cross-reference data and remove harmless material after the final end marker. A fresh page copy goes further by placing the readable pages into a newly created document. Neither method reconstructs page content that the parser cannot find.

  • Structural clue: a byte marker such as the PDF header, end marker, cross-reference pointer, or object delimiter. Clues help triage a file but do not prove that its contents are complete.
  • Parser result: the decisive test for this repair path. A readable page tree is required before a changed PDF can be saved.
  • Normalised copy: a new byte stream created from the parser's model of the document. It can differ from the source even when every visible page looks the same.

Always preserve the original. Rewriting can invalidate digital signatures and may change or omit forms, annotations, attachments, metadata, bookmarks, or other document-level features. Legal, signed, archival, or irreplaceable files need a separate verification plan, not merely a successful download.

How to Use This Tool:

Choose the least invasive outcome that answers the problem, and keep the damaged source unchanged while testing the result.

  1. Select Source PDF and confirm that its size is within the chosen browser work limit.
  2. Choose Diagnostics only for inspection, Rewrite parsed PDF for a normalised save, or Fresh page copy to build a new document from readable pages.
  3. Run Analyze and repair. If the header is missing, encryption is detected, the work limit is exceeded, or the parser cannot load pages, no repaired PDF is created.
  4. Review Diagnostic ledger and Recovery plan. When a file is produced, open every page and test it in the print, upload, archive, or signature workflow that rejected the source.

Interpreting Results:

A Repaired verdict means the parser loaded at least one page and the selected save completed. It does not certify semantic completeness. A Diagnosed verdict means the page tree loaded but no changed file was requested.

  • Review signals call attention to trailing bytes, weak cross-reference clues, object-count imbalance, or signature markers.
  • Blocked means a hard condition stopped this browser repair path, such as encryption, a missing header, an exceeded work limit, or parser failure.
  • The readiness percentage is a count of eight binary signals. It is not a probability that the document is safe, complete, legally valid, or visually unchanged.

Technical Details:

PDF readers locate indirect objects through cross-reference information and reach pages through the document catalog and page tree. Incremental updates can leave more than one trailer, cross-reference clue, or end marker in a healthy file. Raw marker counts are therefore diagnostic evidence rather than a complete parser.

Rule Core:

PDF repair signals and their decision rules
Signal Passing rule Decision effect
HeaderA %PDF-x.y marker appears within the first 1,024 bytes.A missing header blocks repair.
End markerAt least one %%EOF marker is found.Missing markers reduce readiness; bytes after the final marker create a review signal.
Cross-reference cluesAt least one startxref and either an xref or trailer marker are present.Weak clues create a review signal but do not override a successful parser result.
Object balanceAt least one object and end-object marker exist, with a count difference no greater than two.A larger imbalance creates a review signal.
PagesAt least one parsed page or raw page marker exists.The parsed page count is stronger evidence; zero parsed pages prevents output.
EncryptionNo encryption dictionary marker is detected.Encrypted PDFs are blocked; passwords are not requested or bypassed.
ParserThe page tree loads and contains at least one page.This is required for diagnostics to complete and for either repair mode to create output.
Requested outcomeDiagnostics complete, or the selected save returns nonempty output.The last readiness signal reflects the requested mode rather than an independent structure check.

Formula Core:

The browser limit uses binary mebibytes. Readiness gives each of the eight signals equal weight, regardless of how consequential that signal may be.

LimitBytes = BrowserLimitMiB×1048576 Readiness = PresentSignals×12.5% TrailingBytes = TotalBytes(FinalEOFOffset+5)

The default 80 MiB limit equals 83,886,080 bytes. The accepted work-limit range is 10 to 200 MiB, inclusive; the source file also has a hard maximum of 200 MiB.

Repair Modes:

PDF repair modes and output behavior
Mode Mechanism Output
Diagnostics onlyScans structural markers and attempts to load the page tree.No changed PDF.
Rewrite parsed PDFSaves the loaded document again with object streams disabled.A normalised copy when parsing succeeds.
Fresh page copyCreates a blank PDF, copies every parser-readable page into it, and saves the new document.A reduced document structure built around copied pages.

Limitations and Privacy:

The source bytes remain in the current browser session and are not uploaded by this workflow. A repair pass may hold both source and output in memory, so the practical device limit can be lower than the selected work limit.

  • Encrypted or password-protected PDFs are not unlocked.
  • Missing pages, unreadable objects, and content outside the recovered page tree cannot be reconstructed.
  • Digital signatures may become invalid after any rewrite. Signed originals should remain untouched.
  • A successful parse does not guarantee preservation of forms, annotations, attachments, metadata, bookmarks, accessibility structure, or scripts.

References: