ReMyndwhat spotlight search can't find on your mac
spotlight search finds files, apps and settings on a mac. it does not find the thing you were looking at.
that is the whole of mac search in one line, and it explains almost every failed ⌘space.
that distinction sounds pedantic until the moment you need it. you remember a number from a dashboard, a line from a shared doc in a call, an error string in a log someone screen shared. ⌘space, type the words, nothing. the search worked correctly. the content was simply never in the index.
as of september 2026 the share of work that happens inside rendered interfaces rather than saved documents keeps growing, and mac search has not followed it there. here is exactly where the boundary sits.
what spotlight search does index
apple describes spotlight search on a mac as showing suggestions "from apps, files, actions, the internet, and the clipboard".
in practice the index is built from four things:
- file contents. text inside supported document types, extracted when the file is written or changed.
- file metadata. names, dates, kinds, tags, and the extended attributes apps attach.
- app supplied records. anything an app deliberately publishes through core spotlight, which means a developer wrote code to hand it over.
- system surfaces. apps, settings, actions, conversions, and web suggestions.
that is a lot. it is also, in every case, something that was written down. a file on disk, or a record an app chose to register. nothing in that list comes from the screen.
the spotlight index has worked this way since apple shipped it in 2005, and the shape has not changed since. what changed is where work happens.
what it never sees
five categories of content are permanently invisible to spotlight, and they are the five people search for most.
| what you are looking for | why spotlight misses it |
|---|---|
| a figure on a dashboard | rendered in a browser, never saved as a file |
| a slide in a call someone else shared | the pixels arrived over the network and were drawn, not stored |
| a message in a web app | lives in the app's cloud, and any local cache is not a document |
| a ticket, a comment, a pull request review | same, plus most of it is behind a login |
| text inside a video you watched | frames are not documents, and nobody indexed them |
there is a sixth, quieter one. anything an app stores in its own private database, in a format spotlight has no importer for, is invisible even though the bytes are on your disk.
apple did add live text in 2021, so macos can read characters out of an image. that helps with a screenshot you saved. it does nothing for a window you closed. the same asymmetry shows up with chatgpt and claude: both read an image you attach, and neither keeps an index of the 8 hours of screen you did not attach.
why the file system stopped being the record
the file used to be the unit of work. for most jobs in 2026, it is not.
open your own week and count. how much of it produced a saved document, and how much of it happened in a browser tab, a chat thread, a ticket, a terminal, a call? the second pile is larger, and it is the pile spotlight cannot reach.
your browser is not a fallback here either. chrome's history "lists the pages you've visited on Chrome in the last 90 days", which tells you the url you were on and nothing about what the page said while you were there. safari, edge and firefox all store the same shape of record: an address, a title, a timestamp.
so the two indexes most people rely on, files and history, each miss the same thing from opposite directions. one has the content but not the screen. the other has the address but not the content.
how much of the day this actually costs
looking things up is the single most common thing people bring to an ai assistant, which is a decent proxy for how much of work is search.
per the anthropic economic index for may 2026, the top work task in sampled claude conversations is searching electronic sources for information, at 4.95%. reference searching sits second at 3.74%. a third entry, locating unusual or unique information in response to specific requests, adds 0.45%.
| task matched in conversations | share |
|---|---|
| search electronic sources for information | 4.95% |
| search standard reference materials | 3.74% |
| conduct reference searches | 1.38% |
| review files and records to respond to requests | 0.70% |
| locate unusual or unique information | 0.45% |
that is 11.22% of sampled work conversations spent finding something, against 43.36% of classified conversations that look like work at all. almost none of it can be answered from your own screen history, because for most people no such history exists. these are observed usage shares rather than a measure of anyone's job.
what closing the gap actually requires
you need a second index, and it has to be built from a different raw material.
- capture the screen, not the file system, because the screen is where the content was.
- run optical character recognition on what was captured, so pixels become searchable strings.
- store the text locally, so the index is fast and the archive stays with you.
- keep the video short and the text long, because the recordings are what cost you disk, not the words.
step four is the one people get wrong. in a measured install across 17 days, video accounted for about 24.6gb of 26gb, roughly 95%, while the searchable index was 1.4gb. the working is in screen recording storage on a mac.
spotlight and screen memory answer different questions
these two indexes are not competitors, because they are built from different raw material and fail in opposite directions.
| spotlight | screen memory | |
|---|---|---|
| built from | files and app records | frames captured from the display |
| finds | documents, apps, settings | anything that was on screen |
| misses | rendered interfaces, calls, web apps | anything you never looked at |
| cost | free, built in | disk, and a capture permission |
| privacy shape | local index of local files | local index of a recording of your work |
the last row is the one to think about hardest. a file index is boring because a file was already sitting there. an index of your screen is a new artefact that did not exist before, which is why where it lives matters more.
this is also why the microsoft and apple answers diverge. microsoft built recall into windows 11, gated behind a 40 tops neural processing unit, 16gb of memory and windows hello. apple has shipped no equivalent on macos as of september 2026, which leaves the gap to third party apps. we compare the two directly in remynd vs microsoft recall.
where remynd sits
remynd builds that second index on a mac. it records the focused window, runs ocr on device through apple's vision framework, and keeps the resulting text in a database on your machine, so ⌘k searches things spotlight was never going to see.
the scope, stated plainly: capture is the focused window rather than every pixel of every display, ocr and storage stay on your mac, recordings default to 30 days of retention, and you can exclude specific apps or sites from capture entirely. your history is read only everywhere in the app.
what it does not do: asking a question about your history sends the retrieved slices to a cloud model, and there is no local model option today. optional backup is encrypted and exports to your own s3 bucket. so the honest line is that the archive lives with you, not that nothing ever leaves your machine.
if you want the practical version of this, read how to find something you saw on your screen. for the category it belongs to, start with what is screen memory.
download remynd free for mac → free to download, runs locally, no card.