When is JSON to Excel useful?
JSON to Excel is the last step of a lot of small data jobs. An API response has to be handed to someone who lives in a spreadsheet, a log extract has to be filtered by a colleague, or a set of test records has to be reviewed row by row. A CSV file would do for some of those, but a workbook is what people actually open, and a workbook that was generated properly opens without an import dialog. The ZIP container, the workbook parts, and the worksheet XML are all written by this page inside the tab, then handed straight to the download.
The table is built the same way the JSON to CSV page builds one. Every record becomes a row and every leaf value becomes a cell. A nested key is joined with a dot, so a customer object holding a city field produces a column named customer.city. An array stays in one cell as JSON text rather than being spread across columns, because spreading it would change the number of fields per row without warning. Columns are collected across all records in order of first appearance, so a key that appears only in the last record still gets a column and the earlier rows leave it empty.
Cell types are chosen from the value, not from the column. A JSON number is written as a numeric cell, so a price can be sorted, summed, and charted the moment the workbook opens; a boolean is written as a boolean cell; a null or an empty string leaves the cell empty; and everything else is written as text. A string that only looks numeric, such as 007, stays text, because turning it into a number would silently drop the leading zero. A record that is not an object has no column names, and the page reports which record broke instead of skipping it quietly. A very large array produces a large sheet and a slow download, so split anything past a few tens of thousands of rows.