Checking how big a file or folder really is

A folder is taking up space that needs to be reclaimed. Get Info says 4.2 GB. The Finder size column says nothing at all. du -sh in a terminal says 3.9G, and the storage panel in System Settings insists the disk has less free space than any of those numbers explain. Nobody is lying. Anyone trying to get file size mac answers that agree with each other is running into the fact that macOS reports at least three different quantities, all of them legitimate, under the single word "size".

Three numbers, all of them correct

The first number is the logical size, sometimes called the apparent size. It is the count of bytes the file actually contains. ls -l prints it, and stat -f "%z" prints it exactly.

The second number is the space allocated on disk. Storage is handed out in whole blocks, and on a typical APFS volume that block is 4 KiB. A file holding one byte still occupies a full block. Running stat -f "%z %b %k" on a one byte file returns 1 8 4096: one byte of content, eight 512 byte blocks reserved, a 4,096 byte allocation unit. du -h on that same file reports 4.0K, because du reports allocation by default.

The third number is what changes in free space when the file is deleted, and it is the one people actually care about. It is not always either of the first two, for reasons covered further down.

There is also a units problem sitting on top of all this. Since Mac OS X 10.6, Finder and Get Info report sizes in decimal units, where 1 GB is 1,000,000,000 bytes. Command line tools overwhelmingly use binary units, where du -h prints gigabytes of 1,073,741,824 bytes each. The same file is 4.29 GB in Get Info and 4.0G in du -h. A gap of roughly seven percent between Finder and the terminal is expected arithmetic, not a discrepancy worth investigating.

Knowing which of the three numbers a tool reports removes most of the confusion before any troubleshooting starts.

Why the folder size column stays blank

Finder does not compute folder sizes by default, and the reason is cost. A folder total requires walking every file underneath it, and doing that for every visible row of every window would make browsing large directories slow.

The setting exists and it is per view. Open a folder in list view, press Cmd+J for view options, and switch on Calculate all sizes. The column fills in progressively as the walk completes, and deep folders take visible seconds. The same panel has a "Use as Defaults" button that applies the choice to future windows, which is the part most people miss after turning it on for one folder and finding it gone the next day.

Get Info, in the File menu, computes the total for a single folder on demand and shows it counting up. Selecting several items and choosing it opens one window per item, which is rarely useful. The better route is the Inspector: hold the Option key and the File menu entry changes from Get Info to Show Inspector. That opens a single floating window that shows the combined size of whatever is currently selected and updates live as the selection changes. Selecting fifteen folders and reading one combined total is the fastest way to compare deletion candidates without leaving Finder.

One caution about Get Info on folders. The number it reports includes everything it can read. If the folder contains items the current account has no permission to read, the total is quietly short, and no warning is shown. The same applies to folders that are really application packages, such as a Photos library. Finder treats them as one item, and the size it reports is the whole bundle, which is why a single row can account for half a disk.

Sorting also deserves a note. A list view sorted by the size column only orders the rows whose sizes have been calculated. With Calculate all sizes switched off, folders sort as if they had no size at all and end up grouped together at one end, which makes the heaviest directory look like the lightest. Turning the setting on is what makes the sort meaningful.

What the command line actually measures

Four commands cover almost everything, and the differences between them are exactly the three numbers above.

ls -lh prints the logical size of each file, human readable, with no traversal into subdirectories. It is the right tool for "how big is this one file".

du -sh folder prints the summed allocated size of a folder. du -sh * in a directory gives a size for every entry, and piping that through sort -h orders the results by magnitude, which is the single most useful line for finding where space went. du -h -d 1 does the same thing one level deep with the totals labelled.

du -A switches to apparent size instead of allocation, which matters on compressed volumes and for sparse files. On a one byte file it reports 512B rather than 4.0K, because du still rounds to 512 byte units even in this mode.

stat -f "%z %b %k" file gives the exact bytes, the allocated blocks, and the allocation unit in one line, with no rounding at all. When two other tools disagree, this is the tiebreaker.

find . -size +100M locates the large files rather than summarising the totals, and it is usually the second command run after du has narrowed the search to a directory. The size argument takes a suffix, so +1G works the same way, and adding -type f keeps directories out of the result.

One habit is worth adopting with all of these: run them against an explicit path rather than the current directory when the shell has been sitting in a project for a while. A du -sh . in the wrong place is the most common reason a cleanup session starts with a number that means nothing.

Question	Command	Reports
Exact bytes in one file	stat -f "%z" file	Logical size
Readable size of some files	ls -lh	Logical size
Total for a folder tree	du -sh folder	Allocated size
Which subfolder is heavy	du -sh * | sort -h	Allocated size
Ignoring block rounding	du -Ah folder	Apparent size
Where the big files are	find . -size +100M	Matching paths

When the totals refuse to add up

Three macOS behaviours break the assumption that deleting X gigabytes frees X gigabytes.

APFS clones

On APFS, duplicating a file on the same volume does not copy its data. Both names point at the same blocks until one of them is modified, and only the changed parts are written. Finder duplication and cp -c both work this way. The consequence is that du counts the same physical blocks once for every clone that references them, so a folder of duplicates can report far more space than it is actually using. Deleting one clone frees almost nothing.

Local snapshots

Time Machine keeps local snapshots on the startup disk between backups. Files inside a snapshot still occupy blocks even after the visible copies are deleted, which is why space sometimes fails to appear until hours later. tmutil listlocalsnapshots / lists what exists. This is normal behaviour and the snapshots are removed automatically as space is needed.

Files that are not fully on the disk

With iCloud Drive and the storage optimisation options switched on, a file can exist as a placeholder: the name, the dates and the logical size are present, and the contents have been evicted to make room. Finder marks these with a cloud and download icon, and Get Info still reports the size the file will have once it comes back. The blocks, meanwhile, are not on the local disk, so du reports almost nothing for the same item.

This is the one case where Get Info reads high and the terminal reads low, which is the opposite of the units gap described earlier. In a Documents folder that has been optimised for months, the difference can be most of the folder. Deleting placeholders frees no local space at all, and it removes the file from every device signed into the same account, so it is worth identifying them before a cleanup rather than during one.

Purgeable space

The storage panel in System Settings, under General, reports a category of purgeable space, which covers caches, downloaded content that can be fetched again, and snapshots. It counts as used space in some views and as available in others. A disk that reports very little free space while du accounts for far less is almost always holding snapshots or purgeable data rather than hidden files.

None of these are faults. They are the reason a size check should end with a decision about what to delete, not with a prediction of exactly how many gigabytes will come back.

A practical order for reclaiming space

The order matters more than the tools, because each step narrows the next one.

Start at the top level of the home directory with du -sh * | sort -h and read the last three lines. Repeat inside the largest one. Three or four iterations reach the actual culprit in almost every case, and the whole process takes under a minute on a modern disk.

Then switch to Finder for the judgement call. Sort the folder by size in list view with Calculate all sizes on, open the Inspector from the File menu with the Option key held to watch the running total as items are selected, and preview anything ambiguous with the space bar before deleting it. The terminal is faster at finding weight. Finder is better at deciding what a file is, because a name and a preview together answer a question that a path on its own cannot.

Check for cloud placeholders and application packages before anything leaves. A row that reports twelve gigabytes may be a Photos library that is still in daily use, or a set of files whose contents are already offloaded, and neither is a candidate for deletion.

Empty the Trash, then check free space again rather than assuming. If the number did not move, the earlier section explains why. A second look an hour later is often enough, because snapshot cleanup is not immediate.

This two tool loop is also where the friction shows up. Every switch between the size listing and the folder view means retyping or copying a path, and the count adds up over a cleanup session. A file manager that keeps the folder view and a terminal in the same window removes that switch, because the command output and the directory being inspected are already pointed at the same place. The Features page covers how that layout works, and Compared with other file managers sets it against the disk visualisers and dual pane tools that approach the same job differently.

What to change first

Turn on Calculate all sizes in list view and press Use as Defaults, then learn du -sh * | sort -h as a single habit. Those two cover most size questions without any further tooling. If the remaining cost is switching between the terminal that finds the weight and the window that inspects it, that is a layout problem, and Atriens is built for exactly that gap.