JSON Viewer

Why a tree instead of raw text

A 4,000-line API response in a terminal or a network tab is technically readable and practically opaque. You cannot see where one record ends and the next begins, you cannot tell how deep you are, and finding the one field you care about means scrolling and counting brackets.

A tree fixes the two things that actually slow you down: it collapses everything you have not asked to see, and it always knows the exact path of the row under your cursor. That path is the bridge back to code — it is what you paste into a JSONPath query, a jq filter or a property accessor.

Reading a row

Each row carries four pieces of information: the key, the value, the value type, and — for objects and arrays — how many children it holds. The child count is the one people underuse. It tells you at a glance that items has 340 entries without expanding it, and it is how you spot the empty array that should not be empty.

Right-click any row for the actions that matter when you are moving between the browser and an editor:

Keys that are not valid identifiers are written in bracket form automatically, so a path like $['shipping-address'].city is always pasteable.

Searching with field prefixes

Plain text in the search box matches keys, values and paths at once, which is the right default when you are exploring. When it returns too much, narrow it with a prefix.

Case sensitivity and regular-expression mode are toggles next to the box. type: on its own is a legitimate query: type:null with no search term is the fastest way to audit a document for missing data, and type:array shows you every collection in one list.

Navigating without the mouse

The ← behaviour is worth internalising: pressed repeatedly it walks you up the document, which is the fastest way to get out of a branch you have burrowed into.

The same document, five ways

The view tabs are not separate tools — they are different projections of the document already in memory, so switching costs nothing and loses nothing.

• Tree — structure and paths. The default for exploring.
• Table — an array of records as rows and columns. The fastest way to compare records to each other, and the basis of CSV export.
• Analyze — counts, depth, and data-quality findings such as inconsistent types and duplicate identifiers. See the analyzer.
• Schema — a JSON Schema inferred from the document.
• Code — typed models in TypeScript, Python, Go, Rust and five more languages.

A useful habit: open an unfamiliar response in Tree, then switch to Analyze before you write any code against it. The findings usually tell you something the documentation did not.

Large documents

Three things keep a big file usable. Parsing and analysis run in a Web Worker, so the interface does not freeze while they work. The tree renders only the rows actually on screen, so a 200,000-node document scrolls like a short one. And collapsed branches are never walked at all — expanding is what costs, not loading.

Accepted file types are .json and .txt; you can also drop a file onto the editor or paste directly. The practical ceiling is your machine, not the page — a document that fits comfortably in memory will view comfortably.

Nothing leaves the browser

The viewer is a static page. Your document is parsed by JavaScript in your own tab, held in memory, and discarded when you close it — there is no upload, no request carrying your data, and no server-side copy to delete. You can verify that yourself: open DevTools, watch the Network tab, and paste a document.

That matters most for the documents people most need to inspect — production responses, exported records, anything with a customer in it.