Recovering a corrupted Excel file: what actually survives

An .xlsx is secretly a ZIP full of XML

The single most useful fact about modern Excel files is that they are not one monolithic blob. Since the .xlsx format arrived, a workbook is a ZIP archive, and inside that archive is a small tree of XML files, one set per worksheet, plus shared pieces that the sheets reference. Your numbers, your formulas, and your sheet names are stored as plain text in those XML parts. The .xlsx extension is really just a ZIP with a different name.

You can see this yourself in under a minute. Make a copy of the file, rename the copy from report.xlsx to report.zip, and open it with any archive tool. Inside are folders like xl/worksheets/ holding one XML file per sheet, xl/sharedStrings.xml holding the text, and xl/workbook.xml listing the sheets. Open a sheet file in a text editor and your cell values are right there.

An .xlsx is a ZIP: each sheet is an XML part, and the archive keeps a directory at the end. Break the directory and Excel balks, though the sheets inside are still readable.

This is why a corrupted workbook is usually recoverable. Corruption lands in one of two places: the ZIP wrapper around the parts, or the XML inside a part. A truncated download breaks the ZIP directory, the same failure that produces "unexpected end of archive" in an ordinary archive, while the sheets themselves sit intact before the cut. When the wrapper is the problem, rebuilding it gets your data back, because the data was never damaged in the first place.

Try Excel's own Open and Repair first

If you have Excel available, its built-in repair is the honest first step, and it costs nothing. Open Excel, go to File then Open, and Browse to the file. Select it with a single click, then click the small arrow beside the Open button, and choose Open and Repair. Excel gives you two options. Repair attempts to recover the whole workbook, and Extract Data pulls out values and formulas when a clean repair is not possible. Run Repair first, and fall back to Extract Data if it fails.

Do this on a copy, not the original: repair tools work best from an untouched source, and if Open and Repair mangles the file further you still have the original for the next attempt. When it returns an empty grid, throws its own error, or when you have no Excel at all, the ZIP-and-XML structure underneath is your route in, which is where the exact-error path below picks up.

The exact errors, decoded

These are the strings people paste into a search box, rendered here verbatim so you can match yours. The first is the most common:

Excel cannot open the file 'name.xlsx' because the file format or file extension is not valid. Verify that the file has not been corrupted and that the file extension matches the format of the file.

That message is doing two jobs at once, which is why it confuses people. It fires both when the file is genuinely corrupted and when the file is not really an .xlsx, and the wording deliberately hedges between the two. Its shorter sibling, The file is corrupt and cannot be opened., points more firmly at real corruption. The other one you will meet appears when Excel can open the workbook but finds damage inside a part:

Excel found unreadable content in 'name.xlsx'. Do you want to recover the contents of this workbook? If you trust the source of this workbook, click Yes.

Click Yes. That prompt is Excel offering to salvage what it can from partly damaged XML, and it frequently rescues most of the workbook, sometimes dropping a chart or a piece of formatting it could not parse. A closely related follow-up, We found a problem with some content, is the same offer worded differently. Each of these is a signal that the data is largely present and only the structure around some of it is damaged. For a deeper walk through the "not valid" message and its two causes, see "Excel cannot open the file".

What recovers, and what is fragile

Recovery from a corrupted workbook is not all-or-nothing, and expectations matter more here than with most file types: you need to know whether the number in cell G47 came back correctly. The rule follows the structure. The plainer and more central the data, the better it survives.

Values and text recover well. The contents of your cells, numbers, dates, and text, live in the worksheet XML and the shared-strings part as simple text. When those parts are readable, the data comes back faithfully. This is the part that matters most, and the most robust.

Formulas usually recover. A formula is stored as text alongside its last calculated value, so it usually returns intact. If internal links or defined names were damaged, some formulas come back as their cached result rather than the live expression, but the number you saw is preserved either way.

Sheet structure recovers. Sheet names, tab order, and which cells hold what are described in XML that rebuilds cleanly when present. A workbook that lost only its ZIP wrapper typically comes back with every sheet in place.

Formatting is fragile. Cell styles, colors, column widths, and conditional formatting are stored separately from the values and reference them by index. If the styles part is damaged or an index goes stale, numbers survive but may come back looking plain: the data is right, the presentation may need redoing.

Charts, pivot caches, and embedded objects are fragile. These complex parts reference ranges elsewhere in the workbook, so when surrounding structure is damaged they break first. A recovered workbook may open with a chart missing or a pivot table needing a refresh.

VBA macros often do not survive. Macro code lives in a binary part (vbaProject.bin), not in the XML, so it does not benefit from the text-based salvage that rescues your cells. If macros are critical, keep any older copy you can find, because a recovered .xlsx may open perfectly as data while the code behind it is gone.

The workbook that was never an .xlsx

Before you treat a file as corrupted, rule out the impostor case, because it is common and the fix is free. Many web applications and reporting systems offer an "Export to Excel" button that actually produces an HTML table or a CSV file, then labels it report.xlsx so it opens in Excel by default. The file is perfectly valid; it is just not the format its name claims. Excel opens it, notices the mismatch, and shows the same "file format or file extension is not valid" message a genuinely broken file triggers.

You can spot this in seconds. Open the file in a plain text editor. If the first thing you see is <html> or a <table> tag, it is an HTML export in disguise; if you see comma-separated rows of your data, it is a CSV. In either case the fix is not repair at all. Rename it to .html or .csv and open it, or open Excel and use Data then From Text to import it cleanly. Running a repair tool on a healthy HTML file would accomplish nothing, so this check saves you from solving the wrong problem.

Financial data does not belong on a stranger's server

Spreadsheets are where privacy stops being abstract. The corrupted workbook on your desk is plausibly a payroll run, a client list, or a set of financials, and the standard online repair service asks you to upload exactly that to its servers to process it. The data leaves your machine and sits on infrastructure you do not control.

There is no technical reason repair has to work that way. The same parsing and rebuilding can run inside your own browser, on your own CPU, with the file never crossing the network. When it does, there is nothing on a server to breach, retain, or subpoena, because the file was never sent anywhere. For sensitive spreadsheets that difference is the whole decision, so confirm how a tool handles the file before you hand it your numbers.