Home › Blog

How to find large files on a Mac, and why the sizes lie

7 August 202610 min read

Everyone starts by sorting Downloads by size. That finds the third biggest thing on a typical Mac. The first two are somewhere you would never think to look, and one of them is not really there at all.

There is a particular kind of frustration in a Mac that says it has 8 GB free when you are certain you have not put 500 GB of anything anywhere. The storage bar in System Settings shows you a category called System Data, refuses to explain it, and that is the end of the conversation as far as macOS is concerned.

The useful way to attack this is not to hunt for individual big files. It is to work down through four scales, because the technique that finds a 60 GB virtual machine is useless for finding 40 GB spread across four hundred thousand tiny ones.

Scale one: the things over 20 GB

There are rarely more than three or four of these, and one of them is usually most of your problem. They are worth checking first because finding one ends the search.

The Photos library. Sits at ~/Pictures/Photos Library.photoslibrary and behaves as a single item, so Finder reports one enormous number and refuses to break it down. If you use iCloud Photos with "Optimise Mac Storage" turned off, you have every full resolution original locally, forever. Inside it, the Recently Deleted album keeps things for 30 days, which on a library that size can be tens of gigabytes of photos you already decided you did not want.

iPhone and iPad backups. Living at ~/Library/Application Support/MobileSync/Backup. Each one is a full device image. Nothing deletes the old ones. People routinely find backups of phones they stopped using in 2019, at 60 GB each, for a device they no longer own.

Virtual machines and disk images. Parallels, VMware, UTM and Docker all create single files that grow and, crucially, almost never shrink. Delete 30 GB inside a virtual machine and the host file stays exactly the same size, because the space is now free inside the container and still allocated outside it.

Xcode, if you have it. Derived data is build output that regenerates on demand. Simulator runtimes are full copies of iOS, one per version, kept until you remove them by hand.

rm -rf ~/Library/Developer/Xcode/DerivedData
xcrun simctl delete unavailable

Scale two: the 1 to 20 GB range

This is the bracket Finder's search is genuinely good at, and where sorting by size actually works. Press Command-F in Finder, change the first dropdown from Kind to File Size, and set it to "is greater than 1 GB". Change the search scope to "This Mac" or you will only be searching whatever folder you happened to have open.

What you will find, in rough order of how often it turns up:

• Video files you downloaded once and forgot. Screen recordings are the usual offender, because QuickTime records uncompressed by default and a ten minute recording can be 4 GB.
• Installer disk images. The .dmg you used to install an app two years ago is still in Downloads, and you have never once needed it again.
• Mail attachments, which are stored in full inside your mail database whether or not you ever opened them.
• Old project exports. Anyone who edits video or audio has a folder of renders they meant to sort out later.

This bracket is satisfying to clear because the decisions are easy. You either want a 5 GB file or you do not, and you can usually tell in two seconds by looking at the name.

Scale three: many small files, which is where searching fails

Now the interesting part. Search for files over 1 GB and you will never find the folder that is genuinely costing you the most, because it does not contain a single file over 40 KB.

The canonical example is node_modules. A single JavaScript project can contain 250,000 files. None of them is large. Together they are 1.5 GB, and if you have twelve old projects sitting in a Developer folder, that is 18 GB that no size filter will ever surface.

The same shape turns up in plenty of non developer contexts:

• Browser caches, which are thousands of small blobs.
• Photo thumbnail caches, one file per image at several sizes each.
• Email message stores, one file per message.
• Font caches, icon caches and every other cache, all of which are made of many small things by design.

To find these you need something that sizes folders by adding up everything inside them, recursively, and then ranks the folders. That is the entire purpose of a disk map, and it is why this category of app exists at all rather than everyone just using Finder.

From the command line you can get part of the way there:

du -sh ~/* | sort -rh | head -20

That prints your twenty largest home folders. It is genuinely useful and it will take a while, because it is doing the same work a disk map does, just without showing you anything until it finishes.

Why the sizes you are shown are wrong

This is the part almost nothing explains, and it is the reason two tools can look at the same folder and report different numbers without either being broken.

Every file has two sizes. The logical size is how many bytes of content it holds. The allocated size is how much disk it actually consumes. They are not the same, for three separate reasons.

Block rounding

Disks hand out space in fixed blocks, typically 4 KB. A file containing one byte still occupies a whole block. Store 200,000 one byte files and you have used 800 MB to hold 200 KB of actual content. Finder will cheerfully tell you the folder contains 200 KB. Your remaining free space will disagree by 799.8 MB, and your free space is the one telling the truth.

Sparse files

Now the opposite problem. A sparse file is one where large runs of zeroes are recorded as "this bit is empty" rather than actually written out. Virtual machine disks and disk images use this constantly. A VM disk can report 100 GB logical while occupying 12 GB of real disk. Anything adding up logical sizes will tell you that you have used more space than your disk physically contains, which is confusing the first time you see it and obviously nonsense the second.

APFS compression and clones

APFS transparently compresses many files, so they take less room than their content. It also supports clones, where copying a file creates a second name pointing at the same blocks until one of them is modified. Duplicate a 4 GB video in Finder and you have used essentially no additional space. Both copies report 4 GB. Together they occupy 4 GB, not 8.

Scale four: the stuff you should not touch

A short list, because knowing where to stop saves more time than knowing where to look.

The order that actually works

Putting all four scales together, the sequence that finds the most space for the least risk:

1. Check the four big ones from scale one. Photos, device backups, VMs, Xcode. One of them is probably your whole answer.
2. Run a Finder search for files over 1 GB and clear the obvious ones.
3. Empty Downloads. Not glamorous. Reliably worth several gigabytes.
4. Use a disk map to find the many-small-files folders you cannot search for.
5. Only then start looking at caches, which regenerate and will be back next week.

Step five is where most advice starts, which is why most advice does not help much. Caches are the most talked about and the least worthwhile, because deleting them buys space that the app immediately begins rebuilding.

Common questions