Remove metadata from an Excel spreadsheet

What we remove

• Core properties — creator, last modified by, revision count, timestamps, title, subject, description, category, content status and keywords.
• Extended properties — company, manager, total editing time, and the hyperlink base URL relative links resolve against.
• Custom properties, often internal classifications.
• Comments and their authors, tucked into cell corners.
• The embedded thumbnail, a rendered preview of the sheet from when it was last saved.

Cell contents, formulas, formatting and charts are preserved.

What we deliberately keep

• Every cell, formula and chart in the workbook — styles.xml, formatting and the calculation chain are untouched.
• Named ranges and sheet structure, exactly as they were.

What a real dump looks like

Like a .docx, an .xlsx file is a ZIP archive of XML parts.docProps/core.xml and app.xml hold the same creator, company and editing-time fields Word does, and xl/comments*.xml holds cell comment threads with an author name on each one — easy to miss because comments are visually tucked into a cell corner, not sitting in the document body. Named ranges and defined names are stored separately in xl/workbook.xml and are content, not metadata, which is why this tool leaves them alone.

The package format and properties schema are defined in the same ECMA-376 standard that covers Word and PowerPoint — all three Office formats share one packaging convention (OPC, the Open Packaging Conventions) and one properties schema, which is why the metadata risk and the fix look almost identical across all three.

Content and metadata aren't always where you'd guess

A spreadsheet blurs the line more than a text document does: a cell value is obviously content, but is the workbook's calculation chain? What about a defined name that happens to be a project codename? We draw the line at whether a field describes the file (metadata, and gone) or participates in what the file computes and displays (content, and untouched) — which is why named ranges, formulas and the calculation dependency graph all survive intact even though some of them started life to make the workbook faster, not to hide anything. Nothing here requires re-running a single formula: the values a formula last calculated to are preserved exactly as saved, and Excel recalculates on open the same way it always would.

What survives common editors

Google Sheets round-trips .xlsx reasonably cleanly but rewrites app.xml on every save, replacing the original editing-time and application fields with its own — which can make a spreadsheet look like it was made in Sheets even if it started in Excel. "Save a Copy" in Excel keeps the original core properties by default; only building from a template resets them. Shared team templates are the same recurring problem as with Word: one person's name baked into a template's core.xml years ago, still there on every report built from it since.

What Excel's own inspector catches, and what it misses

Excel ships a built-in Document Inspector under File → Info → Check for Issues, and it's genuinely useful — it's just not complete. Its categories cover comments, document properties, custom XML data and hidden rows or worksheets, which is real coverage of the fields most people think to check. What it has no category for at all is the embedded thumbnail: a binary preview image, not a property field, with nothing in the Inspector's checklist that names it. Running both isn't redundant — Excel's inspector is the faster first pass, this is the one that checks the part the checklist doesn't mention.

Cleaning something else?

A spreadsheet often started life as, or gets exported to, a different format — see the document formats hub for how the same properties risk shows up across PDF, Word and PowerPoint. The same risk applies to Word documents and PowerPoint decks from the same source — check those too. Exported the sheet to PDF? That copy carries its own metadata and needs a separate pass.