Convert XLSM to PDF

An XLSM is the same ECMA-376 package Microsoft introduced in 2007 for XLSX — a ZIP of XML parts describing sheets, cells and styles — with one addition: a compiled VBA project stored inside it. The extension exists precisely so that a file containing executable code cannot pretend to be one that does not, which was the entire lesson of the macro virus era.

Everything else about it is ordinary. The sheets, formulas, formatting and charts are stored exactly as in an XLSX, which is why a workbook can be saved either way and why removing the macros produces a file that looks identical. The macro is not an attribute of the spreadsheet; it is a second document travelling in the same envelope.

This pair is unusual among conversions in that the thing that makes the source format distinctive is the thing the target cannot represent at all. Converting a JPEG to a PNG argues about compression; converting an XLSM to a PDF discards the code outright, and there is no setting that would change it.

That is worth being clear about rather than treating as a footnote, because it decides whether this is the conversion you want. If the workbook is a tool — a pricing calculator, a form somebody fills in, a model with a Refresh button — the PDF is a photograph of it and not a copy. If the workbook is a report that happens to have been built with macros, the PDF is the report, and the code was scaffolding that nobody downstream needed.

Most requests for this conversion come from the same situation. The numbers have to go to somebody — a client, an auditor, a board pack, a regulator, a supplier — and sending them an .xlsm means asking a stranger to click through a security warning and enable code written by someone they do not know.

A great many organisations answer that question centrally by refusing. Mail gateways strip macro-enabled attachments, document management systems reject them, and Excel itself blocks macros in files that arrive from the internet with a banner that most recipients will not override. Converting first removes the negotiation entirely: a PDF opens on every device, in every browser and in every viewer, with nothing to enable and nothing to decide.

No macro runs during the conversion and no formula is recalculated. The engine renders the values stored in the workbook, which is what Excel also shows when it opens a file before any recalculation happens.

For most workbooks that is invisible and correct. For a workbook where a macro populates a sheet — a report that pulls figures on a button press, a summary rebuilt from a data tab, a form that clears itself on open — it means the PDF contains whatever was on the sheet the last time somebody pressed Save. Run the macro, save, then convert. It is the single most common way this conversion produces a document that is technically perfect and shows the wrong month.

Command buttons, drop-downs wired to macros, ActiveX controls and anything else that exists to be clicked have no counterpart on a page. What the reader receives is the sheet, laid out as it would print, without the mechanism.

Whether that is a loss depends on what the controls were for. Navigation buttons and Refresh buttons are scaffolding and their absence is an improvement; a data-entry form is not, and converting it produces a document that cannot do the one thing it was built to do. If the recipient needs to enter something, a PDF form or a plain macro-free workbook is the honest answer, and this conversion is not.

A surprising number of macro-enabled workbooks set the print area, the page orientation or the repeated header rows in code, immediately before printing. That code does not run here, so the conversion uses the page setup stored in the file — which is whatever was last applied and saved, not what the macro would have applied.

The symptom is a PDF with the wrong pages in it: an extra scratch sheet, a range that stops short, or a landscape report rendered portrait across three times as many pages. The fix is the same as above and takes a minute: open the workbook, run whatever the macro does to prepare it for printing, save, and convert the saved file. Checking the page count of the result against what Excel’s own print preview shows is the fastest confirmation that the two agree.

A PDF is the same document for everybody who opens it. A workbook is not: it recalculates on the recipient’s machine, picks up their regional settings for dates and decimal separators, substitutes fonts it cannot find, and shows a different number if a volatile function or an external link resolves differently there.

For anything that will be quoted back at you — a valuation, a set of figures in a submission, a table in a contract annexe — that difference is the reason to convert. The PDF is a record of what you sent, which is a materially different thing from a file that produces something similar when opened elsewhere.

Unlike the data conversions on this site, this one does not run in your browser. Rendering a spreadsheet to a page needs a full office engine, and that runs on a server: the XLSM is sent over an encrypted connection, converted in an isolated environment with no route out to the internet, and the working files are deleted as soon as the job finishes.

The free limit is 25 megabytes per file, which is generous for a spreadsheet — most are well under a megabyte unless somebody has pasted images or embedded objects into them. Saying plainly where the file goes is better than implying it stays put; for a workbook holding figures that cannot leave your organisation at all, the right route is Excel’s own Save As, which does the same job locally.

Cell formatting, borders, number formats, conditional formatting and charts are stored in the workbook rather than generated by the macros, and they render. The engine substitutes metric-compatible faces for the common Windows fonts so that column widths and line breaks land where they did in Excel.

What moves is an unusual font that is not embedded, where a similar face is substituted and the spacing can shift slightly. Spreadsheets tolerate that better than documents do, because the grid holds the structure whatever happens inside a cell. Comments, hidden sheets and anything sitting outside the defined print area are left out, which is normally what you want when the document is going outside the building.

If the recipient needs to sort, filter, extend or re-run the numbers, a PDF is the wrong artefact and no amount of good layout fixes that. Saving the file from Excel as a plain .xlsx removes the VBA project and keeps everything else, which gets past a mail gateway and past the security banner while leaving a working spreadsheet.

Convert to PDF when the document is finished and is being sent, filed, signed or printed — when what matters is that everyone sees the same page. The two are not competing answers to one question; they are answers to different ones, and the deciding factor is whether the recipient is going to read the file or use it.