Convert NDJSON to XLSX

This is the only conversion of a line-delimited file on this site that is aimed at a human being. Every other target — CSV for a loader, SQL for a database, Parquet for a query engine — assumes software at the other end. A workbook assumes somebody who will open it, widen a column and sort by date.

If the file is going into a pipeline, this is the wrong page and CSV or Parquet is the right one. If it is going to a colleague, a client or a finance team, a workbook saves the exchange that follows a text file: how do I open this, why are the reference numbers wrong, which column is which.

A delimited file has no types at all, so Excel infers one per column when it opens the file. That inference is where the familiar damage happens: leading zeros vanish from account and product codes, anything date-shaped becomes a date, and identifiers past fifteen digits lose their last digits to floating point.

The records in an NDJSON file already carry their types — a quantity is a number, a flag is a boolean, a reference exported as a string is a string. Writing them into a workbook preserves that distinction in the file itself, so nothing is inferred on opening and a code of 00714 arrives as 00714. That single difference removes an entire category of support conversation.

A field whose value is an object becomes one column per leaf, with the path as the heading: a nested user object holding a name arrives as a column called user.name, carrying the type it had in the record. Arrays flatten by position instead, so a tags list of a and b becomes tags.0 and tags.1, and the headings are the union across the whole file — a list that is occasionally long adds a column for every position it ever reaches.

The consequence is width rather than loss, and width is its own problem when the recipient is a person. An event record with a request block, a user block and a context object can reach thirty columns from six fields, which is a sheet nobody reads. Where the nested blocks are not the point, stripping them with jq before converting gives a narrower workbook, and the columns that remain are the ones the reader was asked to look at.

The workbook has a single sheet, because a newline-delimited file is a single stream of records with no internal divisions to map onto tabs. Its name comes from the file name without the extension, cut to 31 characters, which is the limit a sheet name has.

If the extract genuinely holds several kinds of record — the mixed-event log described below — several workbooks or several conversions of filtered files produce a far more usable result than one sheet with a discriminator column. Splitting the file first is a one-line command against a format designed to be split.

Each line in the source is independent and nothing requires the second to have the keys of the first. The conversion collects every key seen anywhere in the file and gives each one a column, leaving cells empty where a line has nothing for it.

Nothing is dropped, and a file mixing three event types produces a sheet where each row uses a third of the columns. For a person receiving that, it reads as a broken export even though it is a faithful one. Filtering the source to a single event type before converting is worth the extra step, and it is the difference between a spreadsheet somebody uses and one they ask you about.

One line becomes one row, so the row count is the line count minus any blank lines. That is knowable before you convert: wc -l, or the line number at the bottom of an editor.

It is worth checking against what a spreadsheet is a reasonable container for. A workbook of a few thousand rows opens instantly and is pleasant to work with; several hundred thousand rows opens slowly, filters slowly and produces a file most mail systems will reject as an attachment. Past that size the answer is to aggregate before converting — a count per day, a summary per customer — because nobody receiving the file was going to read a million rows either.

Two checks take a minute together. First, count the columns: a sheet much wider than the field list means a nested block or an array flattened out, and it is worth deciding whether the recipient needs those columns at all. Second, look at the identifier and date columns and confirm they read as you expect rather than as five-digit numbers or truncated codes.

And read what is actually in it. A line-delimited extract is machine output, and it usually contains every field the system emits — internal identifiers, flags, trace references, occasionally an email address nobody expected to be in there. A spreadsheet makes all of it visible in a way a log file does not, which is a much better thing to discover before the file leaves your organisation than after.

Values are written as the records held them, with no rounding, reformatting or locale applied. A price of 12.5 is the number 12.5 in the cell, displayed according to whatever the recipient’s Excel is set to, and a timestamp exported as an ISO string stays a string rather than becoming a date serial.

That last one is a deliberate limit rather than an oversight: an ISO timestamp is text in JSON, and turning it into an Excel date would mean guessing a time zone. If the recipient needs sortable dates, the reliable route is a formula or a text-to-columns step in the workbook, done once by somebody who knows which time zone the log was written in.

Both halves run in this browser tab: the file is parsed line by line and the workbook is assembled by a library loaded on demand. Nothing is uploaded, there is no account or queue, and the free tier accepts up to 100 MB with memory as the real ceiling.

For this pair the privacy property is more than a talking point, because the extract is by definition about to be shared. Converting it through a third-party service means the data reaches two recipients rather than one, and only one of them was intended. Doing it locally keeps the list to the person you are actually sending it to.

Send a CSV when the recipient is a system, or when the sheet came out too wide to read and a delimited file is going into a script anyway. Send Parquet when the destination is a query engine and the same records will be read many times. Send the NDJSON itself when the recipient is an engineer, because it is the only version that still has the structure.

The workbook is the right answer for exactly one situation and it is a common one: a person who needs to look at this data today, without installing anything, and who will judge the export by whether the columns make sense at a glance.