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

The treemap is Ben Shneiderman's 1991 answer to a hard problem: how do you show a hierarchical part-to-whole with hundreds of items? A pie cannot do it; nor can a bar chart. Shneiderman's solution was to recursively partition a rectangle proportional to its children's values, then recurse into each child. The result is a space-filling display where every leaf is a rectangle, every rectangle's area is its value, and the hierarchy is implicit in the nesting.

It is a chart designed for zoom-in: at a glance, the eye picks out the largest regions; on inspection, it traces the structure within each. The form trades precise comparison (area perception is poor) for density (you can show a thousand leaves in one panel without scrolling).

What it is

A treemap maps a hierarchical categorical structure to nested rectangles and a quantitative variable to rectangle area. The outer rectangle holds the total; it is partitioned into rectangles for each first-level category, with each child's area proportional to its value. Each first-level rectangle is recursively partitioned for its children, and so on. The layout algorithm (squarified, slice-and-dice, strip) determines how the partitions are arranged.

The hero chart above is a cloud bill: five service families, twenty-one services, area is annual spend. The eye lands first on the two big compute blocks — virtual machines and Kubernetes are a third of the bill between them — and only then notices that the whole Security family is smaller than one storage service. The family is read from the header band and the shared hue; the magnitude is read from area. Randomise the services and the families re-size from their leaves: the hierarchy holds still while the areas move.

When to use it

Treemaps are the right choice when:

  • You have a hierarchical structure with part-to-whole semantics — categories that sum to a total.
  • You have many leaves — too many for a bar chart, too structured for a simple list.
  • The reader's question is "where does the spending / time / volume go?" rather than precise comparison.
  • The first-level groups are the dominant story; sub-level detail is secondary.
  • You can colour-encode a second dimension — change since last period, performance rating — without overloading the form.

When not to use it

  • Precise comparison. Area is one of the least accurate perceptual channels. For comparing values, a bar chart is better.
  • Non-hierarchical data. Without a hierarchy, a treemap is just a mosaic of rectangles. Use a bar chart or waffle.
  • Very uneven values. If the largest leaf is 1,000× the smallest, the smallest leaves become unreadably thin strips. Filter or aggregate the tail.
  • Negative values. Area cannot encode negative numbers. For revenue mixed with losses, use a waterfall or grouped bar.

Design principles

Use the squarified layout

Squarified treemaps produce rectangles close to square, which the eye reads more accurately than long thin strips. Unless you need to preserve a specific order (time within a hierarchy, say), use squarified. The two figures below lay out the same three divisions both ways.

Squarified: rectangles stay close to square
Three divisions, ten programmes. Every leaf is compact enough to compare by eye and to label, and the largest and smallest programmes are both easy to find.
Slice-and-dice: the same values as strips
Identical data laid out by Shneiderman's original algorithm. Order within each division is preserved, but the leaves are long thin slivers whose areas the eye cannot compare, and half of them are too narrow to label.

Show the hierarchy clearly

Each level of the hierarchy needs visual distinction. The branch's name sits in a header band at the top of its block; the leaf names sit inside their cells. A small gutter between blocks (3–8 pixels) helps the eye separate levels. Colour is the other cue: give each top-level branch one hue and let its leaves inherit it, so a family reads as a family. Colour every leaf independently and the nesting is still there geometrically, but the eye can no longer see it.

Branch colour: leaves inherit their family's hue
The hero's five families with the default branch colouring. Blue means compute, orange means data; the reader can find every member of a family without reading a single header band.
A colour per leaf, no header bands: the families vanish
The same bill with leaves only and a palette that cycles per node. The geometry still nests, but nothing tells the eye which cells belong together, and the chart becomes a quilt of twenty-one unrelated rectangles.

Quiet the palette

Treemaps are dense. Saturated colours produce a quilt that competes with itself. Use a desaturated categorical palette for the top level, with sub-levels deriving their colour from their parent — the house palette in the figure above is already muted for this reason. Or use a single hue family throughout and let area do all the talking.

Aggregate the long tail

Real hierarchies are skewed: a handful of leaves carry most of the value and a long tail carries almost none. Drawn faithfully, the tail becomes a fringe of slivers that cannot be labelled and cannot be compared. Set a floor — perhaps one percent of the total — and roll everything beneath it into an Other cell per branch.

Thirty-two leaves drawn faithfully: a fringe of slivers
Two product lines with a long tail of minor SKUs. The four big cells read well; the rest are unlabelled slivers crushed along the right and bottom edges, each too thin to read and too small to hover.
The tail rolled into one cell per line
Everything under 2 percent of its line is summed into an Other cell. The totals are unchanged, every cell is now labelled, and the reader can see the size of the tail as one honest block instead of guessing at a fringe.

Label only the readable rectangles

Tiny rectangles cannot host labels. Set a minimum readable size — the figures here skip any leaf under 24 pixels on its short side — and label only cells above it. For smaller cells, use tooltips on hover or aggregate them as above. A label that spills outside its cell is worse than no label: it attaches itself to the neighbour.

Use colour for a second variable

The hierarchy gives you grouping; area gives you value. A third dimension — change since last period, performance rating, ownership — can be encoded as cell colour using a diverging or sequential scale. Two encodings (area, colour) is the maximum without overloading the form, and once colour carries a measure it can no longer carry the branch, so the header bands and gutters have to do all the work of showing the hierarchy.

Know the siblings

The treemap has two close relatives that draw the same tree with a different geometry. The sunburst bends the levels into rings; the icicle stacks them as bands. All three encode a leaf's value as size, but they trade off differently: the treemap gives the most pixels to the leaves, the icicle makes depth and lineage easiest to trace, and the sunburst is the most eye-catching and the least precise.

The same cloud bill as an icicle
Root at the top, families in the second band, services below. Every service sits directly under its family, so lineage is unambiguous — but the leaves get a fraction of the area a treemap would give them, and the small ones lose their labels.
The same cloud bill as a sunburst
Families on the inner ring, services on the outer. The wheel is striking and the family shares are easy to see, but comparing two services on the rim means comparing arc lengths at the same radius — a weaker judgement than comparing two rectangles.

Avoid 3D and shadows

Drop shadows, 3D perspective, and bevelled edges turn the treemap into a quilt of decorative tiles. The form's beauty is its flatness and density. Resist the temptation.

Show the total

The total — the area of the whole rectangle — is the implicit top of the hierarchy. State it in the subtitle so the reader can convert the visible rectangles back to absolute numbers.

Anatomy

The composition of a treemap
An anatomical guide

A treemap's anatomy is recursive: outer rectangle, child rectangles, child-of-child rectangles. The visual structure carries the hierarchy; the cell areas carry the values. Everything else — header bands, gutters, inherited hue — exists to make the nesting legible.

  • Sunburst — hierarchical part-to-whole as concentric rings. Different shape, same problem.
  • Icicle chart — the same partition as stacked bands; better for tracing depth.
  • Circle packing — nested circles; friendlier, less space-efficient.
  • Voronoi diagram — non-rectangular partitions for a more organic look.
  • Sankey diagram — flows between hierarchical levels rather than nested partitions.
  • Marimekko / Mosaic — width-encoded variant for cross-tabulations.
  • Bar chart — for the same data when precise comparison matters more than density.

Reading list

  • Shneiderman, B. (1992). Tree Visualization with Tree-Maps: A 2-D Space-Filling Approach. The original paper.
  • Bruls, M., Huizing, K. & van Wijk, J. (1999). Squarified Treemaps. The squarified layout algorithm.
  • Heer, J., Bostock, M. & Ogievetsky, V. (2010). A Tour Through the Visualization Zoo. Treemap variants and best practices.
  • Munzner, T. (2014). Visualization Analysis and Design. On containment as a channel for hierarchy.