Finder & Files

How to Find Large Files on Mac (Terminal and Finder)

Published Nov 2, 2026
Tested on a real Mac. Ran find, mdfind, du, df, mkfile and dd on macOS Tahoe 26.6.2 (MacBook Air M3); test files were created and deleted only in a scratch folder. ncdu was not installed, the Finder and Storage steps were not scripted, and nothing in the home folder was deleted (the rm example was not run). Test machine: MacBook Air (M3, 16 GB), macOS Tahoe 26.6.2, zsh 5.9.
On this page
  1. Method 1: find (thorough, slower)
  2. Method 2: mdfind (instant, uses Spotlight)
  3. Method 3: du (which folders are big)
  4. The Finder route: System Settings > General > Storage
  5. What is safe to delete
  6. Common questions

To find large files on a Mac from Terminal, search your home folder for anything over 1 GB:

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

That scan took 44.8 seconds on my MacBook Air (77 GB home folder). If you want an answer in under a second, ask Spotlight instead:

mdfind -onlyin ~ "kMDItemFSSize > 1000000000"

Below: how the two compare, how to see which folders are big, and what you can safely delete.

Method 1: find (thorough, slower)

find walks every folder and checks each file. It is slow but it does not depend on any index.

find ~ -xdev -type f -size +1G -exec ls -lh {} + 2>/dev/null | sort -k5 -hr

What each part does:

  • ~ starts in your home folder. Use / to search the whole disk (expect many more “Operation not permitted” lines).
  • -xdev stays on one volume, so it skips external drives and network shares.
  • -type f matches files only, not folders.
  • -size +1G means larger than 1 GB. Try +500M for a wider net.
  • -exec ls -lh {} + prints readable sizes, and sort -k5 -hr puts the biggest first.
  • 2>/dev/null hides permission errors.

On my Mac it found five files. Here is what they were (paths shortened for privacy):

SizeWhat it was
10GVirtual machine disk image from a desktop app
10GA second VM image from the same app
4.0GChrome’s on-device AI model (weights.bin)
1.7GA database file in one of my projects
1.2GA compressed copy of the VM image

Timings from three runs:

CommandTime
find ~ -xdev -type f -size +1G (first run of the day)1 min 03 s
Same command, run again44.8 s and 43.1 s
mdfind -onlyin ~ "kMDItemFSSize > 1000000000"0.15 s

The second find run is faster because macOS has cached the folder metadata. It is still slow.

Gotcha: -size +1G skips a file that is exactly 1 GB

I made a 1 GB test file with dd and a 2 GB file with mkfile, then searched:

mkfile -n 2g sparse-2g.bin
dd if=/dev/zero of=real-1g.bin bs=1m count=1024
find . -type f -size +1G
./sparse-2g.bin

The 1 GB file is missing. find rounds sizes up to whole units of the suffix, so a file of exactly 1 GB counts as “1”, and +1 means “more than 1”. Use megabytes when the line matters:

find . -type f -size +1000M
./real-1g.bin
./sparse-2g.bin

Method 2: mdfind (instant, uses Spotlight)

mdfind asks the Spotlight index instead of reading the disk. That is why it returns in a fraction of a second. To see the sizes too:

mdfind -onlyin ~ "kMDItemFSSize > 1000000000" -0 | xargs -0 du -sh | sort -hr

The trade-offs I hit in testing:

  • It only knows what Spotlight indexed. My test files in a temporary folder returned 0 results. Folders excluded in System Settings > Spotlight are invisible too.
  • It treats app bundles as one item. mdfind listed a 10 GB .bundle package where find listed the two image files inside it.
  • It counted 4 items where find found 5. Use mdfind to look fast, and find when you need the full list.

Method 3: du (which folders are big)

Big files are only part of the story. Thousands of small cache files add up too. du totals each folder:

du -h -d 1 ~ 2>/dev/null | sort -hr | head
 77G	~
 65G	~/Library
4.4G	~/Downloads
2.4G	~/my-project
1.8G	~/.npm
1.6G	~/Documents
985M	~/.cache
770M	~/.bun
391M	~/Movies
 66M	~/Desktop

That took 41 seconds. ~/Library was 65 of my 77 GB, so drill into it the same way:

du -h -d 1 ~/Library 2>/dev/null | sort -hr | head -6
 65G	~/Library
 37G	~/Library/Application Support
 11G	~/Library/Mobile Documents
9.5G	~/Library/Caches
3.7G	~/Library/Group Containers
2.8G	~/Library/Containers

If you prefer an interactive view, ncdu is a popular terminal tool for this (brew install ncdu). It was not installed on my test Mac and I did not install it. If brew itself is missing, see zsh: command not found: brew.

Gotcha: the size ls shows is not always disk space used

mkfile -n makes a sparse file. It reports a size but stores almost nothing:

ls -lh sparse-2g.bin real-1g.bin
du -h sparse-2g.bin real-1g.bin
-rw-r--r--@ 1 you  wheel   1.0G Nov  2 17:29 real-1g.bin
-rw-------@ 1 you  wheel   2.0G Nov  2 17:29 sparse-2g.bin
1.0G	real-1g.bin
 16K	sparse-2g.bin

This is not just a lab trick. One of the “10G” VM images find reported on my Mac used only 4.5 MB on disk. Deleting it would have freed almost nothing. Check with du -h before you delete anything for space.

The Finder route: System Settings > General > Storage

No Terminal needed:

  1. Open System Settings > General > Storage.
  2. Click the (i) next to a category, such as Documents.
  3. The Large Files tab lists big files, sorted by size, with a Delete button.

In Finder you can also press Cmd+F, set the first menu to File Size, and choose “is greater than” 1 GB. Neither route is good at showing what sits inside the hidden ~/Library folder, which is where most of my space was. See how to show hidden files on Mac to browse them.

Gotcha: df -h / shows the wrong number

df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   460Gi    12Gi   291Gi     4%    459k  3.1G    0%   /
/dev/disk3s5     460Gi   139Gi   291Gi    33%    2.1M  3.1G    0%   /System/Volumes/Data

/ is the sealed system snapshot (12 GB). Your files live on the Data volume (139 GB). “Avail” is the same on both, so read that one.

What is safe to delete

Never delete ~/Library itself or whole folders inside it. Apps keep settings, mail, messages and passwords there. Go item by item:

LocationSafe?Notes
~/DownloadsUsuallyYour own files. Check before you delete.
~/Library/Caches/<app>MostlyApps rebuild caches. Quit the app first. Mine was 9.5 GB.
~/Library/Caches/*.ShipItUsuallyLeftover auto-update downloads. I had three, 477–618 MB each.
~/.npm, ~/.cacheYesDownload caches. They refill when needed.
~/Library/Mobile DocumentsNoThis is iCloud Drive. Deleting here deletes on every device.
~/Library/Application SupportRarelyReal app data. Uninstall the app instead.
Large VM or model filesDependsRemove them from inside the app that made them.

To delete a cache folder you have checked:

rm -rf ~/Library/Caches/com.example.app.ShipIt

Prefer dragging to the Trash in Finder if you are unsure, because rm cannot be undone. I did not delete anything in my home folder for this post.

Common questions

Why do I see “Operation not permitted” errors?

macOS privacy rules block Terminal from folders like ~/.Trash, Photos Library and Mail unless you grant it Full Disk Access in System Settings > Privacy & Security. 2>/dev/null hides those lines. The files in those folders are still skipped.

How do I find large files across the whole disk?

Replace ~ with /. Keep -xdev so it does not crawl external drives. Without Full Disk Access, protected folders are skipped.

How do I find files changed recently that are big?

Add a time filter. This lists files over 500 MB changed in the last 7 days:

find ~ -xdev -type f -size +500M -mtime -7 2>/dev/null

Why is mdfind missing a file I know exists?

The folder is probably not indexed, or the item is inside an app bundle. Use find for that folder.

Will a long find scan slow down my Mac?

It uses the disk heavily for about a minute. If your Mac sleeps mid-scan, use caffeinate to keep it awake.