JSON to Excel

Why line items break every other converter

Take an order with two lines in it. There is one order and there are two lines, so there is no single row that holds both without either repeating the order or hiding the lines. A spreadsheet is a rectangle and the data is not.

{ "id": "00721", "total": 79.5,
  "lines": [ { "sku": "A-1", "qty": 2 },
             { "sku": "A-2", "qty": 1 } ] }

There are only three answers, and most tools pick one without telling you which. Put the array in one cell as JSON text, which looks tidy and cannot be sorted, filtered or summed. Repeat the order across two rows, which doubles the total and quietly breaks anyone who adds up that column. Or name the columns lines.0.sku and lines.1.sku, which works until a third line appears and the columns change shape.

The fourth answer is the one a database would use, and it is the one here.

The order goes on one sheet and the lines go on another. Every line carries the key of the order it belongs to and its position in the array. Nothing is repeated, nothing is hidden, and the two sheets can be put back together with a lookup, a pivot table or a Power Query merge. It is the shape your data already had, written down honestly.

What is not claimed. No accuracy percentage and no promise that the workbook will be the shape you had in mind, because only you know that. What is claimed is narrower and you can check it on your own file: every value that went in comes out in exactly one cell, and every child row points at a parent row that exists. The counts for your file are printed above the table each time you convert.

The cells that look right and are not

A converter that writes everything as text is safe and useless: you cannot sum a column of text, and the dates sort alphabetically. A converter that writes everything as whatever Excel guesses is worse, because it damages data and says nothing. Both are common.

Excel keeps fifteen significant digits. That is not a bug, it is the format. A sixteen digit reference such as a Stripe charge, a bank transaction ID or a Snowflake key goes in whole and comes back with the last digit changed to a zero, and the cell still looks perfectly normal. The same thing happens the other way round to a postcode: 01067 becomes 1067 and Dresden turns into a number.

Dates have three traps of their own and all three are silent. A string like 2026-02-30 is not a date, but JavaScript turns it into the second of March without complaint, so it stays text here instead. A timestamp carrying an offset like +05:00 has no home in a spreadsheet, because Excel has no timezone at all, so converting it would move the clock by five hours and say nothing: it stays text too. And Excel's day numbering is unreliable before March 1900, thanks to a leap year that never happened, so anything older stays text.

So each value is decided on its own. A number that fits in fifteen digits is written as a real number. Anything longer is written as text, because the digits matter more than the arithmetic. A string that is an ISO date becomes a real date cell with a date format on it. True and false become real booleans. Everything else stays text, and the page lists every value where this rule did something, so you can see it rather than discover it later.

There is one more thing a spreadsheet does that nobody expects. A cell whose text begins with an equals sign, a plus, a minus or an at sign is treated as a formula when the file is opened. In a file you were sent, that is how a spreadsheet runs somebody else's instructions on your machine. Those values are prefixed so they stay text. If you need them raw, the checkbox above the convert button turns the guard off.

Excel's own limits, guarded rather than mentioned

Every tool in this category that mentions these limits mentions them in a help page. None of them act on them, so a file that crosses one produces a workbook that will not open, or opens with data missing. The limits are fixed and they are not secret:

• 1,048,576 rows per sheetA sheet past this is split into numbered parts and the page says which and how many. Nothing is cut off.
• 16,384 columns per sheetA record with more keys than this is named rather than silently trimmed.
• 32,767 characters per cellA long description or an embedded base64 blob is reported with the sheet and column it sits in.
• 31 characters per sheet nameDeep paths make long names. They are shortened, and two that shorten to the same thing are given different numbers rather than producing a corrupt file.

Sheet names are the quiet one. Excel also forbids a colon, a backslash, a slash, a question mark, an asterisk and square brackets in a sheet name, and a workbook that contains one does not report an error. It fails to open.

The records are rarely at the top of the file

A real API response is wrapped. There is a status, a page number, a count, and the records you actually want are two levels down inside data or items or results. Paste that whole response into most converters and you get a one row sheet describing the envelope.

When a file has more than one array in it, the arrays are listed with the number of records in each, and the one that holds records rather than plain values is suggested first. You pick. You can also write the path yourself in the usual notation, so $.data.items[*] converts the records and leaves the envelope out of it.

The workbook says how to put itself back together

A workbook split across five sheets is only useful if you can tell which sheet joins to which. That is knowledge the converter has and then throws away, so every one of these files arrives as a pile of tabs and the person who opens it has to work the relationships out by reading them.

So the first sheet is a map. It lists every sheet, how many rows it holds, which sheet it came from, which column joins the two, and the lookup formula that rejoins them. Paste the formula into the child sheet and the parent's fields come back alongside the lines. Nothing to work out and nothing to remember.

And then there is the question nobody else lets you ask: did it convert correctly?

Next to the download button is a button that takes the workbook apart and builds your original JSON back out of it, then compares the two key by key, value by value, and in order. If anything had landed in the wrong sheet, lost its place in an array or gained a key it never had, the two would not match and the page would say exactly where. It is the same check the test suite runs on a thousand generated files before anything ships, pointed at your file instead.

Why this is the strongest check there is. Counting values proves nothing was lost. It cannot prove anything landed in the right place, because the total comes out the same either way. Rebuilding proves placement and structure together: there is only one arrangement of sheets that turns back into the file you started with.

What has actually been tested

Every figure here is a test run that has to pass before anything reaches this page. If one fails, nothing ships. A number on a page that nothing checks goes stale, so a test reads this page, pulls out every figure in it, and compares each one with the code behind it.

• 30Every file that ships, scanned for generated copy, inline styles, off-origin loads and broken asset paths ship
• 20Every value decided on its own: numbers, dates, booleans, long references and leading zeros types
• 14The live page in a real browser, under the security policy it ships with e2e
• 13Finding the records inside an envelope, and the notation that points at them path
• 12Whole awkward files pushed through the converter and counted back out files
• 12Input nobody would type: control characters, overrides, four thousand keys, a key called __proto__ adversarial
• 12A thousand files turned back into JSON and compared with what went in rebuild
• 12Nested arrays turned into sheets, and the keys that keep them joined to their parent sheets
• 10Every number printed on this page, checked against the code behind it figures
• 9The shape of the workbook: what becomes a column, what becomes a sheet plan
• 8Every icon and image is the real brand asset, at the size the page claims brand
• 7Excel's own limits for rows, columns, cell length and sheet names limits
• 7The two rules: every value in exactly one cell, every child row linked to a real parent account
• 8Layout at seven screen sizes, with the browser text enlarged, and the contrast of every line visual
• 5A hundred thousand records, with the cost per record held flat scale
• 5The same file twice gives a byte identical workbook, and random text never converts determinism

What it will not do

• It will not tell an empty string from a blankExcel has no way to hold the difference. A field holding "" comes out as an empty cell, the same as a null. The CSV export keeps the difference if you need it.
• It will not read Excel and give you JSONThat is the other direction and this page does not do it.
• It will not repair broken JSONA trailing comma or an unquoted key is reported with the line and column where it sits. Guessing at a repair would be guessing at your data.
• It will not style the workbookHeaders are bold and frozen and the columns are sized to fit. There are no colours, no conditional formats and no charts.
• It will not decide your schema for youIf the shape of the workbook is not what you wanted, pick a different path and convert again. The tool will not reorganise your data on a hunch.

Questions people ask first