Convert XLSX to ODS

Two quite different reasons arrive at the same conversion. The first is practical: somebody works in LibreOffice Calc all day and would rather hold a native file than one the program translates on every open and every save, because each of those translations is another chance for something to move.

The second is policy. OpenDocument is published as ISO/IEC 26300 and maintained by OASIS, and a number of public bodies require it for anything that has to remain readable independently of a vendor’s release schedule. When a submission form names ODS, no argument about the openness of the alternative will change what it accepts. There is a third reason that is neither, and it is the most common of all: somebody sent a workbook to a person who does not have Excel, and converting is faster than arranging a licence for one file.

This is the property that separates this conversion from every other target a spreadsheet has. A CSV or a PDF captures what the workbook currently shows; an ODS captures how it works. The formulas arrive as formulas, the dependency graph is intact, and changing an input still changes the outputs.

The translation is real work rather than a copy, because the two formats describe formulas differently — different separators, different reference syntax, different names for a few functions. LibreOffice performs it with the same code it uses when you open an XLSX by hand, which is the most exercised path in the program. Sums, lookups, conditionals, date arithmetic and text functions come through without drama. Both formats also agree about the underlying values. A date is a day count in each of them with the same day zero, so nothing shifts by one when the file changes hands — which is a genuine hazard between spreadsheet programs and is not one here.

The gap is at the recent end. The dynamic-array family Microsoft has added over the last few years, and anything else introduced faster than the OpenDocument formula specification has moved, is where a cell can come back as an error rather than a value. Add-in functions from an installed Excel extension are gone by definition, because the extension is not there.

The practical check takes a minute and is worth doing on any workbook that matters: open the result in Calc and look for error values, which stand out against a sheet of numbers. Everything else in the file is fine, and a handful of cells rewritten by hand is a far better outcome than discovering the problem three months later inside a total. If the workbook is going to be maintained in Calc from now on, the durable fix is to rewrite those formulas using functions that exist in both, rather than leaving a file that only calculates correctly in the program it came from.

All three cross over, and all three deserve a glance. Pivot tables become Calc’s equivalent and normally rebuild against the same source range; charts keep their type, series and data references while picking up Calc’s own styling defaults; conditional formatting rules survive for the ordinary comparisons.

What is fragile is the newer decoration around them. Slicers, timeline controls, cached pivot data and the more elaborate icon sets are where the two implementations stop lining up. Refresh a pivot once after opening the ODS instead of trusting the numbers it shows, because a stale cache displays perfectly plausible figures. Charts deserve the same treatment for a different reason: they usually survive as charts and pick up Calc’s own defaults, so a report built to a house style will need its colours reapplied even though every number in it is correct.

An Excel workbook’s automation is VBA written against Excel’s object model. LibreOffice has its own scripting system addressing its own object model, and there is no faithful translation between them, so the code does not come across. The cells, formulas, sheets and formatting are unaffected.

This matters more for a spreadsheet than for a text document, because a workbook’s macros are often load-bearing — a button that refreshes a report, a routine that validates entries before saving. If the file is a tool rather than a table, converting it gives you the table and not the tool, and rebuilding the behaviour in Basic is a deliberate project. It is also worth asking whether it should be rebuilt at all. A workbook that has grown macros is frequently an application that nobody agreed to write, and a migration is the rare moment when replacing it with something maintainable can actually be funded.

An XLSX sheet allows 1,048,576 rows and 16,384 columns. Modern LibreOffice matches the row figure, and its column ceiling was raised only in relatively recent releases — older versions stopped at 1,024. A sheet that genuinely uses columns out beyond that range is rare, but it is worth confirming against whichever version of Calc will actually open the file.

Rows are almost never the problem in practice, because a spreadsheet with a million rows in it has usually outgrown being a spreadsheet. If that describes the file in front of you, the honest recommendation is a columnar or database format rather than either of these two.

A workbook that pulls from another file, a database query, a web source or a Power Query step is carrying references to things outside itself. Some of those references survive as text; none of the connections are live in the same way once the file has moved formats and machines.

Before converting a workbook like that, decide whether the values or the pipeline are the thing you need. If it is the values, paste them as values first and convert a self-contained file. If it is the pipeline, the conversion is not the right tool at all and the query has to be rebuilt where it will run.

The volume case is a migration: a department moving to LibreOffice, an archive being standardised, a contractor delivering a set of models. Drop the whole folder and each workbook converts in turn, keeping its filename with the extension replaced, returning as a single ZIP.

Sample the output by risk rather than alphabetically. Open the workbook with the most formulas, the one with a pivot table, and the one somebody built a chart in, because those are where a conversion actually fails. A directory of plain data sheets can be converted and trusted; a directory of models cannot. A quick way to sort them is file size and formula count: the small workbook with two thousand formulas in it is a model, and the twelve-megabyte one with none is a data dump that will convert perfectly and does not need checking.

This conversion runs on a server, not in your browser, and the page says so rather than implying otherwise. Translating formulas between two spreadsheet formats needs a spreadsheet program, so the file travels over an encrypted connection to a container running LibreOffice headless and nothing else.

The container has no outbound network route. Each job is given its own scratch directory and its own LibreOffice profile, and that directory is deleted as soon as the job ends, whatever the outcome; a job still running after sixty seconds is terminated. The free ceiling is 25 MB per file, which a formula-heavy workbook rarely approaches and an image-heavy one reaches quickly. That is a different arrangement from the data conversions on this site, where a spreadsheet is turned into CSV or JSON entirely inside the browser. Those need a reader, not a calculation engine, and the distinction is why one set of pages can promise no upload and this one cannot.

If what you actually need is the data — to import somewhere, to load into a script, to hand to a system that wants a table — then converting to a spreadsheet format is carrying a lot of machinery you are about to discard. A CSV of the sheet you care about is smaller, unambiguous and readable by everything.

Choose ODS when somebody will keep working in the file: recalculating it, extending it, using it as the model it was built to be. That is the distinction, and it is a better guide than any comparison of the two formats’ feature lists.