JSON Tree Viewer

Exploring large JSON responses

When you receive a large JSON response from an API you have never used before — a Stripe webhook, a GitHub API response, a Salesforce export — the first problem is orientation. Which keys are at the top level? What is the shape of each nested object? Are there arrays, and if so, what do the elements look like?

The raw text is often hundreds of lines of minified or inconsistently indented JSON. The JSON Formatter helps by adding indentation, but a 500-line formatted JSON document is still hard to navigate. A tree viewer solves this by rendering the document as a hierarchical explorer: you see the top-level keys first, expand only the branches you care about, and ignore the rest.

The type color coding in this viewer is especially useful during exploration. Objects appear in blue, arrays in yellow, strings in green, numbers in purple, booleans in pink, and null in grey. This lets you distinguish structural keys (which hold objects or arrays) from leaf values (which hold primitive data) at a glance, without reading every value.

JSON path syntax

JSON path is a query language for JSON, analogous to XPath for XML. It was originally defined by Stefan Goessner in 2007 and has since become a de facto standard for identifying values within JSON documents. A formal specification (RFC 9535) was finalized in 2024.

The core syntax:

$                       # root element
$.store                 # key 'store' on root object
$.store.book            # key 'book' on the 'store' object
$.store.book[0]         # first element of the 'book' array
$.store.book[0].title   # 'title' key on the first book
$.store.book[*].author  # 'author' key on ALL books (wildcard)
$..price                # all 'price' keys anywhere in the tree (recursive)
$.store.book[?(@.price < 10)]  # filter: books where price < 10

The paths this viewer copies use dot notation ($.user.profile.bio) and bracket notation for array indices ($.users[2].email). These are compatible with the most common JSON path libraries and with jq's dot-notation syntax.

Using jq with paths from this tool

jq is the standard command-line JSON processor. A common workflow is to use this viewer to find the path to a value you want, then use jq to extract it from a file or API response. The paths this tool copies translate directly to jq filter syntax by removing the leading $:

# Path from viewer: $.user.profile.bio
jq '.user.profile.bio' response.json

# Path from viewer: $.pagination.total
jq '.pagination.total' response.json

# Path from viewer: $.tags[0]
jq '.tags[0]' response.json

# Extract all elements from an array
jq '.users[] | .email' response.json

# Extract a field from every element in an array and output as a list
jq '[.users[].email]' response.json

# Pipe from curl
curl -s https://api.github.com/users/torvalds | jq '.public_repos'

jq's filter syntax starts from the root implicitly, so you drop the $. Array bracket notation ([0]) works identically in both JSON path and jq. Object dot notation works the same way. If a key contains special characters or spaces, use bracket notation with a quoted string: .[" key with spaces"].

API exploration workflow

A practical workflow for exploring an unfamiliar API combines this tree viewer with the API request tools you already use:

1. Make the request — in Postman, curl, or your IDE's HTTP client, make the API call and capture the JSON response.
2. Paste into the tree viewer — paste the raw response here to understand the shape. Identify top-level keys, find where pagination data lives, check what data types the fields use.
3. Copy paths — hover over the keys you need to access in your code and click the copy icon. Paste these paths into your code as the basis for property access expressions.
4. Use the JSON Formatter — if you need to check or edit the raw JSON text, switch to the JSON Formatter which provides syntax validation and prettification.
5. Diff versions — when the API changes, paste the old and new response side by side into the JSON Diff tool to see exactly what changed.

Understanding JSON data types

JSON supports exactly six data types. Understanding which type a field uses is important for correctly handling it in your code — particularly for types that look similar in raw text but behave differently in programming languages.

• String — a sequence of Unicode characters in double quotes. Appears green in this viewer. Dates, IDs, and enums are typically represented as strings in JSON APIs. Always check whether a field is a string or a number before doing arithmetic on it.
• Number — an integer or floating-point value with no quotes. Appears purple. Beware of integers larger than 2^53 − 1 (9,007,199,254,740,991) — they cannot be represented exactly as IEEE 754 doubles, which is the underlying type JavaScript uses for all numbers. APIs that use 64-bit integer IDs often serialize them as strings for this reason.
• Boolean — the literal values true or false. Appears pink. Note that JSON booleans are lowercase — True with a capital T is not valid JSON.
• Null — the literal value null. Appears grey. Semantically distinct from a missing key — a key present with a null value is different from a key that is absent entirely. Many APIs use null to signal "known to be empty" as opposed to a missing key meaning "not applicable or not requested."
• Object — an unordered set of key-value pairs in curly braces. Appears blue. Objects can be nested arbitrarily deep.
• Array — an ordered list of values in square brackets. Appears yellow. Array elements can be any JSON type, including objects and other arrays.

When JSON is too deeply nested

Deeply nested JSON — objects five, ten, or twenty levels deep — is usually a sign of a design problem. Deeply nested structures are hard to query, hard to validate, and hard to reason about. Some common causes and solutions:

• Storing normalized relational data as nested JSON — a user object that embeds the full organization, which embeds the full subscription plan, which embeds all plan features. This nesting reflects a relational model forced into a hierarchical format. Consider flattening to a normalized API response and using IDs to reference related entities.
• JSON serialization of class hierarchies — object-oriented code that serializes class hierarchies directly to JSON tends to produce deeply nested structures. Prefer designing API responses as flat data transfer objects (DTOs) rather than direct serializations of domain objects.
• Recursive data structures — trees, nested menus, threaded comments. These legitimately require nesting but benefit from a maximum depth constraint enforced server-side to prevent unbounded recursion.

When you encounter deeply nested JSON you cannot control — from a third-party API — this tree viewer's collapsible nodes help manage the complexity. Collapse all top-level nodes first, then expand only the branch you need to investigate. The search function highlights keys by name across the entire tree, letting you find a field without manually navigating every level.

Frequently Asked Questions