Dustloft

How to find what is taking up space on your Mac using Terminal

Guide · 5 min read · By at Logicspark · Published · Updated

Short answer: use du -kxd 1 ~ | sort -rn | head -20 to see which folders are largest, and mdfind -onlyin ~ "kMDItemFSSize > 1000000000" to find individual files over 1 GB. Avoid du -sh ~/*, which silently skips every hidden folder.

Start with the volume

df -h /System/Volumes/Data

On modern macOS your files live on the Data volume, not /. Checking / shows the read-only system volume and tells you nothing useful.

Then measure folders

du -kxd 1 ~ 2>/dev/null | sort -rn | head -20

Each flag earns its place:

  • -k reports kilobytes, so sort -rn orders numerically. Sorting -h output mixes MB and GB and produces nonsense.
  • -x stays on one filesystem, so it will not wander into mounted volumes or network shares.
  • -d 1 stops one level deep. Without it, du prints every subfolder on the disk.
  • 2>/dev/null hides permission errors for folders macOS protects.

Then descend into whatever is largest by repeating with that path.

The mistake almost every guide makes

The commonly-shared command is:

du -sh ~/*     # wrong

The shell glob * does not match names beginning with a dot, so every hidden folder is silently skipped. On one machine this hid 55 GB — ~/.ollama at 16 GB, ~/.cache at 10 GB, ~/.Trash at 9.3 GB and ~/.nvm at 3.8 GB — with no error and no indication anything was missing.

Use du -kxd 1 ~, which includes hidden folders and runs in a single pass rather than forking a process per entry.

Finding individual large files

Spotlight is far faster than walking the disk:

mdfind -onlyin ~ "kMDItemFSSize > 1000000000" 2>/dev/null

If Spotlight indexing is off, fall back to find:

find ~ -xdev -type f -size +1G 2>/dev/null

Beware sparse files

Some files report a size they do not occupy. Disk images and virtual machine disks are the usual culprits — a Docker disk image can claim 494 GB while using 9 GB. du reports what is truly allocated; ls -lh does not. When the two disagree, trust du.

Checking Time Machine snapshots

tmutil listlocalsnapshots /

Local snapshots are a well-known cause of space vanishing into System Data. They are usually reclaimed automatically under pressure, but can be thinned manually if needed. They are also the largest contributor to purgeable space, which is why Finder and df -h can report different amounts of free disk.

A worked example

$ df -h /System/Volumes/Data
/dev/disk3s1  460Gi  404Gi   20Gi  96%

$ du -kxd 1 ~ 2>/dev/null | sort -rn | head -5
172000000  /Users/you/Library
116000000  /Users/you/Desktop
 16800000  /Users/you/.ollama
 10500000  /Users/you/.cache
  9700000  /Users/you/.Trash

Two of the top five are hidden folders that du -sh ~/* would never have shown.

If you would rather not do this by hand, Dustloft runs the same measurements, groups the results by how recoverable each item is, and shows every path and size before anything is deleted.

Common questions

How do I find what is taking up space on my Mac using Terminal?

Run du -kxd 1 ~ | sort -rn | head -20 to rank folders by size, then repeat on whichever is largest. Use mdfind with a kMDItemFSSize filter to list individual files over 1 GB.

Why does du -sh ~/* miss folders?

The shell glob does not match names beginning with a dot, so hidden folders such as ~/.cache, ~/.Trash and ~/.ollama are skipped silently. Use du -kxd 1 ~ instead.

Which disk should I check with df on macOS?

Check /System/Volumes/Data. On modern macOS your files live on the Data volume; checking / reports the read-only system volume.

See exactly what is on your own disk

Dustloft measures every real consumer of space on your Mac and shows each item with its full path and size before anything is removed. Free, open source, no subscription.

Install Dustloft

Once you can see the big folders, the usual suspects are messaging media and dependency trees.