A formatted JSON response can still be difficult to follow when objects and arrays nest deeply. Our JSON visualizer draws those connections as a diagram you can pan and zoom.

Use it to inspect a document's structure and export that view as Mermaid text.

What it is

The JSON visualizer takes a JSON document and renders it as a diagram of connected boxes.

Every object and array becomes a box, every nested object or array becomes a child box with a line to its parent, and the plain values inside an object are listed in the box itself.

The result is a picture of the structure. You pan and zoom it like a map, and one click redraws it after every edit.

It is built for the moment after the JSON is valid and formatted, when the question is no longer "is this correct" but "what is in here and how is it organised".

You may need that view when calling a new API or reading a colleague's config file. It also helps you inspect a webhook payload or a 300 line settings file.

You can use it right now on the JSON visualizer page, with nothing to install and no account.

The pain it solves

JSON was designed to be easy for machines to parse and reasonable for people to read.

The second half only holds while the document is small. As it grows, a few specific things go wrong, and each of them is something we hit ourselves often enough to build a tool for.

Depth becomes invisible. At six or seven levels of nesting the indentation is so wide that you cannot tell which closing brace belongs to which opening brace. You end up counting brackets by hand, or collapsing and expanding regions in the editor and losing your place.

Arrays hide their size and their shape. An array of 20 objects, each with twenty keys, is over 400 formatted lines. You cannot see that it has 20 items, or that item 13 is missing a field, without scrolling through all of it.

Structure is repeated instead of described. If every user object has the same eight keys, a formatted view shows you those eight keys 500 times. What you want to know is the shape, once.

The path to a value is guesswork. You can see a value on screen, but writing the path to it, something like data.orders[12].items[0].sku, means scrolling upward and tracking every level you pass.

Explaining the structure to someone else is hard. A pull request description or an API doc that says "the response looks like this" and pastes 200 lines of JSON gets skimmed, not read. A screenshot goes stale the week after.

Text is a poor medium for hierarchical data. JSON objects and arrays have a nested structure that a diagram can expose.

What you get from a diagram

A drawn tree fixes those problems in a direct way.

The whole shape in one screen. Depth is horizontal distance, not indentation. A document nested eight deep is eight columns of boxes, and you can see all eight without losing track of the nesting.

Arrays read as one box. An array shows how many items it holds, and its items fan out from it. Five hundred similar objects still take space, but the layout makes it obvious that they are five hundred of the same thing, rather than five hundred separate things to read.

Every value sits next to its key, inside its object. Long strings are cut to a readable length, objects with dozens of keys are trimmed with a count of what was left out, and the box stays compact enough to scan.

Redraw in one click. Edit the JSON, click View again, and the diagram updates. When you are hand editing a config file, this is the fastest way to confirm you put the new block inside the right parent.

Big files stay usable. There is a node limit of 300, so a huge document draws the top of the tree quickly and tells you it was cut, instead of freezing the page while it tries to lay out ten thousand boxes. Input is also capped at 500 lines.

As with every tool on this site, your JSON never leaves your machine.

It runs entirely in the browser, with no upload and no copy kept anywhere. You can point it at production data.

How the diagram is built: Mermaid

Under the hood the visualizer converts the JSON into a Mermaid flowchart and renders that.

Mermaid is a text based diagram language. GitHub supports Mermaid in Markdown, which makes the export useful for repository documentation.

Choosing it was deliberate, because it means the diagram is not just a picture on screen.

It is text you can copy into a README or a pull request and have it render there, with no image files to maintain.

A document like this:

{
"user": { "id": 1, "name": "Ada", "roles": ["admin", "editor"] },
"session": { "token": "...", "expires": "2026-10-01" }
}

becomes this Mermaid definition, the exact text the converter produces:

flowchart LR
n0["{ 2 fields }"]:::obj
n1["id: 1<br/>name: "Ada""]:::obj
n0 -- "user" --> n1
n2["token: "..."<br/>expires: "2026-10-01""]:::obj
n0 -- "session" --> n2
n3(["[0] "admin"<br/>[1] "editor""]):::arr
n1 -- "roles" --> n3
classDef obj fill:#eef4ff,stroke:#3b6fd6,color:#111,text-align:left
classDef arr fill:#fff4e5,stroke:#e08a1e,color:#111,text-align:left
classDef leaf fill:#f3f3f3,stroke:#888,color:#111

Paste that into a Markdown file on GitHub and it shows up as a diagram.

That is a quick way to document what an API returns, and because the source is text it diffs cleanly when the response changes.

Getting this right took more care than it sounds.

Mermaid labels go through an HTML parser, so quotes, angle brackets and even semicolons inside your JSON values have to be escaped or the diagram breaks.

Mermaid also rewrites anything that looks like #word; into a garbage token, which bites the moment a string contains a colour code or an entity.

The converter handles all of that, so a value like <div class="x"> renders as text instead of breaking the graph.

Layout choices

One setting covers most of what people want to tweak, and one limit is fixed.

Direction. Left to right is the default, which suits deep documents because depth runs across a wide screen. Top to bottom works better for shallow documents with many siblings, such as a flat list of records.

Node limit. The limit is fixed at 300 nodes and keeps drawing fast. A document that goes past it is cut at the deepest levels, and the page says so. Input is capped at 500 lines, so paste one branch of a bigger document.

How it fits with the formatter

The two tools are meant to be used in order.

The JSON formatter is the right choice when a document may be broken, when you want to sort keys or minify it, or when you need to inspect a syntax error and any available location. Once it is valid and you need to understand it, the visualizer takes over.

If you work with jq on the command line, our guide to working with JSON from the command line covers that side, and the diagram is a good way to work out which path to feed jq.

Try it on your own data

The quickest way to see whether this helps is to paste the last API response you had to read. Load it in the visualizer, click View, and compare how long it takes to answer "where is the shipping address" against scrolling the formatted text.

Then copy the Mermaid text into the README of the project that calls that API, so the next person does not have to read the raw JSON either.

If something would make it more useful for your work, say so on the Contact page.