Our JSON formatter does one job: it takes a wall of JSON and adds line breaks and indentation. For a small document that is enough. For the kind of JSON you actually meet at work, a 4,000 line API response or a config file with objects nested eight levels deep, formatting only turns an unreadable line into an unreadable page. The next tool on mybittools.com is a JSON visualizer, and this post explains what it will do and why.
Why JSON stops being readable as it grows
JSON was designed to be easy for machines to parse and reasonable for people to read. The second half of that only holds while the document is small. A few things go wrong as it grows:
- 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.
- Arrays hide their size. An array of 500 objects, each with twenty keys, is 10,000 lines. You cannot see that it has 500 items, or that item 137 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 actually want to know is the shape, once.
- Finding a path 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. - Comparing two documents is nearly impossible by eye. Two responses that differ in one nested field look identical when printed.
Text is a poor medium for hierarchical data. JSON is a tree, and a tree is best understood as a tree.
What visualizing it fixes
The visualizer takes any JSON document and renders it as an interactive tree. Every object and array becomes a node you can expand or collapse. Collapsed nodes show their size, so a 500 item array reads as one line that says orders [500] until you open it. That alone turns the 10,000 line problem into a ten line overview.
On top of the tree, the features we are building first:
- Click to copy a path. Select any value and get its full path in dot or bracket notation, ready to paste into JavaScript, Python or a jq filter.
- Search that understands structure. Type a key or value and the tree filters to matching branches, keeping the parents visible so you know where the match sits.
- Type colouring. Strings, numbers, booleans and nulls each get a colour. A field that is a number in 499 items and a string in one stands out immediately.
- Shape summary. For arrays of objects, a one line summary of which keys appear and how often, so you can spot optional and inconsistent fields without reading every item.
- Graph view. A node and edge diagram of the whole document for when you want to see how the pieces connect rather than drill into values.
As with every tool on this site, the JSON never leaves your browser. You can paste production data into it safely.
Where Mermaid comes in
A tree on screen is useful while you are looking at it. Often you also need to put that structure into a document: an API spec, a pull request description, a wiki page. That is what Mermaid is for. Mermaid is a text based diagram language that GitHub, GitLab, Notion, Obsidian and most Markdown tools render natively.
The visualizer will export the structure of your JSON as a Mermaid diagram. A document like this:
{
"user": { "id": 1, "name": "Ada", "roles": ["admin", "editor"] },
"session": { "token": "...", "expires": "2026-10-01" }
}becomes a diagram definition you can paste straight into a README:
graph TD
root --> user
root --> session
user --> user_id[id: number]
user --> user_name[name: string]
user --> user_roles[roles: array 2]
session --> session_token[token: string]
session --> session_expires[expires: string]GitHub renders that as a picture with no extra tooling. It is a quick way to document what an API returns without keeping a screenshot up to date. We plan to support the flowchart and class diagram styles, with an option to include or omit values.
The VS Code extension
The web tool comes first because it needs no install and works on any machine. But most JSON we read is already open in an editor, so the second step is a VS Code extension with the same engine:
- Open any JSON file and see the tree in a side panel.
- Click a node in the tree to jump to that line in the editor, and move the cursor in the editor to highlight the node in the tree.
- Copy path, search and shape summary, exactly as on the web.
- Export the current file as a Mermaid diagram into a new Markdown file.
The extension will be free and open source, like the site.
How this fits with the tools you already have
The JSON formatter stays the right choice when you want to clean up a document or check it for syntax errors. The visualizer is for the step after that, when the JSON is valid and you need to understand it. If you already use jq on the command line, the path copy feature is designed to hand you filters you can paste directly. Our guide to working with JSON from the command line covers the jq side.
Tell us what you need
We are building the web version now. If there is a feature that would make this useful for your work, a diff view between two documents, a schema export, a specific diagram style, send it through the Contact page. Requests that arrive before the first release have a good chance of being in it.