Sorting files by size to clear space

The disk fills up on a Tuesday afternoon, usually in the middle of something else. The startup volume warning appears, an export fails halfway, and the obvious first move is to open Finder, switch to list view, and click the Size column. Then the sorting happens and the answer is not there. The largest thing on screen is a 400 MB video, the disk needs 40 GB back, and every folder in the list reports its size as two dashes.

This is the point where most people start deleting things they can see rather than things that matter. The list below covers what sorting by size in Finder actually reports, how to search the whole volume instead of one folder, which shell commands answer the question in one line, and why two tools can look at the same folder and give different numbers.

What Finder reports when you sort by size

List view is the only Finder view that sorts on size, and it sorts only the items in the folder currently open. It does not descend into subfolders. Nothing in the window is a lie, but the important number is missing: folders show two dashes instead of a size, because calculating a folder's size means walking every file inside it, and Finder does not do that work by default.

The setting that changes this lives in View Options, opened with Command and J while a Finder window is in front. Checking the option to calculate all sizes makes Finder walk the folders and fill in real numbers. Those numbers arrive slowly, and they arrive again every time the window is reopened, which is why the option ships turned off. On a home folder with a large photo library or a few checked out repositories, the column can take a minute or more to settle.

Two behaviours are worth knowing before relying on this. Sizes are calculated per window, so turning it on in one window does not turn it on everywhere unless the change is applied as the default for all windows. And the sort happens as numbers arrive, so the order shifts while the calculation runs. Waiting for the column to stop moving before drawing conclusions avoids deleting the wrong thing.

The other limitation is scope. Sorting by size answers the question "what is big in this one folder", which is rarely the question being asked. The real question is "what is big anywhere on this disk", and Finder has a separate tool for that.

Searching the whole volume instead of one folder

Press Command and F in Finder to start a search, set the scope to "This Mac", and the first criteria row appears with Kind selected. Open that menu, choose Other, and a long list of searchable attributes appears. File Size is in that list, and selecting it turns the row into a comparison: file size is greater than a number, in KB, MB, or GB.

Setting the threshold at 500 MB and then lowering it to 100 MB if too little shows up is a reasonable starting point. The results window can be sorted by size in list view, and this time the items are files, so every row has a real number. Adding a second criteria row for Last opened date narrows further, which matters because a 2 GB file opened last week is a working file and a 2 GB file last opened in 2023 is a candidate.

That search can be saved. The Save button in the search window writes a Smart Folder, which is a stored query rather than a copy of anything, so it re-runs every time it is opened. A saved search for files over 1 GB is one of the few pieces of Mac housekeeping that stays useful for years.

There is also a list Apple maintains for this purpose. In System Settings, under General and then Storage, macOS shows a breakdown by category, and the Documents entry contains a large files listing sorted by size, along with a downloads listing and an unsupported files listing. It covers the home folder rather than the whole volume, and it is the fastest route to the top twenty offenders without typing anything.

The commands that answer this in one line

Anyone comfortable in a terminal gets a better answer faster, because the shell can descend into folders without being asked twice. The core tool is du, which reports how much disk space a file hierarchy occupies.

Running du with a depth limit of one against the current directory prints one line per immediate child, and piping that through sort with the human numeric flag orders them smallest to largest, so the heaviest folders end up at the bottom of the output where they are easy to read.

du -h -d 1 ~ | sort -h | tail -20

Three variations cover almost every case. Using a wildcard instead of a depth limit gives the same result for the contents of one folder. The find command with a size test lists individual large files anywhere below a starting point, which is the shell equivalent of the Finder search above. And mdfind queries the Spotlight index directly, so it returns results instantly instead of walking the disk, at the cost of only knowing about indexed locations.

du -sh * | sort -h
find ~ -type f -size +500M
mdfind 'kMDItemFSSize > 1000000000'

The practical difference between these is time. Walking a home folder with du takes minutes on a large disk, and it needs permission to read everything it touches, so Terminal should be granted full disk access first or the output will quietly miss whole trees. Spotlight answers in under a second but skips anything excluded from indexing. Running both and comparing the two lists is often how a hidden 30 GB directory gets found.

Why two tools disagree about the same folder

A folder reported as 12 GB by Finder and 11 GB by du is not a bug, and the gap has four common causes worth recognising before spending an hour on it.

The first is what is being measured. Finder reports the logical size of the contents. The du utility reports blocks actually used on disk, which is why its manual describes an option for the other behaviour.

-A Display the apparent size instead of the disk usage. This can be helpful when operating on compressed volumes or sparse files. Source: the du(1) manual page included with macOS

The second is cloning. On APFS, copying a file inside the same volume does not duplicate the data, it creates a clone that shares blocks until one copy changes. Two folders can each honestly report 5 GB while together occupying barely more than 5 GB.

The third is files that are not fully on the machine. With iCloud Drive optimisation turned on, a file can exist as a placeholder that shows its full size while occupying almost nothing locally. Deleting it frees nothing and removes it everywhere else too, which is a bad trade.

The fourth is purgeable space. Time Machine keeps local snapshots on the startup volume, and macOS counts that space as available because it will be reclaimed under pressure. This is why deleting 20 GB sometimes moves the free space number by 2 GB, and why the free space figure can rise on its own overnight.

Question	Fastest route	Sees subfolders	Caveat
What is big in this folder	Finder list view, Size column	No	Folders show dashes unless calculated
What is big on this Mac	Finder search, File Size criterion	Yes	Files only, not folders
Which folder is eating the disk	du with a depth limit	Yes	Needs full disk access, takes minutes
Where is that one huge file	mdfind on file size	Yes	Only indexed locations
What can macOS reclaim itself	System Settings, Storage	Yes	Home folder scope

Deciding what is actually safe to remove

The output of a size scan on a working Mac is fairly predictable. Development machines surface node module trees, Xcode derived data and simulator runtimes, container disk images, and package manager caches. Creative machines surface video scratch files, render caches, and photo library previews. Everything else is usually a rounding error.

The useful distinction is not large versus small but regenerable versus not. Caches, derived data, and downloaded package archives rebuild themselves on demand, and the cost of deleting them is a slower next build. Original footage, exports nobody kept elsewhere, and virtual machine images with state inside them do not come back. Sorting the scan output into those two buckets takes five minutes and prevents the one deletion that hurts.

Two mechanical points get missed. Moving files to the Trash does not free space until the Trash is emptied, so the free space number will not move while the evidence is still recoverable. And deleting inside a bundle, such as reaching into a photo library package to remove previews, tends to break the library rather than shrink it. Bundles are managed by their application and should be shrunk from inside it.

A quick way to separate the two buckets is to ask what would happen on a fresh machine. Anything that a build, a sync, or a reinstall would recreate without human input is disposable. Anything that exists only because someone shot it, wrote it, or exported it is not. Package manager caches, browser profiles for projects that ended, and old application installers all fall on the disposable side, and together they routinely account for tens of gigabytes on a machine that has been in daily use for a couple of years.

For anything ambiguous, the safe order is measure, move to an external disk, work for a week, then delete. The pages on pricing and what the tools do are worth reading only after the immediate fire is out, because the durable fix is a process rather than a purchase.

Turning the rescue into a routine

The reason this problem recurs is that the scan is manual and nobody schedules it. Two habits remove most of the recurrence. The first is the saved Smart Folder for files over 1 GB, checked once a month, which takes about thirty seconds. The second is a shell alias for the du command above, so finding the heavy directories is one word rather than a remembered incantation.

The friction is not knowledge, it is the trip between windows. The scan happens in a terminal, the judgement happens in a file browser, and the deletion happens back in the file browser after a second look. Every one of those crossings is a chance to lose the list, and the list is the whole value of the exercise. This is the gap that a file manager with a built in terminal is built to close, and the way different tools handle it is set out in the comparison of file managers.

What to change first

Run the du command against the home folder once, today, and read the bottom twenty lines. That single output usually explains the missing space better than an hour of clicking, and it turns the next cleanup into a repeat rather than a search. If the trip between the shell that finds the files and the window that deletes them is where the time goes, that is the part worth changing, and it is what Atriens is built around.