JSON Table Viewer

Why flattening is the useful operation

JSON is a tree and a table is a rectangle, and most of the time the reason for opening a JSON document is to answer a question that is rectangular in nature: how many records are there, what values does this field take, which rows are missing something. Flattening is the translation between the two. Each object becomes a row, and each leaf in the tree becomes a column identified by the path taken to reach it. Nothing is discarded; the structure is encoded in the column names instead of the indentation. That makes the data sortable, scannable and exportable in a way the raw document is not.

Dotted paths and their limits

The dotted path convention — user.address.city — is compact and familiar from most query languages, but it is lossy in one specific way: a key that itself contains a dot becomes ambiguous. That is rare in practice and the alternative, quoting every segment, makes ordinary paths harder to read. Arrays introduce a second question. A list of scalar values is joined into one cell, because a column per tag would be unusable. A list of objects is indexed, because collapsing objects into a cell would destroy the data. Both choices favour keeping information visible over keeping the table narrow.

Sorting mixed data honestly

Every value in a flattened table is text, which makes sorting more subtle than it appears. Sorting numbers as strings puts 10 before 9 and 100 before 20, producing an ordering that looks deliberate and is wrong — arguably worse than no sorting at all, because it invites conclusions. This tool compares numerically when both values in a comparison parse as numbers, and falls back to a locale-aware text comparison otherwise. Empty cells are treated as absence rather than as the empty string and collect at the end of the column regardless of direction, so an ascending sort does not open with a screen of blanks.