A Macro-Free Document Is Not Automatically a Safe One

There is a moment, after you convert a macro-enabled workbook to a plain one, where the job feels finished. The dangerous extension is gone. The file opens without a yellow warning bar. Whatever was in it that could run, cannot run.

All of that is true, and it is worth more than it sounds. Code execution is the largest single risk an Office document carries, and removing it is the change that most security policies are actually written around.

But "cannot execute code" and "is trustworthy" are different statements, and the gap between them is where people get surprised. Not because a converted file is dangerous - it is meaningfully safer than what went in - but because a document is a rich format with several legitimate ways to reach outside itself, and only one of them is macros.

What the extension is actually for

An .xlsm file is an .xlsx file with one extra piece inside it. Sheets, formulas, charts, pivot tables, formatting: stored identically in both. The difference is permission - one is allowed to contain a macro project and the other is not.

That is not a technical necessity. It is a policy signal, and it exists so that something upstream of the user can make a decision cheaply. A mail gateway can reject one extension and accept the other without parsing the file. An upload form can allow one and refuse the other. A group policy can be written in terms of it.

Which is why converting between the two is not really a conversion at all. It is a removal, and the reason it is worth doing is that afterwards the file has nowhere left to store executable code - so the guarantee comes from the format rather than from a setting somebody could change.

We wrote about the mechanics of that on the tool pages: XLSM to XLSX for workbooks, DOCM to DOCX for Word, PPTM to PPTX for presentations. This post is about the question that comes after: what does the resulting file still get to do?

Three things a perfectly ordinary .xlsx can do

None of these are exploits. They are documented features that spreadsheets and documents have had for decades, and most of the time they are exactly what the author wanted.

It can reference content on another machine. A workbook can link to a cell in another workbook, hold an external data connection, or display an image stored at a URL. When the file opens and those references refresh, your machine makes a request. That request tells whoever controls the other end that the document was opened, roughly when, and from which IP address. On a corporate network, a reference pointing at a file share rather than a web address can be worse than that, because Windows will try to authenticate to it.

This is why Office asks before updating links, and why that prompt is not just bureaucracy. It is the boundary Microsoft chose: the content is allowed to be there, and you are asked before it is fetched.

It can carry another file inside it. Embedding an object - a PDF, an installer, another workbook - is a normal feature used for genuine reasons, like attaching a source document to a report. The embedded thing does not run on its own; someone has to double-click it. But it does travel with the document, past filters that only looked at the outer file's extension, and it arrives looking like part of a document somebody already decided to trust.

It can be built to be read wrongly. The oldest trick in the category is not active content at all: a sheet with rows hidden, white text, a column scrolled far off to the right, or a filter applied. Nothing executes. The reader simply does not see part of what they were sent. This one deserves mentioning because it is the risk that survives every technical control on this page.

There is also a historical vector worth knowing about because it comes up in older guidance: a field-based mechanism that could launch external commands from a document without any macro involved. It was used in real attacks, and current Office builds disable it by default. If you are dealing with modern, patched Office it is largely closed; if you are dealing with old installations or unusual configurations, it is a reason not to assume the absence of macros means the absence of execution.

So what is removing macros worth?

Quite a lot, and it is worth being precise about why rather than vague about it.

Macros are the only one of these capabilities that runs code of the author's choosing, automatically, with the permissions of the person who opened the file. Everything else in the list either needs a human to double-click something, announces itself with a prompt, or simply hides content rather than doing anything. That difference in severity is not marginal - it is the difference between "this file might tell someone you read it" and "this file installs something".

Removing macros also changes the file rather than the environment, and that turns out to matter more than it first appears. Office does block macros in various situations now, depending on where the file came from, how it arrived, and how the installation is configured. Those are all conditions, and conditions vary: the same file that was blocked arriving by email may not be blocked after a trip through a file share, a zip, or a synced folder. A file that has no macro project in it produces the same outcome on every machine, on every route, forever.

And it makes archives auditable, which no policy setting can do after the fact. If you convert ten thousand workbooks, you can state something verifiable about all ten thousand.

Verify it yourself, in ten seconds

You do not have to take anyone's word for whether a file contains macros - including ours. A modern Office file is a ZIP archive, so you can look inside without opening it in Office at all, which is also the safe way to inspect something you are unsure about.

unzip -l workbook.xlsx | grep -i -e vba -e macro

No output means no macro parts. Run the same command on the original .xlsm for contrast and you will see what was there.

The same approach answers the remote-reference question, which is the one nobody thinks to check:

mkdir -p inspect && cd inspect && unzip -q ../workbook.xlsx
grep -rlE 'https?://|file://' . | grep -v docProps

Hits in externalLinks, connections, or relationship files mean the workbook points at something. That may be entirely legitimate - a link to last quarter's model on a shared drive - but now you know it is there before you open the file and get asked about it.

For Word, the equivalent worth looking for is a reference to a remote template, which lives in the document's relationship files and is fetched on open.

Choosing the right control for the situation

Different situations warrant different amounts of effort, and treating them all the same is how people end up either careless or paralysed.

Documents of ordinary provenance, at scale. An archive of workbooks from your own company, files from a known supplier, a decade of reports being migrated. Converting is the right control, and it is proportionate: it removes the capability that matters, keeps the content intact, and gives you something you can state about the whole set.

An attachment you were not expecting. The provenance is the problem, not the format. Converting first is a genuine improvement, and it is better done somewhere other than the machine you use - which is the argument for converting through a service or on an isolated box rather than opening the file to convert it. If you then need to view it, a viewer that does not fetch remote content answers the link question too.

Something you actively believe is hostile. Do not open it on a machine you care about, and do not treat conversion as the answer. Removing macros is a control for the ordinary case; isolation is the control for this one. If you need the content, extract the content - pull the text or the tables out rather than opening the document.

The mistake is not using the wrong tool. It is using a good tool and then believing it did something it did not claim to do.

What "sanitized" honestly means

Different tools use the word for different scopes, and the scope is the whole point. Removing macros addresses code execution. Removing metadata addresses what the file says about you and your organisation. Removing active content from a PDF addresses a different set of triggers again - that one we wrote about separately, and Sanitize PDF is the tool for it.

A claim of "clean" without a stated scope is not a security claim, it is marketing. The useful question to ask of any tool, ours included, is not whether it sanitizes but what specifically it removes and what it deliberately leaves alone - because a document that had every feature stripped out of it would no longer be a document.

For the macro tools the answer is narrow and deliberate: the macro code is removed and the rest of the file is preserved exactly, because the people who need to de-macro a financial model are the last people who can afford to have their pivot tables rearranged in the process.

Common questions

Is .xlsx safer than .xlsm? Yes, in the specific sense that it cannot execute code. That is a real and useful difference, not a cosmetic one.

Can a .docx phone home? It can, through legitimate features like linked content and remote templates. Office prompts before fetching, and the check above tells you in advance whether there is anything to fetch.

If Office already blocks macros, why convert? Because blocking is conditional on origin and configuration, and converting is not. The file behaves the same everywhere afterwards.

Does converting change my formulas or formatting? It should not. Anything that re-renders the workbook risks disturbing pivot tables and conditional formatting, which is why the approach that preserves the untouched parts exactly is the one worth wanting.

Related reading: why a black box does not redact a PDF, the file conversion privacy checklist, and getting data out of Excel.