Format Bench › JSON Viewer
JSON Tree Viewer
Paste JSON and press Build tree. Each node shows its type and size, nodes collapse and expand, and clicking a key copies its dotted path so you can use it directly in code.
● Runs locally. What you paste never leaves this page.
Why a tree beats indentation for exploring
A formatter answers "is this well-formed and what does it look like". A tree answers a different question: "what is in here, and where". For an API response of a few hundred lines, indentation is enough. For a document with deep nesting or long arrays, scrolling through indented text is slow, and it is easy to lose track of which level you are looking at. Collapsing every branch you do not care about is the fastest way to see the shape of unfamiliar data.
Paths, and why they are the useful output
Clicking any key copies its path in dotted notation, for example
results[0].address.postcode. That is the expression you would
write in JavaScript to reach the value, so it can be pasted straight into code
or into a console. This turns exploration into something you can act on
immediately, rather than something you have to translate by hand.
Array elements use bracket notation with a numeric index. Keys that contain
dots or unusual characters are shown as they appear; in code those need bracket
notation with a quoted string, such as obj["odd.key"], because
dotted access would be parsed as two levels.
Reading the annotations
Every container shows how many entries it holds, and every scalar is
coloured by type: strings, numbers, booleans and null are each distinct. This
matters more than it sounds. A very common source of bugs is a numeric value
that has been serialised as a string, so an identifier arrives as
"1024" rather than 1024. In indented text those look
nearly identical. Coloured by type they are obvious at a glance.
Empty containers are also worth noticing. An array showing 0 items where you expected results usually means a query matched nothing, which is a different problem from a request that failed.
Working with large documents
The tree is built in one pass in your browser, so very large documents consume memory proportional to the number of nodes. If a document is large enough to feel slow, collapse everything first and expand only the branch you need. For documents that are genuinely enormous, extracting the relevant subtree with a command line tool before viewing is usually faster than any browser interface.
If you need to compare two documents rather than explore one, the JSON diff tool reports what changed between them, and the formatter handles normalising key order.
Questions
What notation are the copied paths in?
Dotted JavaScript notation, with bracket notation for array indices, such as results[0].name. That expression can be pasted directly into JavaScript or a browser console to reach the value.
Can it handle a very large file?
Yes, subject to browser memory, since the tree holds a node for every value. If it feels slow, collapse all branches and expand only the one you need. Nothing is uploaded regardless of size.
Why are values shown in different colours?
Colour encodes the JSON type: string, number, boolean and null are each distinct. This makes it immediately obvious when a number has been serialised as a string, which is a common and easily missed source of bugs.
Does the viewer change my data?
No. It renders a read-only view. Nothing is rewritten, reordered or normalised, so what you see is exactly the structure that was parsed.