File repair success rates: a measured benchmark
Run through IntactFile's shipping repair path, a 200-file benchmark corpus produced a usable result 68.5% of the time (137 of 200 inputs). Counting only genuinely damaged files — setting aside 31 pristine controls — the usable rate is 65.1% (110 of 169), and it varies widely by what broke: index and directory damage recovers best, overwritten or truncated media worst.
Every repair here ran on-device, in the same client-side path the product ships. 0 bytes uploaded.
How the benchmark works
The corpus is a synthetic regression suite: files deliberately damaged in known, controlled ways — a truncated download, a zeroed ZIP central directory, a mangled PDF cross-reference table, a missing MP4 moov atom, and so on — so each engine is tested against a failure mode we understand. That control is also the main caveat: these are constructed failures, not a random sample of the files people actually lose, so real-world rates will differ from what you see here.
Every input is run through the shipping repair path — the node-core repairPath under a signed Business license, the exact code path the CLI and MCP server use. Nothing on this page comes from a lab-only branch; the numbers reflect what actually ships.
Two outcome definitions matter, and we report both:
- Success — outcome success: a fully valid, verified rebuild that passes structural checks.
- Usable — success plus partial: a file that opens and gives back recoverable content even when it isn't byte-perfect. For an irreplaceable file, a partial recovery is often the difference that matters, which is why the headline figure is the usable rate.
The corpus also includes 31 pristine (undamaged) controlsto confirm the engine leaves healthy files intact. They count toward the 200-input total but are excluded when we isolate the damaged-file rate (65.1%, 110 of 169).
Results by file family
One row per file family, with the number of inputs and both rates. Percentages are of the inputs in that row.
| File family | Files | Success | Usable |
|---|---|---|---|
| Archive (7z, RAR) | 17 | 11.8% | 23.5% |
| JPEG | 18 | 27.8% | 72.2% |
| 24 | 50.0% | 95.8% | |
| PNG | 28 | 46.4% | 57.1% |
| SQLite | 16 | 31.3% | 68.8% |
| Video | 45 | 46.7% | 57.8% |
| Video reconstruct (missing moov, with reference) | 12 | 58.3% | 75.0% |
| ZIP | 40 | 52.5% | 87.5% |
| All inputs | 200 | — | 68.5% |
| Damaged files only (controls excluded) | 169 | — | 65.1% |
Success = fully valid verified rebuild. Usable = success + partial. Corpus-level success isn't reported as a single number because it isn't a meaningful average across families of very different sizes — read the per-family rows instead.
What this means — what recovers, and what doesn't
The spread is not random. It tracks one thing: whether the file's actual data survived and only its structure was lost, or whether the data itself is gone.
Best: structural and index loss. When only the map is missing and the payload survived, repair is close to a sure thing. PDF cross-reference (xref) rebuilds reach 95.8% usable, and ZIP central-directory rebuilds 87.5%. Missing-moov video, when a healthy reference file from the same device is available to model the layout, reaches 75.0%.
Middle: often recoverable, but it depends where the damage lands.JPEG comes back usable 72.2% of the time and SQLite68.8% — good odds, but a hit to the wrong offset (an image's entropy-coded scan, a database's b-tree root) costs more than a hit elsewhere.
Lower: overwritten or truncated media. PNG lands at57.1% usable and general video at 57.8%. These skew toward damage where pixels or frames were overwritten or never written — the data itself is absent, not merely unindexed, so there is less to rebuild around.
Worst: proprietary archives. 7z and RAR sit at23.5% usable. Closed formats and solid compression mean a single lost block can cascade through everything after it, and there is far less published structure to reconstruct from than there is for an open format like ZIP.
The pattern in one line: outcomes are highest on index/directory-loss damage (ZIP central directory, PDF xref) andlowest on overwritten/truncated media and proprietary archives. That is the honest shape of structural repair — it rebuilds the scaffolding around data that survived, and it cannot invent bytes that were overwritten. When the underlying data is genuinely gone, no tool can bring it back, and IntactFile is built to say so rather than pretend.
Citing this benchmark
This is a stable, citable reference — reuse the figures freely, with a link back so readers can check the method. Suggested citation:
IntactFile (2026). File repair success rates: a 200-file benchmark.https://www.intactfile.com/research/file-repair-success-rates/
Published 25 July 2026. Corrections and questions:info@intactfile.com. Related reading:how IntactFile works and what it can't do ·press kit and key facts.