XLS, XLSX, XLSM and XLSB: Which Is Which, and Which You Want

The one fact that explains the family: rename it to .zip

Take a copy of any .xlsx, change the extension to .zip, and double-click it. It opens. Inside is a folder tree: [Content_Types].xml declares what every part is, _rels/.rels says how the parts point at each other, xl/workbook.xml lists the sheets, xl/worksheets/sheet1.xml holds the cells, xl/styles.xml holds the formatting. The test file for this article had exactly ten such members. That is the whole design: a workbook is a zipped bundle of small XML documents, standardised as ECMA-376 and later as ISO/IEC 29500.

Once you have seen that, the rest of the family stops being a mystery. XLSM is the same ZIP with one more part allowed inside it — xl/vbaProject.bin, the compiled macro project — and a content type that tells Excel to expect one. XLSB is the same ZIP again, with each XML part replaced by a binary record stream: in the test file, xl/workbook.xml became xl/workbook.bin, xl/worksheets/sheet1.xml became sheet1.bin, xl/styles.xml became styles.bin. Same container, same layout, different encoding of the contents.

XLS refuses the trick, and that refusal is the point. Its first eight bytes are D0 CF 11 E0 A1 B1 1A E1 — the signature of an OLE2 compound file, a little filesystem-in-a-file that Microsoft used for Office documents before 2007. There is no ZIP, no XML, nothing a modern tool can walk into without a dedicated parser. Everything awkward about XLS follows from that: it is a different kind of object wearing a spreadsheet's name.

Why an organisation still receiving XLS has a real problem

The problem is not nostalgia, it is attack surface. Reading an XLS means running a hand-written binary parser over untrusted bytes: seek to a stream, read a record type, read a length, trust the length. That shape of code has produced a long line of Office memory-corruption advisories over two decades, and it is why Microsoft ships File Block settings that let an administrator refuse legacy binary formats outright, and why macros in files that arrived from the internet are blocked by default rather than merely warned about.

The second problem is quieter and costs more: XLS caps out at 65,536 rows and 256 columns. A modern export that exceeds either is truncated rather than refused, and a truncated report looks exactly like a complete one. If a process anywhere in your organisation still produces .xls, that is the thing to check first, before the security question.

The fix is not to ban the extension, which only pushes the file into an email attachment nobody logs. The fix is to convert it on arrival and keep the original somewhere read-only. That is what this page's converter is for: it reads XLS, XLSX, XLSM, XLSB, ODS and Apple Numbers, and it writes XLSX. One output, always, in your browser, with nothing uploaded.

XLSM, and the thing this converter will not tell you

XLSM exists for one reason: XLSX is not allowed to contain macros, so a workbook that runs code needs a different content type and a different extension. That separation is deliberate and it is a good design — you can tell from the filename whether a spreadsheet can execute anything, before you open it.

Which brings us to what running this converter actually showed. A workbook was built for the test that really carries xl/vbaProject.bin, declared in [Content_Types].xml exactly as Excel declares it. The tool read it happily. The macro project did not survive in either direction: the reader is never asked for it, so it is discarded before conversion even begins, and the .xlsx that comes out contains no VBA part at all — the ten members of the output were checked one by one. So: converting an XLSM here gives you a working spreadsheet with the code removed, and no message saying so.

That is often exactly what you want. Stripping a macro from a workbook that arrived by email is a reasonable act of hygiene, and the surest way to do it is to convert to XLSX and keep the result. It is a disaster if the macros were the point — a monthly model somebody in accounts built in 2011 and nobody has read since. Know which case you are in before you press the button, and keep the original either way.

When XLSB is worth its incompatibility

On a small sheet, XLSB buys almost nothing. The 201-row test file was 44,343 bytes as .xlsx and 28,505 as .xlsb, and neither took a measurable moment to open. At 25,000 rows by 5 columns the gap becomes an argument: 5,031,220 bytes against 3,780,567, and 562 milliseconds to parse against 234. That is the whole case for XLSB, and it is a real one — a quarter off the disk and less than half the time to read, because the parser is handed numbers instead of a text document it has to tokenise.

The price is portability, and it is steep. XLSB is a Microsoft binary part format: the specification is published, but every tool that reads it has had to implement it separately, and support outside Excel is patchier and later than for XLSX. Web previews, mail clients, statistics packages and half the scripting libraries in the world will open an XLSX and stumble on an XLSB. There was one more measured surprise: writing the 25,000-row XLSB through the same library took 21 seconds against half a second for the XLSX. That is a property of that particular writer rather than of the format, but it is a reminder that the fast side of XLSB is the reading side.

So the rule is narrow. Use XLSB when the file is measured in millions of cells, lives inside one organisation, is opened only in Excel, and the seconds saved on every open are worth something to somebody. Everything else is XLSX — including anything you will send to a person whose software you do not control.

What the converter kept, and what it did not

The test sheet had 200 formulas in its last column and a date column, and each of the five formats was fed through the tool's own read-and-write path. Rows: 201 out of 201, every time. Dates: preserved as dates, not as serial numbers, in all five. Formulas: 200 out of 200 kept from XLSX, XLSM and ODS. Zero kept from XLSB and zero from XLS — the values arrived, the calculations did not.

That last line needs an honest footnote. The XLS and XLSB test files were written by the same library that read them back, and that library's writers for those two formats store the cached value without the formula. So the measurement proves the round trip is lossy; it does not prove that a real Excel-written XLS would lose its formulas on the way in. The practical advice is the same either way, and it costs one minute: open the converted file, click a cell that should be a calculation, and look at the formula bar before you delete the original.

One more thing worth knowing about the reader: it asks for cell stubs. A cell whose formula is present but whose cached result is empty — common in workbooks written by a generator, or saved without recalculating — would otherwise be thrown away entirely, formula included. Keeping the stub is why a converted file can show you a formula that has never produced a number.

Frequently asked questions

Can I just rename an XLS to XLSX?

No, and it is the single most common way people lose a file. The extension is a label; the bytes underneath are an OLE2 compound file, not a ZIP. Excel will usually notice and refuse, or open it with a warning about the extension not matching the content. Anything less forgiving simply errors. A rename works only between XLSX, XLSM and XLSB, which really are the same container — and even there you are lying to the content type, which causes its own problems. Convert instead.

Will converting my XLSM to XLSX break it?

It will break the macros and nothing else. The cells, the formulas, the formatting and the sheet names come through; the compiled VBA project does not, because XLSX has no place to put one. This was checked on a workbook built specifically to carry xl/vbaProject.bin — the output contained no VBA part at all, and no warning was shown. If the macros are load-bearing, keep the XLSM and convert only a copy. If the macros are unwanted, this is the cleanest way to remove them.

Is XLSB really faster, or is that a myth?

Real, but only at scale, and only on reading. On a 201-row sheet it is 28,505 bytes against 44,343 and neither takes a measurable moment to open. On 25,000 rows by 5 columns it is 3,780,567 bytes against 5,031,220, and 234 milliseconds to parse against 562 — a quarter smaller and read in less than half the time. Writing that same file, in the library used for this test, was the other way round: 21 seconds for the XLSB against half a second for the XLSX. Judge XLSB on how often the file is opened, not on how big it looks in a folder.

How do I tell what a file really is when the extension is wrong?

Look at the first bytes. 50 4B — the characters PK — means a ZIP, so XLSX, XLSM, XLSB, ODS or a plain archive. D0 CF 11 E0 A1 B1 1A E1 means an OLE2 compound file: XLS, DOC, PPT or an old MSI. Plain text with commas or semicolons and no signature at all is a CSV that someone has renamed. On macOS and Linux the `file` command reports all of this in one line; on Windows any hex viewer shows the first row. This is also how the converter on this page decides what it has been given, rather than trusting the name.

Does the converter upload my workbook anywhere?

No. The whole conversion runs in your browser: the spreadsheet library is fetched once, the file is read from your disk into memory, and the new workbook is written back out as a download. Nothing leaves the machine, which is exactly what you want for the case this page is really about — a legacy workbook full of names, salaries or client records that you would rather not post to a stranger's server just to change its extension.