How to Visualize Tree Data Structures

Tree Builder is for building and inspecting that shape locally: add nodes, color them, reorder, export SVG/JSON. JSON to Graph Visualizer is for when the payload is really a network (IDs pointing at each other). Pick the picture that matches the data, not the one that looks busier.

Trees versus graphs for nested data

Tree. Every child has one parent. You can talk about depth, siblings, and “path from root.” File paths and management chains are trees (until someone has two managers - then you have a graph and should admit it).

Graph. Edges are arbitrary. Package dependencies, wiki links, and “related products” are graphs. Forcing them into a tree means hiding edges.

JSON is often a tree plus extra identity: two objects may share a customerId without being nested. A tree view of the document shows nesting. A graph view of the same dump can show the ID links. Use How to Visualize JSON as a Graph when the question is relationships; use this article when the question is containment.

How to Explore Nested JSON is the text/tree-expand workflow when you do not need a diagram at all.

Org charts, file trees, and JSON objects

Org chart. Nodes are people or teams. Labels need a role, not only a name. Color can mean department or location - pick one meaning per color. Depth is usually shallow (3–5). If it is not, the organization is the problem, not the renderer.

File tree. Nodes are paths. Order often matters (README first, or locale folders together). Collapsing node_modules is not optional. Export SVG when you need a figure in a design doc; export JSON when the tree is the data.

Nested JSON. Objects become branches; arrays become numbered siblings. A 4,000-line API dump is readable as a tree if you collapse meta and expand errors[2]. It is unreadable as a force-directed graph of every key.

IA / menu. Labels are the names users see. If the tree only makes sense with internal code names, you are drawing the CMS, not the product.

Tree Builder covers the diagram cases. You can construct the tree by hand when you are designing IA, or map a small JSON document into nodes when you are explaining a payload to someone who will not read braces.

Depth, labels, and what to collapse

A useful tree on a laptop:

• Root named with the collection (“Billing settings,” not “root”).
• Labels short - one line. Details go in a side panel or a tooltip, not a paragraph in the node.
• Two or three levels expanded in the default view. Deeper levels on demand.
• Consistent children - do not mix “file” and “settings group” at the same level without a visual cue (color or icon).

Too many siblings (80 items under one folder) is a list, not a tree level. Split or search.

Cycles cannot be trees. If your “org chart” has a loop, stop drawing boxes and fix the model.

How to build or paste a tree locally

1. Open Tree Builder without an account.
2. Name the root. Add children for the first level only. Confirm the nouns are right.
3. Expand one branch to the depth you will actually discuss. Leave the rest collapsed.
4. Color with a legend (one legend). Drag to reorder if sequence is part of the meaning.
5. Export SVG for a doc, or JSON if this tree is a fixture.
6. If you generate a share URL, treat it like a query string: no tokens, no customer dumps.

When the source is already JSON and you only need to see nesting, a viewer may be faster than laying out boxes. When you need a figure for a meeting, the builder is faster than PowerPoint connectors.

Export versus a graph of relationships

Exporting a tree does not add the missing edges. If “this SKU relates to these three SKUs,” you need a graph (or a table), not a prettier hierarchy.

JSON to Graph Visualizer is the DevOkk step for that. Do not run both on the same slide unless you are teaching the difference.

Heatmaps are a different question - where clicks land on a layout, not how nodes nest. That is When to Use a Heatmap in UX, and it is a hypothesis overlay, not a data structure.

When a tree is the wrong picture

• Timelines - use a list or Gantt, not a fake root.
• Networks - graph.
• Flat enums - a <select> or a table.
• Secrets - do not visualize production payloads you would not paste into Slack, share link or not.

A tree is also the wrong picture when you are still deciding the information architecture in prose. Sketch the nouns first, then open the builder.

Build a tree only when each child has one parent

If the data has one parent per child, open Tree Builder and keep the default view shallow. If the data is IDs pointing at IDs, use JSON to Graph Visualizer. If you only need to expand errors[2], use the JSON viewer and skip the diagram.