The .json file.
The format every API returns and no spreadsheet accepts. Turning one into a table involves decisions, and which decisions were made is the part usually left unsaid.
Also .ndjson, which are read the same way.
What it actually is
JSON is a tree. A table is a rectangle. Every JSON-to-table conversion therefore involves choosing where to cut the tree, and different cuts produce genuinely different datasets from the same file, all of them defensible.
An export of orders where each order contains a list of line items can become one row per order, with the items collapsed, or one row per item, with the order fields repeated. The first answers questions about orders; the second answers questions about products. Neither is the correct reading in the abstract.
Newline-delimited JSON is the same data with one record per line, which is what most large exports and log files use because it streams. It is read the same way here and folds into this page.
At a glance
- Shape
- A tree, not a table
- Types
- String, number, boolean, null, object, array
- Numbers
- IEEE 754 doubles in most parsers, so integers above 2^53 lose precision
- Schema
- None, unless separately supplied
- Variant
- NDJSON, one record per line, for streamed exports
- Read here as
- Direct. Nested objects flatten with the path kept as the column name.
- Status
- Ready
- Fidelity
- Read directly
- Largest file
- 250 MB
Nested objects are flattened into tables, keeping the path as the column name.
Upload one
The analysis runs before there is anything to pay for. You see what it found, and the evidence behind it, first.
No account needed to start. You only pay when you like what you see.
What goes wrong, and what is done about it
01
Long ids losing their last digits
A 19-digit Twitter-style or Snowflake-style id exceeds what a double can represent exactly. A parser that reads it as a number returns a value that is close and wrong, and the corruption is invisible because the id still looks like an id.
Integers beyond the exact-representation range are read as strings, so the value that arrives is the value that was written.
02
The flattening you got is not the one you wanted
One row per order and one row per line item give different answers to every per-unit question, and an export flattened the wrong way produces totals that are correct for a question you did not ask.
The chosen shape is reported in the methodology with the record count each way, so a wrong cut is visible immediately rather than after the analysis.
03
Fields that are absent rather than null
JSON lets a key simply not be there. Absent and null are different facts — never asked versus asked and empty — and collapsing them into a blank cell destroys the distinction that a coverage figure depends on.
Missing keys and explicit nulls are counted separately in the data dictionary, so a 40% null column and a 40% absent column are not reported as the same thing.
Questions people ask
My JSON is deeply nested. Will it cope?
Yes. Nested objects are flattened with the path preserved as the column name, so `customer.address.city` stays legible, and repeated arrays become their own related table rather than a column of text.
What about a JSON file that is one enormous array?
Fine. If it is large enough to be awkward, export NDJSON instead — one record per line streams a record at a time, so size stops mattering.
Can it read an API response I saved?
Yes, including the envelope most APIs wrap results in. The actual records are located inside the response rather than the whole payload being treated as one row.