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

An icicle chart lays a hierarchy out as stacked bands. The root is one full-width band; each generation below it splits its parent's span in proportion to value, so a node's width is the sum of its descendants and its position tells you exactly which parent it belongs to. The form is the sunburst unrolled into a rectangle, or the treemap with depth made explicit — and of the three, it is the one on which the reader can trace a path from root to leaf without losing their place.

Its name comes from the way the bands hang: in the original orientation the root sits at the top and the levels descend beneath it like icicles from an eave. Turned on its side and read left to right it becomes the flame graph that software profilers use, which is where most readers today have met it.

What it is

An icicle chart maps a hierarchy to a partition of a rectangle. The root occupies the full extent of one axis; each child occupies a contiguous slice of its parent's extent, proportional to the child's value; each level of depth is one band along the other axis. Leaves carry the values; a branch's width is the sum of its leaves. Because every child sits directly beneath (or beside) its parent, the reader can follow any path through the hierarchy by moving straight down (or across) — no nesting to decode, no angles to compare.

The hero chart above is a profile of a single web request. The root band is the whole 105 milliseconds; the second band splits it into the four phases of the request; the third and fourth bands break each phase down further. The reader sees at once that the database is more than half the request, that within the database it is the query execution that dominates, and within that the index scan. Randomise the timings and every band re-sizes from its leaves upward, while the vertical alignment of parent over child never changes.

When to use it

Icicle charts are the right choice when:

  • Readers need to trace paths through a hierarchy — which branch does this leaf belong to, and its parent, and its parent's parent.
  • Depth is analytically meaningful: a level is a stage, a call, a generation, a rank.
  • Values add from children to parents, so a band's width is a real total.
  • The hierarchy is deep but not wide — six levels of a handful of children each suits the form far better than two levels of fifty.
  • Interactive zoom or drill-down will let readers inspect dense branches: click a band and it becomes the new root.

When not to use it

  • Only leaf size matters. A treemap gives the leaves the whole frame; an icicle spends most of its area on the branch bands above them.
  • The hierarchy is shallow and simple. Two levels of a few nodes is a bar chart with a header; a tree diagram will be clearer still.
  • Values do not aggregate. If a parent's number is not the sum of its children, the band widths will lie about it.
  • The hierarchy is very wide. Fifty siblings in one band are fifty slivers, none wide enough to label.

Design principles

Choose the direction for the labels

The icicle grows from its root in any of four directions. Root at the top and bands descending is the classic form and suits short labels; root on the left and bands growing rightward gives every node the full height of its band to print a label along — the flame-graph orientation, and the better choice when the names are long or the hierarchy is deep.

Root at the top: the classic icicle
The request profile with the root band at the top. Depth reads downward, breadth reads across, and the wide leaves carry their names. The narrow ones — session loading, TLS — are too thin to label and rely on the tooltip.
Root on the left: the flame-graph orientation
The same profile grown rightward. Depth now reads left to right and every band is as tall as its share of the total, so even the thin leaves have room for a label. This is the orientation to choose when the names matter more than the outline.

Keep the direction consistent

Whichever direction you choose, preserve it across related views. Direction tells the reader how to traverse the hierarchy; a dashboard with one icicle hanging from the top and another growing from the left asks them to relearn the form on every panel.

Sort siblings by value when their order is not meaningful

A request's phases happen in sequence, so the hero keeps them in input order and the reader can follow time left to right. When the order of siblings carries no meaning — cost centres, product lines — sort them by value instead: the biggest band first, the tail trailing off, and the eye finds the dominant branch immediately.

Cost centres in the order the finance system lists them
A support budget in alphabetical order. The reader has to scan the whole second band to find that Facilities is the largest centre, and the third band's leaves alternate between fat and thin with no pattern to read.
The same budget sorted by value, largest first
Identical data sorted descending at every level. Facilities leads, Leases leads within it, and the widths step down monotonically from left to right, so the chart doubles as a ranked list. Sort only when the input order has no meaning of its own.

Use gaps to reveal parent boundaries

A hairline of canvas between siblings separates them without costing width; a small gap between levels shows where one band ends and the next begins. Make the gaps large and they eat the span that is supposed to encode value — a two-pixel gap on a two-pixel leaf is a leaf that has vanished.

No gaps: the bands fuse
The request profile with zero gutters. Siblings of the same hue run together — the three execute leaves read as one wide band — and the reader has to find the boundaries from the tiny lightness step between them.
Ten-pixel gaps: the small leaves disappear
The same profile with generous gutters. Every boundary is now obvious, but the gaps come out of the bands — the five-millisecond leaves are down to slivers, and the widths no longer add up to the root.

Label the upper levels first

Parents orient the reader. The root and the first level should always be labelled; below that, print a label only where the band can hold it — the figures here skip any band under about sixty pixels wide — and let the tooltip carry the rest. A label wider than its band spills onto the neighbours and mislabels them.

Know when the treemap is better

If the reader's question is which leaf is biggest? rather than what is the path to this leaf?, the icicle is spending most of its frame on the wrong thing. The same request profile as a treemap gives the twelve leaves the entire area — and loses the ability to read the call path at a glance.

The request profile as a treemap
The same twelve leaves with the whole frame to themselves. Index scan is obviously the largest cost and every leaf is labelled — but which phase Sort belongs to now has to be read from a nested header band, and Execute, the branch that mattered most in the icicle, survives only as an eyebrow inside Database.

Support zoom without losing context

When a band can be clicked to become the new root, show the path that led there — a breadcrumb above the chart, or the ancestors drawn as thin bands at the top — so the reader always knows where in the hierarchy they are standing and how to get back.

Anatomy

The composition of an icicle chart
An anatomical guide

Bands represent depth, each node's span represents aggregate value, adjacency shows siblings, and containment is expressed by aligned partitions across levels. The reader traces a path by moving straight through the bands; the design's only job is to keep that path unbroken.

  • Treemap — space-filling hierarchy optimised for leaf area rather than depth.
  • Sunburst — the same partition bent into rings.
  • Circle packing — hierarchy by enclosure; friendlier, less precise.
  • Tree — explicit links between parent and child nodes, no values.
  • Bar chart — what a single band of the icicle becomes when the hierarchy is flattened.

Reading list

  • Kruskal, J. B. & Landwehr, J. M. (1983). Icicle Plots: Better Displays for Hierarchical Clustering. The paper that named the form.
  • Gregg, B. (2016). The Flame Graph. Communications of the ACM. The icicle's second life as a profiler's tool.
  • Heer, J., Bostock, M. & Ogievetsky, V. (2010). A Tour Through the Visualization Zoo. Icicle, sunburst and treemap side by side.
  • Munzner, T. (2014). Visualization Analysis and Design. On containment, alignment and the hierarchy layout trade-offs.