"Excel found unreadable content in '<name>.xlsx'"

Since Excel 2007, .xlsx uses the Office Open XML (OOXML) format wrapped in the Open Packaging Conventions — the same ZIP-of-XML design as .docx and .pptx. Rename a copy to .zip and you can open it: inside sit [Content_Types].xml, a _rels/.rels map, and an xl/ folder holding workbook.xml (the list of sheets and defined names), one xl/worksheets/sheet1.xml per tab (the actual cell grid), xl/sharedStrings.xml, xl/styles.xml, an xl/media/ folder for embedded images, and xl/_rels/workbook.xml.rels tying the sheets to their files.

Two Excel-specific details explain why this error behaves the way it does. First, cell values are split by type: a number lives inline in its worksheet as <c><v>42</v></c>, but text does not — to save space Excel writes every string once into xl/sharedStrings.xml and each text cell only points at it by index (<c t="s"><v>7</v></c> means "the 8th shared string"). Second, XML is strict: one unclosed tag, one stray byte, or a part that stops mid-element makes that part unparseable. So the error has two root causes — the ZIP/OPC container itself is damaged (a bad copy, an interrupted sync, a truncated download) or one XML part is malformed or truncated. When Excel hits either, it will not silently render half a spreadsheet; it stops and offers to "recover the contents of this workbook."

Because the format is layered, repair works at two levels. First the tool treats the file as a ZIP and rebuilds the package — fixing the central directory, re-reading each stored entry, and reassembling a well-formed archive. Then it repairs the OOXML parts inside: it re-validates workbook.xml, each xl/worksheets/sheetN.xml, sharedStrings.xml and styles.xml, closes structures that were left open, and drops fragments that cannot be salvaged so the surviving XML parses cleanly.

In practice this recovers the cells, sheets and values that were fully written. Numbers, dates and booleans are stored inline in each worksheet, so any row that made it to disk comes back. Formulas survive too: the formula text lives in the worksheet as <f>SUM(A1:A9)</f> next to its last cached result, so a repaired sheet reopens with your calculations intact. xl/calcChain.xml — the recalculation order Excel keeps as a cache — is famously the first thing to rot; it is safe to discard because Excel simply rebuilds it on the next open, and dropping that one part often clears the error by itself. Embedded images live as independent files under xl/media/ (PNG, JPEG and so on), so damage to a sheet's XML does not touch them, and an intact picture is carried straight into the rebuilt workbook. All of this runs in your browser tab — no Excel install, no add-in, no server round-trip.

Repair recovers what is present; it cannot reconstruct cells that were never written to disk. If a worksheet part was truncated — the save or copy stopped partway — every row after the break point is gone, and the tool can only return the cells up to that cut. That is the honest ceiling on any recovery of this file, ours or Excel's own "recover contents" pass.

The shared-string table is the other Excel-specific catch. Because text cells only hold an index into xl/sharedStrings.xml, if that single part is the damaged or truncated piece you can lose text across every sheet at once while the numbers sit untouched — repair salvages the strings it can read and re-links them, but strings past a truncation in that table are unrecoverable. Pivot tables and charts that cache their source data may need a manual refresh after reopening, and a password-encrypted workbook is wrapped in an encryption container the tool cannot open without the password. When the damage is confined to the wrapper you keep your data; when bytes were never saved, no tool invents them. Because everything happens on-device, the trade is safe for financial models, client lists and records you would never upload — you can watch the Network tab and confirm 0 bytes of the .xlsx ever leave your machine.