Spotlight Finds It, Finder Doesn't: Which of the Three Searches Is Broken

Spotlight’s menu finds the file instantly, and Finder’s Recents has never heard of it. Or you type the same words into Finder’s search field, in the folder the file is actually in, and get nothing — while mdfind in Terminal prints the path.

Nothing here is inconsistent, and the rest of this page is the machinery behind that. Your Mac runs at least three different searches against one Spotlight index, each with its own filters and its own scope, and they fail in different ways for different reasons. Before you rebuild anything, it is worth knowing which of them is the one that let you down.

One of those filters is worth naming now: Recents only counts files you have opened. FileBo asks the same index the wider question — what arrived recently — so a never-opened download is in its panel while Recents stays blank. The tests below are for the deeper failures.

This is a diagnostic page. It will not repair a dead index — Apple’s instructions for that are at Rebuild the Spotlight index on your Mac, and if the tests below say your index is genuinely missing the file, that is the page you want. Everything measured here was run on macOS 26.6, build 25G72.

Three searches, one index

They are not three versions of the same thing. They are three different questions, and each one throws away a different part of the answer before it reaches you: one hides the categories you switched off, one hides the system’s own files unless you ask for them, and one hides everything you have not personally opened.

Here is what each of them actually asks, and what each of them drops on the floor.

What you use	What it queries	What it filters out
Spotlight menu (⌘Space)	every indexed attribute plus document text, ranked	categories switched off in System Settings ▸ Spotlight, and anything under a Privacy exclusion
Finder search field (⌘F)	attributes you pick, inside a scope you pick	System files and Spotlight items, until you add those criteria yourself
Recents in the Finder sidebar	one fixed saved query, unchangeable	everything without a “last opened” date, plus folders and apps
mdfind in Terminal	the index, raw	nothing

mdfind is the useful one for diagnosis precisely because it is the least helpful for daily use. It applies no scope, hides nothing, ranks nothing. If mdfind can see a file and a Finder window cannot, the index is fine and you have a filtering problem.

The Recents query, in full

Recents is the one that catches most people out, because it sits in the sidebar looking like a folder and is nothing of the kind. It is a single fixed search, written once by Apple, shipped inside Finder, and not adjustable by you. It asks two things about every file: have you ever opened it, and is it the sort of item Apple decided belongs in that list. Fail either one and the file is invisible there permanently, however new it is and however easily every other search finds it.

Here is that search in full. It is a saved search bundle inside Finder, at /System/Library/CoreServices/Finder.app/Contents/Resources/MyLibraries/myDocuments.cannedSearch/. Its identifier is com.apple.canned-search.15, its English display name is Recents, and this is its entire query:

(kMDItemLastUsedDate = "*") &&
  ((kMDItemContentTypeTree = public.content) ||
   (kMDItemContentTypeTree = "com.microsoft.*"cdw) ||
   (kMDItemContentTypeTree = public.archive))

Scope is kMDQueryScopeMyFiles, with FinderFilesOnly and UserFilesOnly both set to true.

Two conditions, and both of them exclude things people expect to see.

The file must have been opened. Downloading it does not count. Writing it into a folder does not count. Something has to have actually opened it. macOS keeps a date on every file recording when that last happened, and a file nothing has ever opened does not have one at all.

kMDItemLastUsedDate = "*" means the attribute has to exist.

Want to watch that happen? I wrote a plain text file into ~/Downloads and left it alone. mdls reported kMDItemDateAdded = 2026-08-08 09:46:26 +0000 and kMDItemLastUsedDate = (null). mdfind returned it by name straight away. The Recents query, run over my home folder, did not return it. I then opened it once in TextEdit: kMDItemLastUsedDate became 2026-08-08 09:51:43 +0000, and the same query returned it. That is the whole of the mechanism, and it is why downloads you never opened are absent from Recents.

The type must qualify. The second half of the query asks what kind of item it is, and two everyday things never pass it: folders and applications. It does not matter how often you open them. macOS files every item under a family of types, and the families Recents accepts are documents, archives and Microsoft’s formats — a folder and an app belong to none of them.

Want to check that claim? I dumped a full run of that query and went through it. Not one application bundle; and of the first several hundred entries checked item by item with mdls, not one plain folder. Neither absence is a bug. mdls on Calculator.app gives a kMDItemContentTypeTree of com.apple.localizable-name-bundle, com.apple.application-bundle, public.directory, public.executable, public.item, com.apple.application, com.apple.package, com.apple.bundle — nothing under public.content or public.archive, so it can never match. A folder’s tree is public.folder, public.directory, public.item: same result. A .zip does match, through public.archive, and so does a .dmg, whose tree includes public.archive alongside public.disk-image.

If Recents is empty rather than incomplete, the causes are different again and are covered in Finder Recents is empty.

Four commands that isolate the layer

Four questions, in this order, and the first one that answers you is the layer that failed. Does your Mac know the file exists at all? Is the file even eligible for Recents? Is Finder searching where you assume it is searching? And is the disk the file lives on being indexed in the first place?

Only the first of those four can be fixed by rebuilding the index, which is why it comes first.

Check your own Mac. Run these in order and stop at the first one that answers you.

1. Is it in the index at all?

mdfind -name "partofthename"

A path means the index has the file, and no rebuild is going to change anything. Silence means the index does not have it, and only then is Apple’s rebuild procedure the right move.

2. Is it eligible for Recents?

mdls -name kMDItemLastUsedDate -name kMDItemContentTypeTree /path/to/file

kMDItemLastUsedDate = (null) means Recents will never show it, no matter how recent it is. If the tree contains neither public.content nor public.archive, likewise.

3. Is Finder searching where you think?

defaults read com.apple.finder FXDefaultSearchScope

SCcf is the current folder, SCev is This Mac, SCsp is whatever you searched last. The Mac I tested on returned SCcf. If yours does too, a ⌘F from inside Downloads searches Downloads and nothing else, which looks exactly like a broken index and is not one. The same control sits in the search window itself, in the row under the toolbar where Finder offers Search This Mac, the folder you started in, and Shared.

4. Is the volume indexed?

mdutil -as

On my Mac that prints / as Indexing disabled — expected, because the system volume is sealed and read-only — with /System/Volumes/Data and /System/Volumes/Preboot enabled. Read the state beside each volume, not just the list of names: a mounted drive normally does appear here, and the line that matters is whether it says Indexing enabled. Anything reported as disabled, or missing from the list altogether, is invisible to every search on the machine.

Symptom	Layer	What to do
mdfind finds it, ⌘F does not	scope or criterion	widen the scope, or add the System files criterion
mdfind finds it, Recents does not	kMDItemLastUsedDate absent, or wrong type	nothing to fix; Recents is working as written
Neither finds it, file is on an external drive	volume indexing	mdutil -s /Volumes/Name
Neither finds it, file is in your home folder	the index	rebuild, using Apple’s page

What Finder’s search field is really asking

When you add a criterion in a Finder search window you pick from a short menu of friendly names — Name, Contents, Created date, Last opened date. Each of those is a label stuck on one specific piece of bookkeeping macOS keeps about your files, and picking the wrong label is one of the commonest ways to fail to find something that is sitting right there. Two of these dates sound almost identical and mean completely different things.

The friendly criterion names in a ⌘F window are metadata attributes wearing labels. Finder keeps the mapping in its own string table, at Contents/Resources/en.lproj/SlicesAttributeNameOverrides.strings:

Finder criterion	Attribute
Name	kMDItemDisplayName
Contents	kMDItemTextContent
Created date	kMDItemContentCreationDate
Last modified date	kMDItemFSContentChangeDate
Last opened date	kMDItemLastUsedDate
File Size	kMDItemPhysicalSize

Note the fifth row. Last opened date in a Finder search is the same attribute Recents is built on, which means you can reproduce Recents by hand, with a scope of your choosing, and see for yourself which files carry the date.

That is also the free fix, and it is worth doing before you install anything. File ▸ New Smart Folder, then +, gives you a search window with the same criteria; swap Last opened date for Last modified date or Created date and you get the view Recents refuses to show — files that arrived but were never opened. Press Save and it becomes a permanent item in the Finder sidebar. It costs nothing, it ships with macOS, and for a lot of people it is the end of the problem.

One limit worth knowing before you rely on it: the criteria in that short list — Last modified date, Created date — travel with the file. Something that came out of a zip or an export keeps its original dates and sorts as old as it claims to be, which is exactly the trap the recent-downloads page is about. The date that records arrival, kMDItemDateAdded, is not in the short list at all — it is reachable through Other… or a Raw Query, and it is the one FileBo asks about alongside the other three.

Two more criteria are reachable from the + row, through the attribute menu’s Other… list, and Finder’s strings spell out both of their states: System files are included / aren’t included, and Spotlight items are included / aren’t included. Neither is included until you add the criterion yourself, which accounts for a large share of “Spotlight found it, Finder didn’t” reports.

The Spotlight menu is broader than either of them, and most of the difference is text: it reads the words inside your documents as well as their names, so it finds files whose names contain nothing you typed. man mdfind documents what it builds: typing search produces (* = search* cdw || kMDItemTextContent = search* cdw) — every attribute, plus the text inside your files.

Want to measure that gap on your own Mac? It takes three commands. On my Mac, mdfind -interpret -count "invoice" — the Spotlight-menu form of the query — returned 86. A filename search, mdfind -count 'kMDItemFSName == "*invoice*"cd', returned 10. A contents-only search, kMDItemTextContent == "invoice*"cd, returned 84. More than eight times as many hits, and the contents-only count accounts for nearly all of that gap: those are words inside documents, which a filename search never sees. Your own counts will differ — run the three commands and compare them to each other, not to mine. (One cosmetic note: current macOS prints a couple of UserQueryParser lines to stderr before the number; append 2>/dev/null if they get in the way.)

The four places Apple’s page does not go

Four situations survive the tests above and still leave a file unfindable, and not one of them is an index that wants rebuilding: a drive you plugged in, a folder on a server, a cloud folder like Dropbox or iCloud Drive, and your own Library folder. Each is invisible for its own reason, and none of those reasons is the one Apple’s rebuild page addresses.

External volumes. Mounted and readable does not mean indexed, and the volume being listed is not the same as the volume being searched. I created a 20 MB disk image and attached it with hdiutil attach -nobrowse: it appeared in mdutil -as straight away, but as Indexing disabled, and a file written to it stayed unfindable — mdutil -i on flipped the reported status to Indexing enabled without ever producing a result, and even a full erase-and-rebuild with mdutil -E did not help. Attached normally, the same image reported Indexing enabled and a newly written file came back from mdfind within about fifteen seconds. So read the state next to the volume, not just its presence in the list. Two further details worth knowing: mdutil -s /Volumes/Name reports the firmlinked path, /System/Volumes/Data/Volumes/Name, which is normal; and a file called .metadata_never_index at the root of a volume switches indexing off for that volume regardless of anything else — I dropped one onto the test image, remounted, and the status changed to Indexing and searching disabled with the new file unfindable.

Network shares. The index that answers your query is not necessarily on your Mac. man mdutil says so under -p: “Spotlight caches indexes of some network devices locally. This option requests that a local caches be flushed to the appropriate network device.” Whether a share is searchable at all therefore depends on the server, not on the state of your Mac’s index — rebuilding locally cannot make a non-indexing server searchable. I had no share to test against on my Mac, so take that paragraph as documentation rather than measurement.

Cloud folders. File Provider mounts Dropbox, Google Drive, OneDrive and the rest into ~/Library/CloudStorage/, which is inside a hidden folder — so those files inherit the ~/Library problem below. iCloud Drive content is indexed: a PDF in ~/Library/Mobile Documents/com~apple~CloudDocs came back from mdfind carrying a kMDItemLastUsedDate nearly a year older than its kMDItemDateAdded — it was last opened long before it ever synced to this machine. So a synced file can sit in Recents at a position that has nothing to do with when it appeared on your Mac. Files that have been evicted to the cloud are a separate matter, and the error they raise has its own page.

~/Library. This one surprises people. The contents are indexed. I wrote a file into ~/Library and mdfind returned it within five seconds, with kMDItemDateAdded populated. What you are hitting is not the index but two layers of hiding: ls -ldO ~/Library shows the hidden flag on the folder, and Finder’s search leaves System files out. mdfind sees all of it; Finder shows none of it until you add that criterion.

When rebuilding will not help

Rebuilding the index is a genuine fix for a genuine failure, and it is also the most-recommended and least-often-correct answer in this whole area. It will not help if:

• mdfind already finds the file — the index is not the problem
• the volume has indexing off, or carries .metadata_never_index — fix the volume, not the index
• you searched the current folder while the file was elsewhere
• the item lives in ~/Library, ~/Library/CloudStorage, or another hidden path
• the file has no kMDItemLastUsedDate and you were looking at Recents
• the path sits under a Privacy exclusion in System Settings ▸ Spotlight — check that list before you spend the afternoon reindexing

Apple’s page also covers the everyday causes worth ruling out first, in If searching your Mac returns unexpected results: spelling, quoted phrases, disabled result categories, and files sealed inside archives or Time Machine backups.

What FileBo can and cannot do when Finder will not show a file

There is a fourth question, and none of the three searches answers it well: what changed recently, as opposed to what did I open recently. A saved Smart Folder on Last modified date, as above, already answers it for free, and if that is all you needed, stop here.

FileBo answers it in a panel rather than a window. One keystroke and it is there over whatever you are working in, listing what has arrived on your Mac lately — including the file you downloaded and never opened, which is precisely the file Recents will not show you. Open it from the panel, or drag it straight out into an email or a chat.

If you do want the mechanical version: it runs the same kind of query, over four date attributes at once — kMDItemContentCreationDate, kMDItemFSContentChangeDate, kMDItemFSCreationDate and kMDItemDateAdded — scoped to a watch list rather than to kMDQueryScopeMyFiles. None of those four is kMDItemLastUsedDate, which is why a file you downloaded and never opened turns up there and not in Recents. Its search field is a separate query, (kMDItemFSName = "*text*"c) within your home folder, live from two characters and capped at 800 results.

It is built on the same index as everything else on this page, and it inherits every gap that index has. It has no database of its own, so it cannot show you a file Spotlight does not know about, and it cannot repair a broken system index — nothing outside Apple’s own tooling can. If step 1 above came back silent, no third-party recents panel is going to change that answer.

The one-line version

Ask mdfind first. If it answers, your index is healthy and you are looking at a scope, a filter, or a missing kMDItemLastUsedDate — none of which a rebuild touches. If it stays silent, you have earned the rebuild.