Convert Parquet to XLSX

A .parquet file arriving in an inbox is a small failure of translation. It is the standard format inside a data platform — compact, typed, fast to query — and it is not a format any office application treats as its own. There is no File, Open route for it in Excel, and what the Power Query connector will accept depends on which version and licence you happen to have in front of you.

Asking for a different export is often the right answer and is not always available: the person who sent it may be in another timezone, the pipeline may only write Parquet, or the file may be the artefact of a job that has already finished. Converting it yourself takes a moment and does not require anything to be installed.

This is the reason to convert to XLSX rather than to CSV, and it is a real difference rather than a preference. A Parquet file records the type of every column. A CSV records none, so every value becomes text and Excel applies its own interpretation on import — which is where identifiers become numbers and codes become dates.

A workbook cell carries its type. Numeric columns arrive as numeric cells and boolean columns as boolean cells, so a sum works on the first click, a filter offers a numeric range rather than a list of strings, and a pivot table treats the amount column as an amount. Nothing has been re-inferred from characters, because the values never became characters on the way through.

Timestamps are the exception. A timestamp column is written as an ISO 8601 string — `2024-03-11T09:30:00.000Z` — and lands in a text cell, so it will sort correctly as text but will not respond to date arithmetic or feed a date filter in a pivot table.

Converting it is a known operation and takes about ten seconds per column: select the column, Data, Text to Columns, Next, Next, and on the final step choose Date with YMD as the order. Excel then parses the value into a real date. The reason the conversion does not do this for you is that the time zone and the display format are decisions about presentation, and making them in Excel — where you can see the result — is better than making them silently in a file.

A worksheet holds 1,048,576 rows including the header row, and 16,384 columns. That is a limit of the spreadsheet format itself, so no converter can exceed it and no version of Excel will show you the rows beyond it.

Parquet files routinely hold more than that, because the format exists for tables a spreadsheet cannot hold. When the extract is over the line the honest answer is that it needs filtering or aggregating first, and the person who produced it can do that far more cheaply than you can. Ask for the rows for one month, or for the totals by category, rather than for a bigger file — a question asked upstream usually turns a million rows into a few thousand that answer it better.

Parquet has a 64-bit integer type, and a spreadsheet holds about fifteen significant digits. A value beyond what can be represented exactly is written into the cell as text rather than as a number that has been rounded.

That is the right way round even though it looks inconsistent next to the other numeric columns. An order reference or a transaction identifier that has been rounded still looks like a valid identifier, matches nothing, and is very difficult to trace back; the same value as a left-aligned text cell is obviously text and is correct. If a column of long numbers appears left-aligned in the workbook, that is what it means, and it should stay text rather than being converted to a number to tidy the alignment.

Parquet can hold a list, a struct or a map in a single column. A spreadsheet cell holds one value, so those columns are written as JSON text: a list appears as `["a","b"]` in one cell and a struct as an object with its member names.

It is readable and it is not workable. There is no formula that will treat it as data without a substantial amount of text manipulation, and a pivot table sees one long string. If those columns matter to the analysis, the fix belongs upstream: ask for them flattened into separate columns in the export, which is a one-line change in whatever query produced the file and turns an unusable cell into three usable ones.

A Parquet file holds exactly one table with one schema, so the workbook has one worksheet. It takes its name from the file with the extension removed, trimmed to the thirty-one characters a worksheet name allows, which means a long generated filename is cut rather than rejected.

The column names come through as the footer recorded them, including any underscores, prefixes or path-like segments that a data pipeline gave them. They are frequently not the names anyone would choose for a report, and renaming them in the first row is the normal first step. Doing it in the workbook is safer than asking for a renamed export, because the original names are what the data team will use when you go back with a question.

Considerably. Parquet stores values in binary form, compresses each column separately, and holds a repeated value once with small references to it; a worksheet stores a cell per value with its own type and style references, inside a ZIP of XML.

A modest Parquet file therefore produces a workbook several times its size, sometimes far more when the columns are highly repetitive — the ones that compressed best going in are the ones that expand most coming out. It is worth checking the row count before converting a file you have not looked at, since the expanded table is held in memory while the workbook is built and the ceiling arrives sooner than the size on disk suggests.

The Parquet reader and the spreadsheet writer are both libraries loaded on demand by this page, and the conversion runs there. No request carries the file, so an extract that has not yet been aggregated or masked does not become a copy on a third party’s server because somebody needed to look at it in Excel.

That is usually the constraint that decides whether an online converter can be used at all for this pair. A Parquet file from a data platform is normally closer to the raw table than to a report, and uploading one is precisely what a data handling policy exists to prevent.

If the analysis is going to be repeated every week, ask for the pipeline to write an XLSX or a CSV directly. Converting by hand each time is a step that will eventually be forgotten, and a scheduled export is a two-line change at the other end.

If the question is a single number — a total, a count, a comparison between two months — asking for the answer is faster than asking for the data, and the person with the query engine can produce it in seconds. Convert the file when you genuinely need the rows in front of you: to check a sample, to build a model on top of them, or because the next thing that has to happen is a spreadsheet regardless.