JSON to Excel

No. An xlsx is fundamentally a ZIP archive containing a defined set of XML parts. As long as those parts are structurally correct, any standards-compliant spreadsheet application opens it. The files generated here contain every required part and were validated by actually opening them with Python’s openpyxl — checking the Chinese worksheet name, number and boolean types, special-character escaping and whitespace preservation one by one. Those validation results are frozen into automated tests to catch regressions later.

For the same reason as every other tool here: data does not leave the browser. Adding a third-party library does not technically violate that promise, but you cannot verify that the library never phones home, and that doubt is enough to deter people from using it on real data. Everything needed to produce an xlsx — compression and XML assembly — is available natively in the browser, so a self-contained implementation is entirely feasible. The only cost is extra validation work, which is paid for with cross-verification and regression tests.

No. Detected numbers are written with a numeric type and booleans as TRUE/FALSE. This matters a lot: written as text, cells show the green warning triangle, SUM returns 0, and sorting compares strings — so "10" sorts before "9". Note however that if the JSON literally contains the string "123" in quotes, it stays text, because that is the genuine type of the source data.

Nested objects flatten into dotted paths by default: user: { addr: { city: "Berlin" } } yields a user.addr.city column. Arrays are serialised as JSON text in a single cell by default. Both behaviours are switchable — turning flattening off writes the whole object as JSON text in one cell, which suits cases where you only want to preserve the original structure. There is a depth limit, and exceeding it is reported rather than expanding without bound and blowing up the column count.

Yes, and both are preserved. JSON null becomes a genuinely blank cell, while an empty string "" is written as empty text. They look similar in Excel but behave differently under filtering and formulas, so they are not merged. That is also why null is never written as the string "null".

The theoretical limit is Excel’s own: 1,048,576 rows by 16,384 columns. In practice your browser’s memory binds first — hundreds of thousands of rows will get noticeably slow. There is also a separate, lower column cap, since very wide tables are hard to use; exceeding it produces a notice. Everyday API payloads and exported reports sit far below these limits.

Column order follows **first appearance** of each field across all records. If one record lists its fields in a different order, the earliest occurrence wins. This both guarantees every field is included and keeps output order stable and predictable — the same input always yields the same column order.

Yes — your browser will present a save dialog where you choose the name and location (depending on your browser settings). The worksheet name is set on the page and is a separate thing: the file name identifies the file on disk, while the sheet name is what appears on the tab at the bottom of the Excel window.