The data still in a spreadsheet you thought you deleted

An .xlsx is a zip, and the sheets are only some of it

Rename a copy of a workbook to .zip and open it. A small test workbook built for this page holds these parts, among others:

Deleting something from the grid is a change to one of those parts. Several of the others are not touched by it.

Hidden, and the one nobody has heard of

Every sheet in the book appears in xl/workbook.xml as a <sheet> element with a name and a relationship id. A hidden sheet has one more attribute:

The attribute takes three values: visible, hidden and veryHidden. The first two behave as you would expect. A veryHidden sheet does not appear in the Unhide list, so nobody browsing the workbook in Excel finds it from the interface at all; it takes the VBA editor or unzipping the file. It was never meant as a security feature, and is routinely treated as though a sheet marked that way is gone.

It is not gone. The sheet's own part is still in the zip with every cell in it. X-RAY reports both of the test workbook's hidden sheets by name, and marks the second as very hidden.

The shape of data that was removed

Hidden rows and columns are one attribute each: <row r="4" hidden="1"> and a <col> entry with hidden="1" on it. The cells inside them are ordinary cells with ordinary values.

Two more things describe data that is no longer visible. The autofilter is stored as <autoFilter ref="A1:D40"/>, a range written when the filter was applied, and the print area is a defined name called _xlnm.Print_Area. Either can name a rectangle far larger than anything still on the sheet, which tells a reader how many rows there used to be.

Ordinary defined names do the same more directly. The test workbook carries two:

The range may be long gone. The name is a sentence about what used to be in it, and it is sitting in xl/workbook.xml.

Text survives the cell it was in

Excel does not store text in the cell. It keeps one pool of strings for the whole workbook in xl/sharedStrings.xml, as a list of <si> items, and a cell that holds text is written as a type-s cell whose value is a position in that list:

Clearing a cell removes the reference. Whether the entry itself goes depends on whether the application rebuilds the pool, and a pool item that no cell points at any more is still a valid file. The test workbook has one on purpose: item 8 reads Redundancy shortlist: Okafor, Beltran, Doyle, no cell in any sheet refers to it, and it opens in a spreadsheet application without complaint and shows nothing.

The same pool is shared with the sheets you deleted. This is exactly why CLEANSHEET rebuilds the table rather than leaving it: on the test file it walks the surviving sheets, keeps only the items they still reference, renumbers every cell's index to match, and the pool goes from nine items to six.

A number outlives the formula that made it

A formula cell holds two children: the formula and the last value it produced.

The <v> is the cached result, kept so the file can be displayed without recalculating first. Remove the <f> and the number stays. That is deliberate when CLEANSHEET does it: the visible figures are untouched and the workings, including the reference to a sheet you would rather nobody knew about, come out.

Read the other way round, a cached value is evidence. A number computed from a sheet that is no longer in the workbook is still the number, and the formula beside it names the sheet, the cell and the multiplier.

xl/calcChain.xml is a companion to all this: a list of which cells hold formulas, by cell reference and sheet index. CLEANSHEET deletes it, because once the formulas are gone it would name cells that no longer calculate and Excel reads that as a damaged file. Excel builds it again on the next save.

The pivot cache, which is the one that catches people

A pivot table does not read the source rows when it draws itself. It reads a cache: a private copy of the source data, written into the workbook as its own parts. That is what makes a pivot fast, and what lets it keep working when the source is not open.

The copy is in two files. xl/pivotCache/pivotCacheDefinition1.xml names the source in a <worksheetSource> element, then lists every column as a <cacheField> with a <sharedItems> list of every distinct value in that column. xl/pivotCache/pivotCacheRecords1.xml then holds one <r> element per source row, with an <x> index into the shared items for text and an <n> for a number.

The pivot table part itself refers to the cache by cacheId. It never names the sheet. The link runs table to cache, and the cache remembers the sheet, which means deleting the sheet breaks nothing and removes nothing.

This was tested rather than assumed. The test workbook has a pivot table over a very hidden Payroll sheet of names, teams and salaries. The Payroll worksheet part was then deleted from the zip, along with its entry in the sheet list, its relationship and its defined name. Opened afterwards, the workbook has two sheets and no Payroll. Its pivot cache still says:

Those four rows were read back out of the file by a standard spreadsheet library, not carved out by hand. The sheet is gone and the salaries are not. refreshedBy adds the name of whoever last refreshed the pivot.

What to do before you send a workbook

Look at it first. X-RAY unpacks the zip in the browser tab and reports the author, the account that saved it last, the revision count, the editing time, the company, and every hidden and very hidden sheet by name.

Then clean it. CLEANSHEET is the spreadsheet pass. On the test workbook it removed both hidden sheets and their parts, both defined names that pointed at them, the pivot table and both pivot cache files, xl/calcChain.xml, the comments part and the drawing that renders the note boxes; it froze the one formula to its cached value; and it rebuilt the shared string pool down to the six items still in use. It keeps the print area, because that one still refers to a sheet that is still there.

Check what the numbers are about. DATASCAN reads a CSV or JSON export and names the columns that look like personal data (emails, phone numbers, national insurance and social security numbers, card numbers, addresses), which is the question of whether the data should be leaving at all, rather than where it is hiding.

And check for credentials. SENTINEL reads every XML part inside the zip, not only the visible cells, so a key or a token sitting in a hidden sheet, an orphaned shared string or a pivot cache is in scope. It reports on Office files; it does not rewrite them.