JSON Viewer
Explore large JSON as a collapsible tree, with search, type badges and copyable paths.
JSON Viewer tool
Select path on any row to copy its dot-notation path.
What this tool does
A 4,000-line API response is not something you read top to bottom. This viewer turns it into a tree you navigate: every object and array is a collapsible node showing how many members it holds, so you can shut the branches you do not care about and drill into the one you do.
The filter box matches both keys and values and hides everything that does not match, keeping
the ancestors of each hit so you can see where it sits. Each row carries a type badge and a
path button that copies the node's dot-notation path — ready to paste into
jq, a JMESPath query, a test assertion or your own code.
Common uses
- Finding which of 60 fields in a webhook payload actually holds the customer ID, by typing part of the value into the filter.
- Reading a Terraform state file, a lockfile or a CloudFormation template without scrolling through thousands of lines.
-
Getting the exact accessor for a deeply nested field —
projects[0].settings.alerts.slack— instead of counting brackets by hand. - Checking whether an array of objects is uniform, by collapsing it and comparing counts.
- Reviewing an unfamiliar API response before writing the type definitions for it.
A short example
This document:
{"org":{"name":"Northwind"},"projects":[{"id":"prj_01","owners":["ada@example.com"]}]}becomes a tree whose rows carry these paths:
org object {1}
org.name string "Northwind"
projects array [1]
projects[0].id string "prj_01"
projects[0].owners[0] string "ada@example.com"How the paths are written
Object members use dot notation and array elements use bracket notation with a numeric index,
which is the form that JavaScript, jq (with a leading .) and most
JSONPath implementations all accept. Keys that are not valid identifiers — anything with a
space, a dash, a dot of its own, or a leading digit — are written in bracket-and-quote form
instead:
data.items[3].user_id
data["content-type"]
data.tags[0]Copying a path never copies the value, and nothing about the document is sent anywhere — the tree is built from DOM nodes in this tab.
Worth knowing
Branches are rendered only when you open them, which is what keeps a document with tens of
thousands of nodes usable. Expand all has to build every row at once, so on a
very large file it stops at 20,000 rendered nodes and tells you; filter first, then expand.
One caveat that applies to any browser-based viewer: values are read with
JSON.parse, so an integer beyond 253 — a Twitter-style snowflake ID,
for instance — is displayed as the nearest double and may differ from the text you pasted in.
The document itself is never rewritten, so Copy JSON and Download hand back what you gave it,
re-indented.
Frequently asked questions
Why are my numeric keys shown in a different order from the file?
The tree is built from the parsed value, and JavaScript enumerates any key that is a canonical array index — 0, 2, 10 — in ascending numeric order ahead of the string keys, whatever order the text used. So {"b":1,"10":2,"2":3} lists 2, then 10, then b. A key like 007 is not an index, so it stays where you wrote it.
One of my repeated keys is missing from the tree. Where did it go?
JSON.parse keeps only the last value for a repeated name, so the earlier occurrence never reaches the tree — the parsed object genuinely holds one member, even though the text holds two. The JSON validator scans the raw document instead of the parsed result and reports the line number of each repeat.
The file contains \u00e9 but the tree shows é. Has something been rewritten?
No. That escape is JSON string syntax for a single character, so the parsed value is the letter itself and any consumer receives the same string either way. It does affect searching: the filter matches the character, not the six-character escape, so type the accented letter. The Unicode converter shows the code points behind either spelling.