The .json file.
Also .ndjson, which are read the same way.
- 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, as one table. An array of flat records reads cleanly. Nothing is flattened for you.
- Status
- Ready
- Fidelity
- Read directly
- Largest file
- 25 MB free, 250 MB once a project is bought
What it actually is
Nested objects are flattened into tables, keeping the path as the column name.
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.
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
3 named failures, each with the repair.
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.
What is done: Nothing here rescues it. Quote long ids as strings in the export, before the file is written, because once a large integer has been through a parser the digits it lost cannot be recovered.
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.
What is done: Neither cut is made here: the file is read as it stands. Choose the shape in the export instead, one record per row of whatever you want to count, because it is not chosen afterwards.
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.
What is done: Both arrive as an empty cell. An absent key and an explicit null are read the same way, so where the distinction matters it has to be encoded in the export, a sentinel value, or a flag of its own, since it does not survive the read.
Questions people ask
About this format, not about the product.
My JSON is deeply nested. Will it cope?
Not well. The file is read as one table and nothing is flattened into path-named columns, so a deeply nested export arrives with its structure intact and very little of it usable as a column. Export the records array on its own, or send NDJSON with one flat record per line.
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?
It is read as it stands, envelope and all. Nothing goes looking for the records inside a wrapper. Save the array of records on its own, or send NDJSON, so the rows arrive as rows.
Keep reading
The jobs people do with this file, and the formats beside it.