Check a folder size on a Mac: reading the number Finder hides

Open a Finder window in list view, switch on the Size column, and every folder shows two dashes. Files get a number. Folders get nothing. The usual reason for looking is that a volume is filling up and something needs to be found, which makes the blank column feel like an obstruction rather than a design decision.

It is a design decision, and it is recorded plainly in Finder's own settings. The list view setting is named calculateAllSizes, and on a fresh account it is set to 0. Finder is not failing to show folder sizes. It has been told not to compute them.

That single fact shapes everything else on this page. Finder can give a folder size, but only on request, and the number it gives is not always the number the terminal gives, and neither is always the number the volume actually lost. The three answers differ for reasons worth knowing before a decision gets made on the strength of one of them.

Why the Size column is blank for folders

A file's size is stored with the file. A folder's size is not stored anywhere. To produce it, something has to walk every descendant of that folder and add up what it finds. On a directory with a few dozen items that is instant. On a home folder with several hundred thousand items, spread across a mail store, a photo library, and a few years of build artifacts, it is a sustained burst of disk activity.

Finder is a window that has to stay responsive while scrolling. Committing it to a full recursive walk of every visible folder, every time a window opens, would make the common case slow in order to serve the uncommon one. So the default is off, and the walk happens only when asked for.

Turning it on is per view setting, not global in any obvious sense. In a list view window, open the View menu and choose Show View Options, then tick Calculate all sizes. That applies to the current window. The same panel has a button to use the settings as the default for new windows, which is how the behaviour spreads.

Two things are worth knowing before turning it on everywhere. The setting belongs to list view, so a window in icon, column, or gallery view will not honour it. And the totals fill in progressively: a folder shows dashes, then a rough number, then a settled one, as the walk completes in the background. Sorting by the Size column while that is still happening produces an order that reshuffles under the pointer. Let the numbers settle before sorting.

The three Finder routes, and when each one is right

Calculate all sizes is the right tool for comparing siblings, because it fills the whole column at once. For a single folder, Get Info is faster to reach and does the same walk for one target. It shows a live counter while it works, so a folder that takes a long time announces itself.

The Inspector is the version of Get Info that follows the selection. Open it once and click through folders, and it recomputes for each one without opening a new window per folder. For working down a suspect directory level by level, it is the least tedious of the three.

The preview pane, toggled from the View menu, shows size in the side of the window rather than in a separate panel. For folders it behaves like the others: it computes on demand rather than reading a stored value.

The terminal answer, and how to make it useful

The command is du, for disk usage. Run on its own it prints a line for every directory below the current one, which is rarely what anyone wants. Three flags turn it into a usable tool.

du -sh ~/Documents
du -h -d 1 ~/Documents | sort -h
du -h -d 1 -t 500m ~

The first line gives one total for one folder. The second lists every immediate child with the largest last. The third lists only the children above 500 MB.

The -s flag collapses everything into one total. The -h flag prints units instead of block counts. The -d 1 flag stops the listing at one level down while still counting everything below, which is the form that answers "which of these is the problem". Piping through sort -h orders the human-readable sizes correctly, which plain sort does not.

Two more flags earn their place on a full disk. The -t flag sets a threshold and hides everything under it, so a directory with four hundred children prints the six that matter. The -x flag refuses to cross onto another filesystem, which stops a walk of the home folder from wandering into a mounted network share or an external drive and reporting its contents as local usage.

The -I flag takes a mask and skips matching names, which is how to answer a question like "how big would this project be without node_modules". And -c adds a grand total to the end of a list, useful when the shell glob is doing the selecting rather than a single directory argument.

One habit worth forming: du writes its errors to standard error, not standard output. On a walk that crosses into a protected directory it prints permission denials while still adding up what it could read, and the total that comes out the other end is silently short. Redirecting with 2>/dev/null hides the warning but not the undercount. Reading the warnings is the point of them.

The number du reports is not the space the volume lost

This is the part most guides skip, and on a modern Mac it can be the difference between a right answer and a wrong one.

APFS supports file clones. A clone is a second name for the same blocks on disk, created without copying the data, and the two names diverge only as one of them is written to. Finder's Duplicate command makes clones. So does cp -c. Plenty of developer tooling makes them too.

The measurement is easy to take. A 200 MB file was written to a scratch directory, then cloned three times. du -sh on that directory reported 800M. The volume's used space, read from df before and after each clone, grew by about 2 MB per clone. The same file copied with a plain cp instead grew used space by about 202 MB, as a real copy should.

So du reported four times the space that was actually consumed. It is not wrong in the way a bug is wrong. It is adding up the blocks each file claims, and each clone genuinely claims all of them. There is simply no per-file answer to "how much would be freed by deleting this", because the answer depends on which of the other names still exist.

The -A flag is worth knowing here even though it does not solve that problem. It reports apparent size, the logical length of the file, rather than the blocks the filesystem allotted. For sparse files, or files on a compressed volume, apparent size and disk usage differ substantially, and which one is relevant depends on whether the question is about transferring the data or about freeing the disk.

Hard links have the same shape of problem in reverse. By default du counts a file with several hard links once, so a directory tree full of hard links reports less than the sum of its visible contents. The -l flag turns that off and counts every occurrence, which is the right choice when the question is about copying rather than storing.

Why the three numbers disagree

Put Finder's number, du's number, and the Storage pane's number side by side for the same folder and they rarely match. The gaps have specific, boring causes.

Method	What it measures	Units	What it skips
Calculate all sizes	Recursive walk, on demand, list view only	Decimal, 1 GB is 1,000,000,000 bytes	Nothing visible, but silently skips unreadable subtrees
Get Info and Inspector	Same walk, one target at a time	Decimal	Same
du -sh	Blocks allotted to each file	Binary by default with -h, 1G is 1,073,741,824 bytes	Nothing, but prints permission errors and undercounts
du -Ash	Logical file lengths	Binary	Compression and sparseness, by design
Storage in System Settings	Whole-volume categories	Decimal	Not a folder tool at all

The units gap alone is about 7 percent at gigabyte scale, which is enough to make two correct numbers look like a contradiction. Finder reports 1 GB as 1,000,000,000 bytes. du -h reports 1G as 1,073,741,824 bytes. Neither is lying.

Hidden files are a smaller factor than people expect, because both routes count them. What Finder does hide is failure: where du prints a permission error and carries on, Finder's total simply comes out short with no indication that anything was skipped. A folder that contains another user's data, or a directory protected by the system, will read low in Finder and read low with a warning in the terminal.

The Storage pane belongs in a different category entirely. It reports on a volume, splits usage into buckets that do not map onto directories, and counts local snapshots and purgeable space in ways no directory walk can reproduce. It answers "what kind of thing is filling this disk". It does not answer "how big is this folder", and trying to reconcile it with a folder total is wasted effort.

Doing this without switching windows

The practical friction in all of this is not any single command. It is that the folder is open in one window and the command runs in another. Finding the large directory means reading a du listing, remembering a path, switching to Finder, navigating to it, looking at what is inside, and going back to run the next du one level down. Repeat four or five times and most of the effort has gone into moving between two views of the same directory.

A file manager with a built-in terminal removes that loop, because the shell's working directory and the pane's directory are the same thing. Run du -h -d 1 | sort -h, read the list, open the offender in the pane above, and the next command already starts from the right place. The Features page covers what that arrangement includes, and the Compared with other file managers page sets out where it differs from the alternatives.

The same reasoning applies to what the panes show. Finder surfaces a chosen set of attributes. A folder size that is wrong because a subtree was unreadable, or a file that is smaller on disk than its length suggests, are both visible in a view that shows the filesystem's own answers rather than a curated subset.

What to change first

Turn on Calculate all sizes in one list view window and set it as the default, so folder comparisons stop requiring a separate step. Then learn one command, du -h -d 1 | sort -h, and use it as the tool for finding what to look at rather than for measuring what to delete. Before deleting anything on the strength of a du total, check whether the files are clones, because the space that comes back may be a fraction of the number on screen. If moving between the listing and the folder is the slow part, Atriens puts both in one window.