Search for large files on a Mac and get the right answer

Searching for large files on a Mac produces three different answers depending on which tool asks the question. The Finder returns one set, mdfind returns another, and find returns a third, and none of them is broken. They disagree because they measure different things, look in different places, and count some items that are not files at all.

This is about constructing the query rather than about which folders are usually heavy. Getting the query right is the part that determines whether the list you act on is the list you wanted.

Size is not one of the criteria the search starts with

Typing into the Finder search field searches names and content. It does not search by size, and there is no size field visible until one is added.

The steps are specific. Open a Finder window, press Command-F, then click the plus button below the search field to add a rule. The first pop-up menu shows a short list of common attributes. Size is not always in it. Choosing Other at the bottom of that menu opens the full attribute list, where Size can be selected and, usefully, marked as a favourite so it appears in the short list afterwards.

Two other settings decide what the query covers. The scope buttons below the search field switch between This Mac and the current folder, and the default is not consistent across every entry point into search. A query that returns almost nothing is very often a query scoped to a folder rather than the whole machine.

The second is the unit. The size rule offers a value and a unit, and it treats a gigabyte as 1,000 megabytes rather than 1,024. A rule asking for files greater than 1 GB is asking for files over 1,000,000,000 bytes. That is a small difference on one file and a visible one when the threshold sits near a boundary and the list changes length depending on which convention was assumed.

Spotlight decides what counts as one file

Spotlight indexes items, and an item is not always what the file system would call a file.

Application bundles, many document formats, and photo libraries are directories that the system presents as single objects. Spotlight reports an aggregate size for them. A query for items over 500 MB will return application bundles alongside video files, which is either exactly right or completely wrong depending on the intent.

The command line version of the same index makes this easy to see.

mdfind -onlyin /Applications 'kMDItemFSSize > 500000000'

That returns application bundles by name. The same query pointed at a folder of video files returns individual files. Same query, same index, two different kinds of result, and nothing in the output distinguishes them.

The index also has holes. Volumes excluded from Spotlight in the Privacy list return nothing. External drives that have not finished indexing return partial results. Hidden directories and much of the system are outside the index by design, so a Spotlight based search will never see a large file inside a dot directory such as a version control object store or a package cache.

None of that makes Spotlight the wrong tool. It makes it the right tool for user documents and the wrong tool for auditing a whole disk, and the failure mode is silence rather than an error.

find counts blocks and rounds up

find does not read the index. It walks the directory tree and asks the file system about each entry, which means it sees the places Spotlight does not, including hidden directories and unindexed volumes.

The trap is the unit. Without a suffix, the number given to -size is counted in 512 byte blocks, and the count is rounded up.

The behavior is easy to confirm. Create a file of exactly 1,000 bytes. It occupies two 512 byte blocks, so find . -size 1 does not match it and find . -size -2 does not either. Only find . -size 2 does. Anyone expecting bytes has just written a query that quietly excludes most small files and behaves unpredictably near the threshold.

The fix is to always give a suffix.

find ~ -type f -size +500M
find ~ -type f -size +1G

With M or G the number means what it looks like. Note that find also descends into bundles, so a query over a folder of applications returns the individual files inside them rather than the applications, which is the opposite of what Spotlight does with the same folder.

The size on screen and the space on disk can differ enormously

A file can report a size it does not occupy. Sparse files record only the blocks that hold data, and the rest of the length is bookkeeping.

The gap is not subtle. A sparse file created with a single byte written at offset 1,000,000,000 reports 1,000,000,001 bytes in ls -l and in the Finder, while du reports 4 KB actually on disk. A size query finds it. Deleting it recovers 4 KB.

dd if=/dev/zero of=sparse.bin bs=1 count=1 seek=1000000000
ls -l sparse.bin
du -h sparse.bin

Virtual machine disks, database files, and some disk images are sparse in normal use. The same divergence appears in the other direction with APFS clones, where two files each report a full size while sharing the data between them.

The practical rule is that a search by size answers a question about reported length, and du answers the question about occupied space. When the goal is free space rather than tidiness, run the size search to find candidates and then check the candidates with du before deciding anything.

Tool	Unit given	What it measures	Where it is blind
Finder search	GB as 1,000 MB	Reported length, bundles as one item	Anything outside the Spotlight index
mdfind	Bytes	Reported length, bundles as one item	Privacy list, unindexed volumes, dot directories
find -size	512 byte blocks by default	Reported length, descends into bundles	Nothing, but it is slow on a full disk
du	Blocks occupied	Space actually used, clones counted full	Requires a starting directory
ls -l	Bytes	Reported length of one file	One file at a time

Size alone is a weak filter

A list sorted by size answers the question that was asked and not the question that was meant. The largest files on a working machine are usually the ones being worked on, so a pure size query surfaces exactly the material that must not be touched, and buries the forgotten export from two projects ago somewhere further down.

Adding a time criterion changes that. The Finder search rules can be combined, so a second rule on Last Opened Date turns the query into something closer to the real question: large, and not touched recently.

The same combination works from the command line, with one caveat about which timestamp is being read.

find ~ -type f -size +200M -atime +365
find ~ -type f -size +200M -mtime +365

The first matches files not accessed in the last year. The second matches files not modified in the last year. They are not interchangeable. Access times can be updated by backup software, indexing, and antivirus scanning, so on some machines -atime reports that everything was touched yesterday. Modification time is the more stable of the two, at the cost of missing files that are read constantly but never written.

Spotlight carries a separate attribute for this that is more reliable than either, because it records use by an application rather than a read at the file system level.

mdfind 'kMDItemFSSize > 200000000 && kMDItemLastUsedDate < $time.now(-31536000)'

That returns items over 200 MB whose last recorded use is more than a year old. It inherits every limitation of the index described above, so it is a query for documents rather than for a whole disk.

The third criterion worth adding is kind. A rule limiting results to movies, or to disk images, produces a list where every row can be judged by the same standard, which makes a review of forty items much faster than a mixed list of forty where each row needs its own reasoning.

Save the query instead of retyping it

A search built once and thrown away will be built again badly next time. The Finder can keep it.

With the search open and the rules set, clicking Save turns it into a Smart Folder that reruns itself whenever it is opened.

As you add, change, or delete files on your Mac that meet the criteria, the list of files in the Smart Folder is updated automatically. Source: support.apple.com

Two useful ones to keep are files over 1 GB anywhere on the machine, and files over 200 MB not opened in the last year. The second is the more useful of the two, since size alone says nothing about whether something is still needed.

One constraint on the save step catches people. Certain characters cannot be used in folder names, including a colon, so a Smart Folder named with a time or a ratio in it will be rejected. The error message names the problem but not the character.

The command line equivalent is a shell function or an alias, which has the advantage of being readable and the disadvantage of not living in the sidebar where it would be seen.

The gap between the list and the action

The query is the easy half. What follows is opening the results, deciding on each one, and then moving, compressing, or deleting them, and that is where a size audit usually stalls.

Results from a Finder search cannot be organised in place, because the window is a view over matches rather than a folder. Sorting works, but the files are scattered across the disk, and acting on twenty of them means twenty round trips between the result window and wherever each file actually lives.

Results from find or mdfind are a list of paths, which is the right shape for acting in bulk and the wrong shape for looking at anything. Deciding whether a 4 GB file is still needed usually means opening it, and a path in a terminal does not open.

That split is the real cost of a large file audit. The query lives in one place, the judgment needs another, and the action needs a third. A file manager that puts the folder view and the shell in the same window closes the loop, since the list and the preview and the command that acts on them stop being three separate applications. The comparison page sets out how different tools divide that work.

What to change first

Add Size as a search criterion through the Other list once, mark it as a favourite, and save the result as a Smart Folder. That converts a search you rebuild every few months into one that is always current.

Then treat the output as candidates rather than answers, and confirm each one with du before deleting, because the number in the size column is a claim about length and not about space. Keeping the list and the shell in one window is what makes that second check quick enough to do every time, and Atriens is arranged for exactly that.