JSONビューアー
JSON Viewer renders a document as a collapsible tree in your browser. The tree is virtualized over a flattened row list, so a fifty-thousand-node API response opens and scrolls at the same speed as a small one, and every row carries the RFC 6901 pointer that addresses it.
このツールの画面は英語表記です。
以下の解説は英語のみでご覧いただけます。
How does JSON Viewer work?
A JSON viewer is judged entirely by how it behaves on a document that is too big to read as text — which is the only reason anyone opens one. Most fail there, and they fail for the same structural reason: they render the tree as nested components, one per node. That is the obvious implementation and it means a fifty-thousand-node response produces fifty thousand DOM elements, of which perhaps forty are on screen. Scrolling becomes janky, expanding a branch re-renders its whole subtree, and the tab starts consuming hundreds of megabytes.
This viewer flattens the document into an array of rows first — each one carrying its depth, its type, its child count, and the index at which its subtree ends — and then renders only the rows inside the viewport. The DOM holds around fifty elements regardless of document size, so a large file opens as quickly as a small one.
Recording where each subtree ends is what makes collapsing cheap. Hiding a branch is a single index skip rather than a walk over everything inside it, so collapsing the root of a 50,000-node document costs one comparison instead of fifty thousand. The same structure makes search sensible: matches are found across the whole document, not just the expanded part, and every ancestor on the path to a match is kept, because a value without its path tells you nothing.
Flattening is iterative, with an explicit stack rather than recursion. A recursive walk overflows the JavaScript call stack somewhere around ten thousand levels of nesting, and a document that deep is precisely the document someone brings to a viewer because nothing else will open it. There is a test at twenty thousand levels.
Each row shows the RFC 6901 JSON Pointer that addresses it — /order/lines/0/sku — and copies it on click. That is the string you paste into a JSON Patch, a jq path, a test assertion or a bug report, and having it exact removes the most tedious step of working with an unfamiliar response.
Document
{"order":{"lines":[{"sku":"WID-1","qty":2}]}}Tree
▾ root { 1 }
▾ order { 1 }
▾ lines [ 1 ]
▾ 0 { 2 }
sku "WID-1" /order/lines/0/sku
qty 2 /order/lines/0/qtyWhat options and edge cases does JSON Viewer support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Initial depth | levels | 2 | Containers deeper than this start collapsed, so a large document opens as a readable overview rather than forty thousand lines. Expand all is one press away. |
| Virtualization | viewport only | — | Around fifty rows exist in the DOM at any moment, whatever the document size. This is the difference between a viewer that opens a 20 MB response and one that hangs the tab. |
| Search | substring | case-insensitive | Matches keys and rendered values across the entire document, including collapsed branches, and keeps every ancestor of a match so the path stays visible. |
| JSON Pointer | RFC 6901 | shown per row | Click to copy. Keys containing / or ~ are escaped as ~1 and ~0, so the pointer is correct rather than merely plausible. |
| Type colours | string, number, boolean, null | — | Scalars are coloured by type, so a numeric string "42" is visibly different from the number 42 — a distinction that causes a surprising share of integration bugs. |
| Editing | not supported | — | This is a viewer. For editing values, renaming keys and reordering arrays, use the JSON Editor, which keeps a text pane and a tree in sync. |
| Input size | bytes | 8 MB | Parsing runs on the main thread. Above the ceiling the tool declines rather than freezing. The tree itself handles far more nodes than the parser ceiling permits. |
Frequently asked questions
Will it open a really large file?
Up to the 8 MB parse ceiling, yes, and the tree is not the bottleneck — it renders only what is on screen, so node count barely affects it. The limit is the parse step, which runs on the main thread and is declined above 8 MB rather than attempted, because attempting it locks the tab.
What is the /order/lines/0/sku next to each row?
The RFC 6901 JSON Pointer that addresses that node. Click it to copy. It is the path you paste into a JSON Patch operation, a test assertion, or a bug report, and having it exact — including the ~0 and ~1 escapes for keys containing ~ and / — removes the most error-prone part of describing where something is.
Can I edit values here?
No, deliberately. A viewer that also edits has to reconcile two sources of truth on every keystroke, which is why the JSON Editor is a separate tool: it keeps a text pane and a tree synchronised, with undo. Keeping this one read-only is what lets it stay fast on documents the editor would struggle with.
Why is my number shown in a different colour from my string?
Scalars are coloured by type. It matters more than it sounds: the string "42" and the number 42 look identical in raw text and behave completely differently downstream. A quoted value being a string where an integer was expected is a recurring cause of integration failures, and colour makes it visible at a glance.
Does search look inside collapsed branches?
Yes. The search runs over the whole flattened document rather than the visible rows, so a match buried in a collapsed subtree is found and shown along with the ancestors that lead to it. Clear the query and the tree returns to whatever you had expanded.
Is the document uploaded?
No. It is parsed and rendered by JavaScript in the tab you already have open. Open DevTools, go to the Network panel and paste a response — nothing carrying it leaves. The documents people need a viewer for are usually production API responses, which is exactly the material that should not pass through an unknown server to be made readable.