A 3-kilobyte API response is fine to scroll. A 3-megabyte one isn't, and a minified one isn't even scrollable — it's one line. The trick to reading JSON isn't better eyes; it's letting a parser turn the text into structure you can navigate. Here's what tree views actually buy you, when a table beats both, and how strict parsing turns "something's wrong in here somewhere" into a character position.
JSON nests. An object contains arrays containing objects containing more objects, and in flat text the only signal of depth is a column of whitespace that your eye loses track of three levels in. Pretty-printing (one property per line, consistent indentation) fixes readability but inflates size — a sample order document that's 345 bytes minified grows to 520 bytes at 2-space indentation, about 51% more — which is exactly why production APIs ship minified and humans need a viewer at all. The viewer re-adds the structure interactively: collapse what you don't need, expand the path you're hunting.
A tree view parses the JSON and renders every object and array as a collapsible node with its keys visible. Practical consequences:
shipping → address, not page-searching through 2,000 lines."5" masquerading as a number stands out immediately — a classic API bug.The JSON Viewer implements this with the open-source jsoneditor library (Apache-2.0), all in-browser — relevant when the document you're inspecting carries auth tokens or personal data.
When the top level is an array of similar objects — search results, log entries, product feeds, any REST collection. Table mode renders each element as a row and each shared key as a column, turning "compare these 40 records" into something you can actually scan. It's the view your spreadsheet brain wants, without the import step. Structure that isn't tabular (deeply mixed nesting) still belongs in the tree.
Strict parsing is your friend. JSON per RFC 8259 rejects a specific set of common mistakes, and the parser tells you where:
| Mistake | Example | Why it fails |
|---|---|---|
| Trailing comma | ["a","b",] | Nothing may follow the last element before ] or } |
| Single quotes | {'k':1} | Strings are double-quoted, no exceptions |
| Unquoted key | {k:1} | Keys are strings; bare identifiers are JS object syntax |
| Comment | // note | JSON has no comment syntax at all |
| NaN / undefined | {"x":NaN} | Only decimal numbers, null, true, false |
The error message includes a character position — Unexpected token } at position 142 — and position 142 is where your trailing comma's damage surfaces. Note that "helpful" viewers which silently accept this input are lying to you: your API, your jq pipeline, and your language's parser will all reject it. Better to catch it where it's cheap.
They're complementary habits. View (tree/table) when the structure is unfamiliar and you're locating something. Format when you've found it and need to read it, quote it, or compare two payloads — the JSON Formatter is built for that pass, and JSON Diff for the comparing-two-versions job that formatting enables. The viewer on this site can also export its current state either pretty or minified, so the round trip view → fix → ship never leaves the tab.
Watch the stats bar. A few megabytes parse instantly; rendering a million tree nodes does not, because every node is an interactive DOM element. Deep nesting (depth in the dozens) usually signals a design smell — the data wanted a table but got an object graph — and minified-vs-pretty byte counts tell you whether transport compression is worth it. For genuinely huge documents, text mode is lighter than tree mode, and slicing the file down first (per-line NDJSON split into chunks) beats heroic rendering.
Paste, upload, or load the sample — tree, table, and text modes, structure stats, and precise error positions. No upload.
JSON Viewer →Let the parser hold the structure: trees for navigating, tables for collections of records, formatted text for reading and sharing. Trust strict errors over lenient acceptance, check the stats before diving, and keep viewing (explore) and formatting (share) as two deliberate steps in your debugging routine.
In a tree viewer. Paste the JSON and it parses into collapsible nodes, so you navigate structure instead of scrolling text: close the branches you don't care about and open the path you do. For arrays of similar objects — API results, product feeds — switch to table mode, which renders them as a grid. A stats bar showing values, keys, and maximum depth tells you upfront how much digging is ahead.
Different jobs. Tree view is for exploring: navigating unknown structure, finding where a value lives, editing nodes. Formatted (pretty-printed) text is for reading a known shape end-to-end, pasting into issues and reviews, and diffing two versions side by side. Most debugging sessions use both: tree to locate, formatted text to share. A tool like ToolAspect's JSON Viewer offers tree, table, and text modes in one place.
Almost always one of five things: a trailing comma before } or ], single quotes instead of double, an unquoted key, a // or /* */ comment, or NaN/undefined where a number or null belongs. JSON per RFC 8259 allows none of these. A good viewer prints the parser's error with the exact character position — 'Unexpected token } at position 142' is a 10-second fix once you can jump to column 142.
For transport, yes; for debugging, no. Minified JSON strips every byte of whitespace — a sample order that's 520 bytes pretty-printed with 2-space indentation is 345 bytes minified, roughly a third smaller, and the gap widens with document size. APIs minify because clients re-parse anyway. But when a human has to read it, pretty-print first; that's what view and format tools are for.