JSON Viewer

Why a tree beats a formatted block

Formatting solves the line-by-line readability problem. It does not solve the navigation problem, and for large documents the navigation problem is the harder one.

Consider an API response with a hundred records, each with thirty fields, nested four levels deep. Formatted, that is three thousand lines and a great deal of scrolling, and the structure only becomes apparent if you read carefully enough to track the indentation. As a tree with the first two levels open, it is a list of a hundred collapsed rows and you can see the shape immediately.

The tree also solves the width problem. Indentation pushes deeply nested values further right with every level, so a document twelve levels deep becomes a narrow column of text on the right-hand side of the screen. A tree draws one indentation guide per level and keeps values on a readable measure.

The practical split: use a formatter when you are going to copy the text somewhere else or edit it by hand. Use the viewer when your goal is to understand what is in the document.

What the colour coding is telling you

Type information is the most underrated part of a tree view. JSON has six value types, and the difference between two of them is a frequent source of production bugs:

• Strings are green. This is where API type confusion lives: "42" and 42 look similar in a formatted block and behave completely differently in code. A string sorts lexicographically, so "10" comes before "9".
• Numbers are amber. Note that JSON has one number type — there is no integer literal — so whether a value arrives as a float depends on what the producer wrote.
• Booleans are purple. Worth watching, because a boolean-typed field that suddenly arrives as the string "false" is truthy in JavaScript.
• Null is grey and deliberately dim, so it does not compete for attention with real values.
• Objects and arrays are the branches, shown with a count of how many members sit inside.

The string-versus-number distinction is the one to watch for. A price field that is sometimes 19.99 and sometimes "19.99" will work in one code path and produce NaN in another, and it is invisible in a formatted block while obvious in a coloured tree.

Using the path list to write code against unfamiliar data

The path list flattens the document into one line per leaf value, using the notation you would actually write to reach it. Numbers and simple identifiers use dot notation; anything else uses bracket notation.

items[0].sku
items[0].price.amount
items[0].price.currency
items[12].tags[3]
meta.pagination.total

Notice the fourth line in that example. The array index is irregular — index 12, tag 3 — and that is exactly the kind of detail a path list surfaces and a manual read misses. If your document is a collection where only some records have a given field, the path list shows you which indices carry it.

The workflow this is built for: paste an unfamiliar API response, copy the path list, and use it as a scaffold for the fields you need to destructure. It is considerably faster than clicking through a tree looking for the right nesting level, and it produces a reference you can keep next to your code. If you then need those paths as a TypeScript interface, generating one by hand from the list is a short step.

One caveat: if an array contains hundreds of elements, the path list is correspondingly long. In that case collapse to the depth you need first, or paste a single record rather than the whole collection.

Handling very large documents

Rendering is the expensive part, not parsing. Every node in the tree is a real DOM element, and browsers slow down measurably somewhere in the tens of thousands of nodes. Three habits keep large documents responsive:

• Set Depth to 1 or 2 before you view. Collapsed branches are not rendered, so starting shallow and expanding only the path you need keeps the node count low. Set Depth to All on a large document and you may wait.
• Slice the document rather than viewing all of it. If you need to inspect one record out of five thousand, copy that record and view it on its own.
• Format instead when you need the text. If your goal is to copy a section out, the JSON Formatter produces a plain textarea that you can select from directly, with no tree to render at all.

On memory generally: the document is held in the page, so a very large one stays in memory until you navigate away. Reloading the page is the cleanest way to release it.

JSON Lines and arrays of records

Data that arrives one record per line — logs, exports, streamed results — is not a single JSON document, so the viewer will report an error. Wrapping the records in an array makes it viewable, and the tree then shows one indexed branch per record, which is a convenient way to compare their shapes and spot records where a field is missing.

If a record turns out to be malformed while others are fine, that is useful information in itself: it usually means the export was interrupted mid-write, or that a field contained an unescaped newline and split one record across two lines.

To convert, add a comma between records and wrap the whole thing in square brackets. The JSON Validator will confirm the result parses before you paste it here.