Reading the two tables
The structure table has one row per value, indented by depth, with the full path underneath the key name. data.users[0].email is the email of the first user, and the notation is deliberately the same expression you would write in JavaScript to read it, so paths are copy-and-paste rather than translate-and-hope.
The schema summary collapses array indices: every data.users[0].email, data.users[1].email and so on rolls into one row at data.users[].email, with a count and the set of types that path held. Two types in one row means the elements disagree. The occurrence count against the array length tells you whether a field is on every element or only some.
Mixed types, and why they surface here rather than in production
In the sample response loaded by default, the first user's id is the number 1 and the second's is the string "2". JSON permits this happily. Your consumer generally does not: a strict equality check against a number quietly fails on the string, a sort produces nonsense, and a generated TypeScript interface degrades to number | string which tells you something is wrong without telling you what. The same thing happens with a field present on some elements and absent on others — the count column shows it as fewer occurrences than the array has elements.
Both are cheap to see on a sample and expensive to discover from a stack trace. Scanning the summary for red before writing the mapping code is about thirty seconds well spent, and it converts a class of runtime bug into a conversation with whoever owns the endpoint.
null, empty array, empty string, missing key
These are four different states and they usually mean four different things. Roughly: null is "no value has been set", [] is "we looked and found none", "" is "set, to nothing", and an absent key is "not applicable to this response". On screen all four render as blank, which is exactly why they get conflated in code.
The one that breaks things is an API that sends null where an array is expected — iterate over it without a guard and you get a runtime error on the first response that has no results. Turning on the nulls-and-empties filter gives you a list of every place in the payload where that risk lives, which is the list of spots your mapping code needs a default for.
Handling a large response
Fully expanding a list of several thousand records produces a table with tens of thousands of rows and a browser that stops responding. Three limits keep that in check: the depth cap, a hard ceiling of fifty expanded elements per array, and the row limit. The schema summary is built from the full walk regardless of what the table shows, so a truncated table still gives you a complete field inventory underneath.
The order that works: set the depth to two or three to see the skeleton, find the branch you care about, then put a key name into the path search to expand only that. If the payload is measured in megabytes, cut it down before pasting — this is a page for understanding a response, not for processing one.
It runs where you are
Parsing, walking and rendering all happen in the tab. Nothing is uploaded, no request is made, and there is no storage of any kind, which is stated plainly because the natural input for this page is a production response containing an authorization header or a customer record. The residual risk is entirely local: the values are rendered on your screen, so think twice while screen sharing or recording.
Questions people ask
My JSON has a duplicate key and only one of them shows up.
JSON.parse keeps the last occurrence and discards the earlier ones, so by the time anything is walked the duplicate is gone. The specification does not define what a parser must do with duplicate keys, and implementations differ — some take the first, some error. If you need to know whether the original text has duplicates, search the raw response; no structural tool can tell you after the parse.
A large number is displayed slightly wrong.
JavaScript numbers hold integers exactly only up to about 9.007 quadrillion. An ID above that is rounded during the parse, before this page sees it, so the value shown is genuinely the value your browser has. The fix belongs on the server: large identifiers should be sent as JSON strings. Until then, check the raw text for the true digits.
Is it safe to paste a response containing an access token?
From a network standpoint, yes — everything happens in the page, no request is made, nothing is written to storage, and closing the tab ends it. The remaining exposure is visual, since the values are rendered in a table on screen. If you are sharing your screen or recording, redact the field first, or use the path search to keep the interesting branch on screen and the token off it.
Why does the array stop expanding after fifty elements?
Because expanding a thousand-element array produces a table nobody reads and a tab that stutters. Fifty is enough to see the shape and to catch elements that disagree with each other. The schema summary is built from the entire array regardless of the display cap, so the type and occurrence counts underneath are complete even when the table says items were not expanded.