File recovery, on the record

Your file isn’t dead.
It’s just badly zipped.

Every .xlsx, .docx and .pptx is really a ZIP full of XML. Drop one here and we’ll open it up, check every part against the official ECMA-376 schema, and show you exactly what broke — including the schema faults that AI-generated files trip over and plain XML checks never catch.

A tearful cat beside a laptop showing Word's “We found a problem with some content” dialog
“We found a problem with some content.” You and me both. That message usually means one broken part — often just a few characters.

Drop the evidence here

.xlsx.docx.pptx— or click to browse

No broken file handy? Borrow one of ours:

Tested on files we didn't write

5,342 real spreadsheets. Zero false alarms.

Every one opens in Microsoft Excel, verified by the independent xlsx-corpus-bench. So the right answer for every file is "nothing is broken".

False alarms
0
OfficeCLI: 239 on the same files.
Files changed
0.32%
17 stale totals, fixed. Everything else comes back byte for byte.
Fail Microsoft's validator
27.7%
Yet open fine. We check against what Office does, not just the spec.

And on our 156-case fault corpus, against OfficeCLI: 133 of 133 faults found, to 100.

See the full benchmark
How it works

How a repair runs

Each stage runs only if the one before it wasn't enough.
  1. 01Container

    Rebuild a package whose ZIP directory is damaged

  2. 02XML

    Close unbalanced tags and escape stray entities

  3. 03Package

    Repair relationships and content types

  4. 04Schema

    Element order, attribute values and references

  5. 05Gate

    Withhold the file unless the Open XML SDK accepts it