A spreadsheet is a zip file full of XML, and it keeps more than it shows you. Selkie opens an .xlsx locally and lists what is still inside: hidden and veryHidden worksheets, hidden rows and columns, cached pivot-table source data, comments, author names and external file paths, and shows you the actual recovered content, not just a warning.
In August 2023 the Police Service of Northern Ireland answered an FOI request with an Excel file. Analysts had built new worksheets and deleted the visible tabs, but the original sheet was still in the workbook, hidden. It carried the surnames, initials, ranks, roles and locations of 9,483 serving officers. The ICO fined the force £750,000: reduced from £5.6m. Officers relocated.
.xlsx · .xlsm · .xltx, or click to choose one
Selkie reads the workbook. It does not change it. To actually remove
what you found, open the file in Excel, right-click a tab → Unhide (this will not show
veryHidden sheets: for those use the VBA editor, Alt+F11, and set
Visible = xlSheetVisible), delete the sheets, then File → Info → Check for Issues
→ Inspect Document and remove everything it offers. Re-run Selkie on the cleaned copy.
Hidden and veryHidden worksheets. A hidden sheet is one right-click away from being seen. A veryHidden sheet cannot be un-hidden through the Excel interface at all: the Unhide dialog does not list it. It can only be reached through the VBA editor. That is why senders never notice one: as far as Excel shows them, it does not exist. Selkie reads the sheet's cells directly out of the XML, so the state makes no difference to it.
Hidden rows and columns. Usually a working aid: a rate column, a calculation strip, a set of rows filtered out and then hidden. They travel with the file and are one drag of the mouse from visible.
Cached pivot-table source data. The one almost nobody knows about. When you build a PivotTable,
Excel stores a private copy of every source row inside the workbook so the pivot can be re-sliced without
the source. Deleting the source sheet does not delete that copy. A workbook whose data tab was
removed can still hand over every original row through
xl/pivotCache/pivotCacheRecords1.xml, or by double-clicking a pivot total. Selkie reads the
cache directly.
Comments and threaded notes carry author names and the frank internal remarks that were never meant for the recipient. Document properties carry the creator, the last person to save, the company and sometimes the template path. External links record the full path of workbooks you linked to, which is how internal server names and share paths escape. Defined names can still point at ranges on sheets that were deleted, naming them.
What Selkie cannot see: legacy .xls (binary, re-save as .xlsx first) and
.xlsb binary workbooks; macro code inside vbaProject.bin (it reports that
the macro blob is present, not what it does); anything a password has encrypted; images or embedded
objects; and cell values that only exist as a formula result cached by another application. A clean report
means Selkie found nothing of these kinds: it is not a guarantee that the visible data is safe to release.