Search what you remember about it, not what it's called

The frustrating version of this problem is always the same shape: there's an image you know exists, you can picture it clearly, and the only things you actually remember are facts that have nothing to do with its filename. A rough date. That you rated it well. That it was unusually large, or a portrait crop, or came from a folder about a project two jobs ago. Scrolling a folder tree by eye, hoping to recognise the thumbnail, is the default approach and it's also the slowest one — it treats the problem as "where did I put this" when the actual problem is "what do I remember about it," and those two questions call for completely different tools.

The fix is turning each fragment of memory into a query clause and stacking them until the result set is small enough to scroll. None of it depends on having tagged the file when you first saved it — the useful clues are almost always things the index already captured on its own.

Filenames were never going to solve this anyway. A file saved two years ago carries whatever name the camera, the export tool or the download gave it — IMG_4821.heic, Untitled_final_v2.png — and almost nobody renames a reference image the moment it's added, because renaming takes time that feels wasted on a file you might never look at again. That's precisely the gap this approach is built to close: it treats the filename as irrelevant and searches everything else the file actually carries instead, which is usually far more than it feels like from memory alone.

Step 0: Write down every fragment before searching

Before typing anything, it's worth spending thirty seconds listing every half-memory rather than jumping straight to the first one that comes to mind. A rough date, an impression of size or shape, whether it felt like something worth rating, which project or trip it might be connected to — each fragment becomes one clause, and having the full list up front means building the query in the order that narrows fastest rather than the order the memories happened to surface in.

It's also worth noticing what this approach doesn't require: it doesn't require having been a diligent tagger two years ago, it doesn't require remembering a project name accurately, and it doesn't require the file to have been opened even once since it was originally saved. Every clue used below is something the first pass already captured automatically, which means the search works just as well on a file you saved once in a hurry as on one you carefully filed and labelled at the time.

Step 1: Start from the one fact you're most sure of

Pick whichever memory feels most reliable and turn it into a single clause first, rather than trying to write the whole query from memory in one go. A rough date is usually the strongest starting point, because it narrows a library of tens of thousands down to a window of weeks without needing to be exact.

Eight hundred and ninety is still too many to scroll, but it's a start, and every clause added from here only narrows it further.

Step 2: Add whatever you remember about the file itself

If the image was unusually large, a specific crop shape, or a particular format, that's a second clause that costs nothing to add and often does more narrowing than the date did.

width and height read straight off the file at index time, so this works whether or not the image was ever opened again after it was first added — there's nothing to have forgotten to record, because nothing needed recording in the first place.

The same is true of format and media type. If the memory includes "it was a screen recording, not a photo" or "it came from a raw file, not a JPEG," type:video or ext:heic narrows just as hard as a dimension does, and neither requires the file to have been touched since the day it was added — the first pass read the format once, and that fact doesn't age.

Step 2b: Combine two weak memories before trusting one strong one

A memory that feels shaky on its own — "maybe it was large, maybe not" — is still worth adding if a second, equally shaky memory points the same direction. Two uncertain clauses stacked together often narrow harder than either would alone, precisely because they're independent facts rather than two guesses at the same thing.

Step 3: Reach for rating and favourite status next

A vague memory like "it was really good" or "I starred it" is a real search clue, not a feeling to give up on. rating and is:favourite both narrow hard, because most of a library is never rated at all.

Thirty-one is a number you can actually scroll through and recognise the thumbnail among. If the memory of having rated it well turns out to be wrong, dropping that one clause is cheap — the date window alone is still a far smaller set than the whole library.

Step 4: Search notes, not just tags

If a note was ever written on the file — even a short one — the text of that note is searchable the same way a tag is. A half-remembered phrase like "good pose, wrong lighting" is often more distinctive than any tag would have been, because notes tend to be specific to one file rather than shared across a category.

Step 5: Try the folder, if any of it comes back

Sometimes a fragment of the folder name surfaces once the search gets close — "it was in something about the Berlin project." Scoping with in: cuts straight to that folder without needing the exact path memorised, since partial folder names still narrow the registered roots down to the plausible ones.

There's a broader point buried in that, worth stating directly: search built on facts the index captures automatically is inherently more durable than search built on facts you have to remember to record. A tag has to be typed at the moment it would be useful later, which means it only exists if someone anticipated the exact future search correctly. A dimension, a format, a date added — none of that anticipation is required, which is exactly why it's still there, two years later, when the tag that would have made this easy was never applied.

What to do when none of the clues narrow it enough

Occasionally every clause that comes to mind still leaves too many files — the date was a guess, the rating memory was wrong, there was never a note. When that happens, drop back to the widest reliable clause and sort by it instead of filtering further: sorting a few hundred results by date added, newest first, and scrolling with thumbnails visible is still faster than opening folders one at a time, because at least the search has already ruled out everything outside the window.

A worked example: "a portrait from sometime last year, I think I starred it"

That sentence alone is three clauses: a shape, a rough window, and a status flag.

There's no dedicated "portrait" key in the syntax, so the actual move is picking a width ceiling low enough to rule out most landscape crops. It's a small extra step, an approximation rather than an exact filter, but it's still faster than opening a year of folders looking for a shape you can only describe, not name precisely.

A second worked example: "a clip, not a photo, from a shoot last spring"

The same approach works identically when the memory is of a video rather than a still — nothing about the method changes, only which key carries the media-type clause.

Five results from a starting library of tens of thousands, built from nothing more precise than "a clip," "around spring," and "I think I wrote a note on it." None of those three facts requires having looked at the file since the day it was saved.

Common mistakes worth avoiding

Scrolling by eye before trying a single query clause — even a wrong first guess at a date narrows the search space faster than looking at thumbnails does. Giving up on a memory because it feels too vague to be useful — "it was pretty recent" is still added:> something, and a rough boundary beats no boundary. And forgetting that dropping a clause is free — if a guess turns out wrong, removing it costs nothing and the search is exactly where it was before that clause was added.

A subtler mistake is confusing "date added" with "date the photo was actually taken." A file imported from an old hard drive years after it was originally shot has an added date reflecting the import, not the shoot — worth remembering when a date-window clause returns nothing, since the memory of "it's from that trip" and the memory of "I added it recently" can point at two completely different windows for the exact same file.

Why this works without having tagged anything

The whole approach depends on the index having captured facts about a file the moment it was added, rather than only what you deliberately typed in about it. Dimensions, format, date added and date modified are read during the first pass, before any tag or rating exists — which means even a file you saved once and never touched again carries enough for a query like the ones above to find it. Searching without tagging first covers this same principle for a different starting problem: building a useful search on a folder that's never been organised at all, rather than finding one specific file inside a library that mostly has been.

What to do when the library gets large

None of the steps above get harder as a library grows — if anything, a larger library makes date and rating clauses do more work, because there's more to rule out. What's worth doing ahead of time is saving the combinations you reach for often as views, so "recent, well-rated, not yet used" becomes a click rather than a query rebuilt from memory every time the same kind of search comes up.

Speed doesn't change with scale either — a query against forty thousand indexed files runs against the same index a query against four hundred does, rather than scanning folders live each time it's typed, so a search this specific costs nothing extra to run on the largest library it might ever need to search.

Building the habit before the next time this happens

The real payoff of this approach shows up the second time a search like this is needed, not the first. Once a rough date, a rating and a folder name have proven themselves as reliable search clues once, reaching for them the next time a half-remembered file needs finding stops feeling like a puzzle and starts feeling like a routine three-clause query — the same habit saving the combination as a view turns into something that doesn't even need retyping the query text, just recalling which view answers which kind of memory.

The full set of search operators covers every key used above and the ones left out — tag, ext and no are all useful once a library has more structure to search against. Organizing a library from folders you already have is the place to start if this kind of search keeps coming up empty because nothing has been indexed yet. The case for one query line over a folder tree covers why this approach beats browsing at any library size, and the one-time-purchase shape of the tool itself is worth reading if cost is part of the decision. Or try it against your own years-old folders — thirty days, every feature, no card and no account, which is enough time to test whether a half-remembered file is actually findable.