Does the tree view show array indices?

No. The tree always collapses array indices, so an array of fifty objects contributes one branch describing the shape rather than fifty near-identical branches. If you need the literal index of a specific element, use the dot-notation key paths format instead.

What do the labels in brackets mean?

Each line ends with the JSON type of that key's value: object, array, string, number, boolean, or null. Because JSON itself does not distinguish integers from floats, every numeric value is reported as number.

Is the tree view a JSON formatter?

No. A formatter re-prints your data with indentation and keeps every value. The tree view discards values entirely and shows only the structure, which is what makes it readable for large documents where the values would drown out the shape.

Is my JSON uploaded to a server?

No. The document is parsed in JavaScript inside your own browser tab. Your JSON is never transmitted, logged, or stored anywhere.

JSON Tree Viewer - View JSON Structure as an Indented Tree

See the shape of a JSON document at a glance. The tree view strips out every value and redraws the document as an indented outline of key names, each annotated with its type. It answers the question you actually have when an unfamiliar API response lands in front of you - how is this thing organised? - without making you scroll through hundreds of lines of data to work it out.

View your JSON as a tree

Opens the tool with the indented tree format already selected.

Open the tree viewer

A worked example

Take the same order payload used elsewhere on this site:

{
  "user": {
    "name": "Ada Lovelace",
    "address": { "city": "London", "country": { "code": "GB" } },
    "roles": ["admin", "engineer"]
  },
  "orders": [
    { "orderId": "ord_1001", "total": 249.99 },
    { "orderId": "ord_1002", "total": 15.50, "giftMessage": "Happy birthday" }
  ]
}

As a tree, it becomes:

user  (object)
  name  (string)
  address  (object)
    city  (string)
    country  (object)
      code  (string)
  roles  (array)
orders  (array)
  orderId  (string)
  total  (number)
  giftMessage  (string)

Eleven lines describe the whole document. Indentation carries the nesting, so you can see immediately that code lives three levels deep inside user, and that orders is an array whose elements have three fields between them.

Why array indices are always collapsed

The tree is a structural view, so repeated array positions are merged before anything is drawn. The two orders in the sample above produce a single orders branch rather than one branch per element. For an array of fifty records that difference is the whole point - drawing fifty near-identical branches would bury the shape under repetition.

A side effect worth knowing: the branch is the union of the fields seen across all elements. giftMessage appears in the tree even though only the second order carries it. That is usually what you want from a structural view, but it does mean the tree tells you a field can appear, not that it appears on every record. When you need to know which specific element has which field, switch to dot-notation key paths, which keep the literal index.

Tree view vs a JSON formatter

These solve different problems and it is worth being clear about which one you need.

	JSON formatter	Tree view
Keeps values	Yes, all of them	No, structure only
Output length	Grows with the data	Grows with the schema
Repeated array elements	Printed in full	Merged into one branch
Shows types	Implicitly, by syntax	Explicitly, on every line
Best for	Reading one specific record	Understanding an unfamiliar payload

A ten-thousand-line API response with a repetitive results array will still format to ten thousand lines. The same document usually reduces to a tree of a few dozen, because the size of a tree tracks the complexity of the schema rather than the volume of the data.

Common uses

Onboarding onto an unfamiliar API - understand the response shape before you write a single line of parsing code
Checking nesting depth - find out how far down a field really sits before designing your accessors
Reviewing a payload in a pull request - paste the tree into the description so reviewers see the shape without a wall of sample data
Spotting structural drift - diff the tree of two API versions to see schema changes without the noise of changed values
Explaining a structure to someone else - the outline reads well in a ticket, a design doc, or a chat message

Reading the type labels

Every line ends with the JSON type of that key's value - object, array, string, number, boolean, or null. Two caveats apply:

All numbers are number. JSON does not distinguish integers from floats, so neither can the label.
null describes the sample, not the contract. A field that happens to be null in the document you pasted is labelled null, even though the API may return a string for it most of the time.

If you want the full path to each key rather than an indented name, the typed key paths format gives you the same type information against complete dot-notation paths.

How to use it

Copy a JSON response from your API client, browser DevTools, or a .json file
Open the tree viewer - the indented tree format is preselected
Paste into the left box, or drag the file straight onto it
Click Extract Keys, or press Ctrl + Enter
Copy the outline, or download it as a .txt file

Other output formats

Flatten JSON to dot notation - one full path per line, indices kept or collapsed
Convert JSON to a TypeScript interface
Generate JSONPath expressions
Unique key names only - the distinct key vocabulary, sorted

JSON Tree Viewer