This entry is part of the Chart Index, the reference library for the Chart Design Field Guide.

A tree diagram shows parent–child relationships explicitly. Nodes are entities or decisions, links show how they connect, and depth shows how far each node sits from the root. It is the clearest general-purpose form for explaining hierarchy when structure matters more than size: the organisation chart, the taxonomy, the decision tree, the dependency graph, the family tree.

Every other hierarchy chart in this index encodes a value — as area, as angle, as width. The tree encodes none. That is its limitation and its strength: it cannot tell you which branch is biggest, but it can show a hundred nodes in a shape that any reader can follow from root to leaf without instruction, because the node-link diagram is the one hierarchy form people already know.

What it is

A tree diagram maps a hierarchy to nodes joined by links. The root sits at one edge — the top, or the left — and each generation is placed one level further from it; siblings are spread along the other axis so that nothing overlaps. Two layouts are standard. The tidy tree (Reingold and Tilford's algorithm) places every node at the depth of its own generation, so a shallow branch ends early and a deep one runs on. The dendrogram (cluster layout) pushes every leaf to the same outer line, so the leaves form a straight edge and the internal nodes are spaced to reach them.

The hero chart above is a reporting chart: one chief executive, five divisions, sixteen teams, laid out left to right with the leaves aligned. The reader traces any team to its division by following a single curve, and can see the shape of the organisation at a glance — Technology has the most teams, every division has at least three. Hover a node and its ancestors and descendants light up while the rest fades: a chain of command, isolated. Each leaf also carries a headcount, and node size follows it — area in proportion to the number, with every division and the chief executive sized by the sum of the teams beneath them. Randomise perturbs those headcounts and nothing else: the nodes swell and shrink while the structure, the names and the links stay exactly where they were. Size is the one value a node-link tree can carry honestly, because it is drawn on the node rather than on the branch, and a branch's length still means nothing.

When to use it

Tree diagrams are the right choice when:

  • The reader needs to understand reporting lines, classifications, decisions, or dependency paths — the shape of the structure, not the size of its parts.
  • Parent–child relationships are the primary information, and every node has exactly one parent.
  • Nodes do not need to be sized by a quantitative value, or a value would distract from the structure.
  • The hierarchy is deep enough to be interesting and narrow enough that the leaves fit in the frame — a few dozen leaves is comfortable.
  • Interaction can support focus, expansion, or collapse: a tree is the natural form for drilling into a structure one branch at a time.

When not to use it

  • The structure is a network with multiple parents or cycles. A node with two parents has no place in a tree; use a network graph.
  • Part-to-whole magnitude is the main question. Use a treemap, an icicle or a sunburst, which give every node a size.
  • The hierarchy is so wide that the leaves cannot fit at the intended width — hundreds of leaves need a radial tree, a collapsible tree, or a different question.
  • The reader needs to compare siblings numerically. A tree makes every node the same size; the comparison has to come from somewhere else.

Design principles

Choose the orientation for the labels

A top-to-bottom tree spreads its leaves across the width of the frame, and every leaf's label has to fit in the slot beneath it. Past eight or so leaves the slots are narrower than the words, and the labels collide. A left-to-right tree stacks the leaves down the height of the frame, where every label has a whole row to itself. Turn the tree on its side whenever the leaves outnumber the fingers on both hands.

Top to bottom: sixteen leaves fight for the width
The reporting chart with the root at the top. The division labels sit fine, but sixteen team names across one row run into each other, and the reader has to guess where one ends and the next begins.
Left to right: every leaf gets its own line
The same tree turned on its side. Sixteen leaves stack down the frame with a row each, no label touches another, and the division names sit in a tidy column between the root and the teams.

When the tree must hang from the top — a genealogy, a bracket, a decision tree the reader expects to read downward — rotate the leaf labels instead of squeezing them.

Top to bottom with rotated labels: the compromise
The same sixteen leaves hanging from the top, with the labels turned to run along the layout axis. Nothing collides, and the reader still reads the tree downward — at the cost of tilting their head for the names.

Align leaves when depth is not the point

In a tidy tree, a node's distance from the root is its depth — a leaf two levels down sits two levels down, however deep its cousins go. That is the right choice when depth means something: a shallow branch of a decision tree is a shorter decision. When it does not, and the leaves are the thing to compare, the dendrogram's aligned leaves give the reader a straight edge to scan and keep the leaf labels in one clean column.

Tidy tree: each node at the depth of its generation
An incident taxonomy of uneven depth. Global outages and phishing are two levels from the root and stop there; regional outages go three deep. The ragged right edge is information: it shows which branches have been subdivided and which have not.
Dendrogram: every leaf on the same line
The same taxonomy with the leaves aligned. Global and Phishing are now pulled out to the right edge alongside the deeper leaves, their links stretched to reach. The leaf column is clean and easy to scan, but the reader can no longer see from position alone that those two were never subdivided.

Links explain structure but should never cut through labels or visually overpower nodes. Draw them thin and in a tint of the child's colour, underneath everything else. The shape of the link is a smaller decision than it looks: a smooth curve reads as flows to, an orthogonal step reads as reports to, and the organisation chart tradition prefers the step.

Step links: the organisation-chart convention
The reporting chart drawn with orthogonal links. Each division's teams hang from one horizontal rail, the way a printed org chart draws them, and the eye reads the structure as boxes and wires rather than as branches.

Colour the branches, not the nodes

Give each top-level branch one hue and let every descendant inherit it, so a subtree reads as a family wherever the eye lands. A different colour for every node is confetti; a single colour for the whole tree is fine for small trees and leaves the reader counting links for anything larger.

Reveal focus without losing context

On hover or selection, emphasise the ancestors and descendants of the chosen node while keeping the rest of the structure faintly visible. The reader sees the path they asked about without losing the shape around it. Every tree on this page does this — hover any leaf.

Do not let the tree imply a value

Node size, link thickness and branch length all look like they should mean something. In a plain tree they do not: every node is one node, and a branch is long only because its subtree is wide. Keep nodes the same size and links the same weight unless you are deliberately encoding a value — and if you are, consider whether an icicle or a treemap would carry it better.

Anatomy

The composition of a tree diagram
An anatomical guide

The root starts the hierarchy, internal nodes define branches, leaves terminate paths, links connect parent and child, and depth records distance from the root. The tree encodes structure and nothing else; every design decision is about keeping that structure legible.

  • Radial tree diagram — wraps a hierarchy around a circle when many leaves share a common depth.
  • Network graph — general relationships that are not a strict hierarchy.
  • Icicle chart — hierarchy with aggregate value encoded by span.
  • Circle packing — nested hierarchy with value encoded by area.
  • Treemap — space-filling hierarchical part-to-whole.

Reading list

  • Reingold, E. M. & Tilford, J. S. (1981). Tidier Drawings of Trees. The layout algorithm behind every tidy tree.
  • Buchheim, C., Jünger, M. & Leipert, S. (2002). Improving Walker's Algorithm to Run in Linear Time. The general-tree extension that d3 implements.
  • Munzner, T. (2014). Visualization Analysis and Design. On node–link versus containment for hierarchies, and when each wins.
  • Bertin, J. (1967). Semiology of Graphics. On the network as one of the three fundamental imposition types.