A treemap is a set of nested rectangles, each sized proportionally to the value it represents — in the case of a Mac's storage, the size of a folder or file. The largest folder in a directory gets the largest rectangle; a folder half its size gets roughly half the area. It's a deceptively simple idea that turns out to be a genuinely better way to answer one specific question than any list view: "what is the single biggest thing taking up space here?" This article covers what a treemap actually is, why area beats a sorted column of numbers for that particular question, the squarified algorithm that makes treemaps readable rather than a mess of slivers, and why drill-down treemaps solve a problem that one flat treemap of an entire disk cannot.

What a treemap actually is

Take a folder and list everything inside it by size. A treemap draws that same information as a rectangle divided into smaller rectangles, where each child's area is proportional to its share of the parent's total size. A folder using 40% of the parent's space gets a rectangle covering roughly 40% of the total area; a file using 2% gets a small rectangle covering roughly 2%. Every rectangle is typically labelled with a name and a size, and often coloured by file type or by folder to make groupings easier to spot at a glance.

Nothing about this requires special algorithms to compute the sizes themselves — those numbers come from walking the filesystem the same way du -sh does. The algorithm's job is purely about how to lay those numbers out as rectangles in a way that stays legible.

Why area beats a sorted list for one specific question

A sorted list — biggest file or folder at the top, ranked downward — is a fine way to answer "give me the top 20 items by size." But it's a surprisingly poor way to answer the question people actually have when their disk is full: "what's the one thing I should deal with first, and how does it compare to everything else here?"

A list of numbers requires you to read and compare digits: is 42.3 GB meaningfully bigger than 38.1 GB? Is either of them a big fraction of the whole, or a rounding error? A treemap answers that instantly, because your visual system is very good at comparing areas without doing arithmetic. The biggest rectangle is obviously the biggest rectangle. A folder that's genuinely dominant — say, half your entire disk — visually dominates half the map, which a list of numbers simply cannot convey with the same immediacy. This is the core reason a treemap tends to get you to "that's the answer" faster than scanning a sorted column, even though both are showing exactly the same underlying data.

The squarified treemap algorithm, briefly

Early treemap layouts had a real usability problem: a naive algorithm that simply divides space by proportion, one slice after another, tends to produce long, thin sliver rectangles for anything that isn't close to the "average" size in that view. A sliver ten pixels wide and eight hundred pixels tall is technically proportional to its value, but it's nearly impossible to visually compare its area against a squarer rectangle next to it — long and thin reads as "small" even when the numbers say otherwise.

The squarified treemap algorithm addresses this by choosing how to subdivide space so that resulting rectangles stay as close to square as the layout allows, rather than optimising purely for exact proportional slicing in one direction. It works through the items being placed in a row or column, testing whether adding the next item would make the current group of rectangles more square or less square on average, and starting a new row once adding another item would make things worse. The result trades a small amount of strict layout precision for a large gain in how easy the map is to actually read: near-square rectangles let your eye compare area accurately, which is the entire point of drawing a treemap in the first place rather than just listing numbers.

Why nested, drill-down treemaps beat one flat map of a whole disk

A single treemap covering an entire disk at once runs into an unavoidable tradeoff. To include everything, you either have to omit small items below some size threshold — because a file that's 0.001% of a terabyte disk would be a rectangle a fraction of a pixel wide — or you include everything and end up with a map so dense it stops being readable at all, dominated by a handful of huge rectangles with thousands of illegible slivers crammed into the remaining space.

A drill-down treemap avoids this by only rendering one level of depth at a time. You start at the top — your whole disk, or your home folder — see the handful of major rectangles at that level clearly, and then click into the one you care about. That folder's contents then fill the same space, redrawn as their own proportional treemap, at a scale where its own internal structure is finally visible. You can keep going deeper — home folder, into Library, into Developer, into Xcode — with each level getting the full available space to lay out clearly, rather than being squeezed into an ever-shrinking corner of one giant flat map.

This matches how people actually investigate a storage problem: start broad, spot the dominant chunk, zoom into exactly that chunk, and repeat until you land on something specific enough to act on. A flat treemap of an entire disk tries to show you every level of that investigation simultaneously, which is precisely why it becomes either incomplete or unreadable — usually both.

Conclusion

A treemap isn't a gimmick layered on top of a file list — it's a genuinely better fit for the specific question "what's the biggest thing here, and how does it compare to everything else," because human vision compares areas faster and more reliably than it compares numbers. The squarified algorithm is what keeps that comparison honest by avoiding sliver rectangles that would otherwise distort the picture, and drill-down navigation is what keeps a treemap useful at any scale, from a small project folder to an entire disk.

This is the visualisation VolumeLens is built around: a squarified, drill-down treemap of your actual disk, so that finding the folder that's quietly eating your storage takes seconds of looking rather than minutes of scrolling through a sorted list.