JSON Viewer

When a payload is unfamiliar, start by looking at its shape:

1. Collapse all to see only the top-level keys. Most APIs wrap the useful part in something like data, items or results, next to metadata such as pagination or meta.
2. Read the counts. A collapsed node shows ...250 items... or ...12 keys.... A large array is usually the record list, and the small objects around it hold paging and request info.
3. Open one element. Records in an array almost always share a structure, so expanding [0] shows you the schema of all 250.
4. Search for what you need. Press Ctrl/⌘+F and type a key name or value. The viewer expands the ancestors of each match and scrolls to it, so you don't have to dig through the nesting by hand. Turn on regex mode to search for patterns such as ^2026- or @example\.com$.

The status bar shows the total node count and the maximum depth. Depth matters if you plan to flatten the data. Anything deeper than two or three levels needs a decision about how to name columns before it can go into the JSON to CSV converter.

Hover over a row and a badge appears with the path from the root to that value. Click the badge to select the whole path for copying. Given this response:

{
  "data": {
    "orders": [
      { "id": "ord_81", "lines": [ { "sku": "KB-01", "price": 49.5 } ] }
    ]
  }
}

hovering over the price shows data.orders[0].lines[0].price. Object keys are joined with dots and array positions use brackets, the same notation as JavaScript property access. That makes the path easy to reuse elsewhere:

The badge shows keys as they appear in the data and does not quote them. If a key contains a dot, a hyphen or a space, such as content-type, use bracket notation when you copy the path into code: headers["content-type"] in JavaScript, .headers["content-type"] in jq or $.headers['content-type'] in JSONPath. The syntax is defined in RFC 9535.

The tree is rendered virtually. Only the rows currently on screen exist in the page, and a node's children are built the first time you expand it. Scrolling a 100,000-node document therefore costs about the same as scrolling a small one. The practical limits come from the steps before rendering: the text has to fit in the editor, and the whole document has to be parsed into memory. Both depend on your machine and browser, not on this page.

If a file is too large to work with comfortably, cut it down before you open it:

# first 50 records only
jq '.data.orders[:50]' huge.json > sample.json

# just the shape: keys of the first record
jq '.data.orders[0] | keys' huge.json

Two common inputs are not a single JSON document. Log exports in JSON Lines (NDJSON) format have one object per line, which fails with Unexpected non-whitespace character after JSON. Run jq -s '.' file.ndjson to wrap the lines into an array first. Very large integers, such as 64-bit IDs from Twitter-style APIs or database keys, lose precision when parsed. 9007199254740993 shows as 9007199254740992 because JavaScript numbers are 64-bit floats. If exact IDs matter, the API usually offers a string version of the field (for example, id_str).

Switching views doesn't lose anything. The text stays as you left it. For comparisons, format both documents with the same indentation in the JSON formatter and paste them into the diff checker. If the tree refuses to appear, the input isn't valid JSON yet. The JSON validator explains each error message.