JSON to Excel, one column per path

Each leaf gets a dotted path as its column header, so {"user":{"address":{"city":"London"}}} lands in a column called user.address.city. This is the same convention pandas uses in json_normalize and jq uses in its paths output, which means the header row is a set of expressions you can paste straight back into code. Flattening stops at eight levels deep; anything still nested at that point is written into one cell as minified JSON rather than exploding into hundreds of columns.

The column list is the union of every key in the document, and a record that lacks one gets an empty cell. The panel shows the fill rate beside each column — 3/400 records is a strong hint that a key is a typo or a deprecated field rather than real data — so you can untick it before exporting instead of discovering forty empty columns in Excel. Nothing is dropped silently; a key that appears once still becomes a column unless you switch it off.

You choose, because there is no answer that suits both a list of tags and a list of line items. One cell of JSON text keeps ["vip","eu"] intact and reversible; joined with a semicolon gives you vip; eu, which reads better and filters worse; and one column per position produces tags.0 and tags.1, which is right for fixed-length tuples and wrong for anything that varies. Arrays of objects always take the indexed route when you pick it, giving items.0.sku, items.0.qty and so on.

Because a spreadsheet cannot hold it as a number without changing it. JSON puts no ceiling on the size of a number — RFC 8259 only warns that interoperability suffers past what a double can carry — while every cell in a workbook is a 64-bit binary float with 15 reliable significant digits. Write 9007199254740993 as a numeric cell and the file will say 9007199254740992. Any number whose literal does not survive that round trip is written as text and counted in the status line, so a snowflake id or a bank account number comes out intact.

Yes — every column has a checkbox and a pair of arrows, and the whole list can be reordered by first appearance, A→Z, or by how many records fill it. First appearance is the default because key order in the source document is usually meaningful: the API author put id first for a reason. Moving one column with the arrows switches the list to manual ordering and leaves the rest where they were.

A single object becomes a single row, one column per key, which is what you want for a config file or one API response. An object whose values are all objects is treated as a lookup table instead: its keys become the first column and each value becomes a row, which is the shape a database dump keyed by id usually arrives in. That behaviour is a checkbox, so an object with two dozen object-valued fields can still be exported as one wide row.

Because the writer emits the five parts an .xlsx minimally needs and no more: content types, the package relationships, the workbook, the workbook relationships and one worksheet. There is no styles part, so there are no fonts, fills, borders or number formats; no formula elements; no second sheet; no images or charts. What it does emit — typed cells, column widths, a frozen header and an autofilter — needs none of those, and leaving the rest out is what keeps the file verifiable rather than nearly-valid.