Why Downloaded Files Don't Show Up in Finder's Recents

You downloaded something an hour ago. It is sitting in ~/Downloads — you can see it in the folder. Open Finder’s Recents and it is not there, while a spreadsheet you last touched on Tuesday is at the top of the list.

The short way out is FileBo — a panel that counts a download from the moment it lands, so the file is on the list before you ever open it.

If you want to know why, the rest of this page is the machinery: where that search lives, the two conditions a file has to pass, a thirty-second experiment that settles it on your own Mac, and the free way to build the list Recents should have been.

Recents is a saved search, and it asks one question

Recents sits in the sidebar looking like a folder, but there is no folder behind it. It is a stored search that Finder re-runs every time you click it, and that search asks one thing about every file: has anything ever opened this? A file that has only arrived and never been opened has no answer to give, so it does not come back in the results. There is nothing in there to repair — there is a question, and your files either answer it or they do not.

Mechanically, it is a search bundle Finder ships inside itself:

/System/Library/CoreServices/Finder.app/Contents/Resources/MyLibraries/myDocuments.cannedSearch

Internally it is still called myDocuments — a leftover from All My Files — with bundle identifier com.apple.canned-search.15. Its English display name, from Resources/InfoPlist.loctable, is Recents.

Want to read the query yourself? Print it:

plutil -p "/System/Library/CoreServices/Finder.app/Contents/Resources/MyLibraries/myDocuments.cannedSearch/Resources/search.savedSearch"

On macOS 26.6 (build 25G72) the RawQuery key comes back as:

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

with SearchScopes set to kMDQueryScopeMyFiles, and FinderFilesOnly and UserFilesOnly both true.

Read the first clause literally. kMDItemLastUsedDate = "*" means this attribute exists on the file. Not “is recent” — exists at all. Apple’s own Spotlight schema, in Metadata.framework/Resources/en.lproj/schema.strings, labels that attribute Last opened and describes it as “Date when this item was last used”. Finder’s Smart Folder UI renames it again, to Last opened date.

macOS writes that attribute when something opens the file. A download you have never opened has not been used, so the attribute is not stale or wrong on it — it does not exist. Recents cannot show a file that fails the first of the query’s two mandatory clauses. (The second clause is a type test, and it is the subject of a later section.)

Thirty seconds to prove it on your own Mac

None of that has to be taken on trust. You can watch one file go from invisible to visible in Recents in about half a minute, using a throwaway file, without touching anything you care about. The only thing that changes about the file is that something opens it.

Try it on your own Mac. Make a file, wait a few seconds for Spotlight to notice it, and ask:

$ printf 'test\n' > ~/Downloads/fb-demo.txt
$ mdls -name kMDItemDateAdded -name kMDItemLastUsedDate -name kMDItemUseCount ~/Downloads/fb-demo.txt
kMDItemDateAdded    = 2026-08-08 09:46:45 +0000
kMDItemLastUsedDate = (null)
kMDItemUseCount     = (null)

One date, one absence. Now run the Recents query itself against the same folder — this is the string from the plist above, nothing added:

$ mdfind -onlyin ~/Downloads '(kMDItemLastUsedDate = "*") && ((kMDItemContentTypeTree = public.content) || (kMDItemContentTypeTree = "com.microsoft.*"cdw) || (kMDItemContentTypeTree = public.archive))' | grep fb-demo
$

Nothing. Open the file once, wait, and ask again:

$ open ~/Downloads/fb-demo.txt
$ mdls -name kMDItemDateAdded -name kMDItemLastUsedDate ~/Downloads/fb-demo.txt
kMDItemDateAdded    = 2026-08-08 09:46:45 +0000
kMDItemLastUsedDate = 2026-08-08 09:47:23 +0000

The same mdfind now returns the file. kMDItemUseCount appears alongside the date. Nothing about the file changed except that something opened it, and that is the entire difference between visible and invisible in Recents.

The scale of it on a working Mac: of 1,356 items at the top level of my Downloads folder, 1,130 have no kMDItemLastUsedDate. Counting recursively, 460 files there carry a kMDItemWhereFroms URL — the marker a browser leaves, and one that AirDrop and messenger transfers here did not set — and 392 of those have never been opened. That is 85% of the browser downloads still sitting in that folder, missing from Recents until something opens them.

The second filter, which catches folders and applications

The date is only half the test. The other half asks what kind of thing the item is, and Recents accepts only what macOS treats as a document or an archive — text, images, PDFs, and the zips, disk images and installers a download tends to arrive as.

A folder is neither. Nor is an app. That is why a folder you downloaded and unzipped never appears in Recents however many times you open it, and why the applications you use all day are not in there either. Opening them more often cannot help, because they are failing a test that has nothing to do with opening.

The rest of the query is a type test on kMDItemContentTypeTree, and it removes those two whole categories that people expect to see.

Check one on your own Mac with mdls -name kMDItemContentTypeTree. A folder’s type tree is short:

$ mdls -name kMDItemContentTypeTree ~/Downloads/some-folder
kMDItemContentTypeTree = (
    "public.folder",
    "public.directory",
    "public.item"
)

Neither public.content nor public.archive is in it. So a downloaded-and-unzipped folder can never appear in Recents, no matter how often you open it. On my Mac, 116 folders under ~/Downloads carry a last-used date; add the Recents type filter to the same mdfind and the count is 0.

Applications behave identically — 82 apps in /Applications had a last-used date, and none survived the filter. An app bundle’s tree is longer than a folder’s, but it lands in the same place:

$ mdls -name kMDItemContentTypeTree /Applications/Safari.app
kMDItemContentTypeTree = (
    "com.apple.application-bundle",
    "com.apple.application",
    "public.executable",
    "com.apple.localizable-name-bundle",
    "com.apple.bundle",
    "public.directory",
    "public.item",
    "com.apple.package"
)

Eight entries, and neither public.content nor public.archive among them.

Disk images, installers and archives are fine on this count: .dmg resolves to com.apple.disk-image-udif → com.apple.disk-image → public.archive, .pkg to com.apple.installer-package-archive → public.archive, .zip to public.zip-archive → public.archive. They still need a last-used date to show up, so a DMG you downloaded and never mounted is absent for the first reason instead of the second.

The attribute your downloads do have

Your download is not invisible to macOS. It simply carries a different kind of date. Not “when you last used this”, which it has never had, but “when this arrived here” — plus, if a browser put it there, the address it came from and the moment it was fetched.

None of that is what Recents asks for. All of it is enough to find the file, sort by it, and build a list of your own — which is what the next section does.

Every file that lands in a folder gets kMDItemDateAdded, opened or not. Apple’s schema calls it Date added and describes it as “Date when this item was last moved”. Downloads generally also carry kMDItemWhereFroms — Where from — holding the URL.

Want the download time to the second? The quarantine attribute is a third record of the same event, and it is more precise than most people realise:

$ xattr -l yourfile.pdf
com.apple.quarantine: 0083;692bfaea;Brave;<uuid>

Four semicolon-separated fields: flags, a Unix timestamp in hexadecimal, the app that did the downloading, and an event UUID — the last one is often empty, so a value ending in a bare semicolon is normal. Decode the second field and you have the download time to the second:

$ python3 -c "print(int('692bfaea',16))"
1764489962

On the file I took that from, the decoded time matched its kMDItemDateAdded exactly. That gives you a way to date a download whose Finder dates have been muddled by copying.

The free fix: a Smart Folder keyed on Date added

There is no setting that makes Recents include unopened files — the query is inside a system bundle. What you can do, at no cost, is build the search Recents should have been. This is a real answer, not a warm-up; if it does the job, you are done reading.

If you only ever want this morning’s download, the cheapest fix is not a Smart Folder at all: open ~/Downloads in list view and sort by Date Added (View ▸ Show View Options, or right-click the column headers to add the column). Same attribute, no setup. The Smart Folder below is worth building when you want the answer across several folders, or pinned in the sidebar.

Build it on your own Mac. Wording below is Finder’s on macOS 26.6.

1. Open your Downloads folder in Finder.
2. Press ⌘F (File ▸ Find…). The search row appears; click Downloads rather than This Mac.
3. Click the + at the right of that row. A criteria row appears, starting on Kind is any.
4. Open the first popup. If Date added is in the list, pick it. If it is not, choose Other…, type date added in the chooser’s search field, tick Date added and click OK — Finder keeps it in that popup afterwards.
5. Set the row to is ▸ within last ▸ 7 ▸ days.
6. Click Save at the right of the search row. Finder asks you to “Specify a name and location for your Smart Folder”, defaults to ~/Library/Saved Searches, and offers a checkbox to add it to the sidebar. Tick it.

Step 4 is the one that trips people, and the reason is that the popup is not a fixed menu — it is a stored preference. The list lives under the SlicesRootAttributes key in com.apple.finder.plist, and Other… is what writes into it, so what you see there depends on what you have searched for on that Mac before. You can print your own:

$ defaults read com.apple.finder SlicesRootAttributes

A fresh criteria row always starts on Kind is any — that template ships in Finder.app/Contents/Resources/default_smart.plist. Of the attributes Finder bothers to give a friendly name to, in en.lproj/SlicesAttributeNameOverrides.strings, there are exactly six — Contents, Name, File Size, Created date, Last modified date, Last opened date — and Date added is not one of them. Whatever state your popup is in, Other… always gets you there.

Prefer the terminal? If you would rather not click, the same question is one line:

$ mdfind -onlyin ~/Downloads 'kMDItemDateAdded >= $time.today(-7)'

$time.today(-7) is seven days back; $time.today is since midnight; $time.now(-86400) is the last 24 hours. All three work with mdfind as written.

Where Date added will mislead you

One caveat before you lean on it. Date added means added to this folder — not downloaded from the internet. It is set when the file arrives where it now sits, and it resets when the file arrives somewhere else. So filing a download into a project folder makes it look freshly downloaded, and a file restored from a backup or synced down from a cloud will surface with today’s date. The creation date does not move, which is what makes the pair useful together.

Tested here:

Action	kMDItemDateAdded	kMDItemFSCreationDate
File created 09:57:00	09:57:00	09:57:00
Renamed in place	09:57:00	09:57:00
Moved to another folder at 09:57:19	09:57:19	09:57:00

Renaming inside one folder changes nothing — which is also why a browser’s temporary .crdownload or .part file keeps the date added it was given when the download started, not when it finished.

What this page does not fix

If Recents is empty of everything, including documents you opened this morning, that is a different fault — most likely the index rather than the query, and Finder Recents empty on a Mac is where that is separated out. If Spotlight’s menu finds a file that a Finder window will not, that is three different searches over one index and worth diagnosing before you rebuild anything. And if the file you are hunting is a cloud placeholder rather than real bytes on disk, see the operation can’t be completed because it needs to be downloaded.

Downloads on an external drive are outside the scope of the Recents query entirely — it searches kMDQueryScopeMyFiles — and outside Spotlight’s index unless that volume is indexed.

What FileBo shows instead: the download you never opened

Everything above is Finder’s own machinery, and the Smart Folder is a real answer. FileBo is the version of it you do not have to build.

It is a small panel that asks Spotlight a wider question than Recents does. Recents wants to know when you last opened something; FileBo counts a file from the moment it arrives. So the download sitting untouched in your Downloads folder is simply in the list, with no criteria to pick and no saved search to name — that folder is one of ten it watches from the start. You can look at everything, or narrow the view to the last 24 hours, 7 days or 30 days.

Unzipping something does not flood the list either. Files landing straight in Downloads each keep their own tile — a watched folder is never collapsed — while a subfolder that fills up in one burst shows as a single tile carrying an “N new” badge, which clears when you open it.

It needs macOS 15.0. After a 14-day trial, browsing the grid, searching it, the time scopes and the tabs, and Show in Finder stay free indefinitely; opening files, dragging them out and the rest of the actions are a one-time $9.99 unlock.

If you do want the mechanical version: its MDQuery matches on any of four dates rather than one — kMDItemContentCreationDate, kMDItemFSContentChangeDate, kMDItemFSCreationDate and kMDItemDateAdded — so a file that has only ever been downloaded still qualifies. The attribute Recents insists on, kMDItemLastUsedDate, is not among them. The burst that collapses a subfolder into one tile is six or more files with gaps of ten minutes or less, which is what unzipping an archive there looks like. Scopes are All, Last 24 Hours, Last 7 Days and Last 30 Days.

The boundary is the same one this whole page rests on: FileBo reads Spotlight’s index and does not repair it. If your index is broken, it will be as empty as Recents is, and Apple’s own rebuild instructions are the fix. What it changes is the question, not the data — which is precisely why an unopened download shows up in it and cannot show up in Recents.

For the fastest ways to find a download you know you just made, including your browser’s own history panel, see finding recently downloaded files on a Mac.