Tagging is the part of organising a library that people put off, and the untagged pile grows quietly in the meantime — nobody decides to stop tagging, it just becomes the thing that never quite gets caught up on. The fix isn't to catch up on tagging. It's noticing how much is already true of a file before anyone touches it: its type, its dimensions, when it arrived, whether it has a note. Built well, a query line can answer most real questions using only that, and the untagged pile stops being a liability the moment it's searchable on its own terms rather than waiting on a tagging session that keeps getting pushed back.
This matters because tagging discipline is fragile in a way file facts never are. A tag only exists if someone applied it, consistently, on the day the image arrived. Dimensions, file type and the date a file was added exist whether or not anyone was paying attention that day, which is exactly why they make a more reliable foundation for search than tags alone ever can.
It also changes what "organised" means in practice. A library where every image is searchable by type, size and date, and only a fraction carries tags, is more useful day to day than one where tagging was attempted everywhere and abandoned halfway — the first is consistently searchable by what it has, the second is inconsistently searchable by what it doesn't. The goal below isn't zero tags; it's not depending on tags for the questions that file facts already answer.
Step 1: Start with what indexing already read
The first pass over a folder reads dimensions, EXIF and colour without anyone tagging anything. That alone is enough to answer questions like "the big ones I saved recently" or "everything that's a video rather than a still," neither of which needs a label, and both of which are the kind of question people usually assume they'd need to tag their way into answering.
This works because indexing happens once, automatically, the moment a folder is registered — there's no separate step where you'd choose to skip reading EXIF or dimensions. Every file gets these facts whether or not it ever gets a tag, which is exactly the property that makes searching without tagging possible in the first place rather than a workaround people fall back on when tagging fails.
Dimensions in particular do more work than people expect. A width or height
filter often stands in for a tag that would otherwise say something like
print-quality or web-only — the size already tells you which bucket an
image belongs in without anyone having decided to label it that way.
Step 2: Find the untagged pile directly
Rather than guessing at what's missing labels, ask for it by name.
Seeing the actual number tends to be the useful part — it's usually larger
than expected, and it's the exact set no amount of future tagging discipline
reaches backwards into, because tagging discipline only ever applies to
what gets added after you adopt it. no:tags is what makes that backlog
visible and addressable rather than a permanent blind spot that just grows
in the background.
Narrowing it further is often more useful than working through the whole pile at once — a thousand untagged images is not a task, but a hundred untagged images from a specific month, filtered by size or type, usually is.
Step 3: Combine rating and status instead of inventing tags for them
A lot of what people reach for a new tag to express is really a rating or a status, both of which the app already tracks as their own thing rather than needing to be encoded into a tag name.
is:favourite and a numeric rating cover a surprising amount of what people
would otherwise invent a tag like good or keep to say, and they combine
with everything else in the query line the same way a tag would, so nothing
is lost by using the built-in fields instead of a home-made label for the
same idea. A rating also sorts and compares in a way a text tag never will
— rating:>=4 is a meaningful range query, where tag:good only ever means
"has this exact label or doesn't."
Step 4: Use notes for things too specific to be a tag
A tag is a reusable label; a note is a sentence about one specific image.
has:notes finds everything you've written something about, whether or not
it was ever also tagged — useful for images that got a comment in the
moment ("wrong lighting, right pose") but never made it into a proper
tagging pass, and it means that comment isn't lost just because it never
became a formal label.
This combination is worth checking periodically on its own, since it tends to surface images that got real attention at some point — enough to write a sentence about — but never made it into whatever tagging pass happened around them.
Step 5: Save the query once it earns its keep
The first time a filter combination answers a real question, save it as a
view rather than retyping it. A saved view stores the search's text and
re-parses it on open, so it keeps returning current results as the library
grows — the same idea Finder calls a Smart Folder,
under a different name, and just as useful here as it is there once you've
found a combination worth reusing. A view built on no:tags in particular
is worth keeping permanently, since the size of the untagged pile is useful
to check on its own even after the library feels reasonably organised.
Where tagging still earns its place
None of this replaces tags entirely, and pretending otherwise would be dishonest. A mood, a subject, a colour palette described in words, a project name — none of that is a fact the app can read off a file, so it still needs someone to type it once, and no amount of clever querying against file facts will ever surface a concept nobody recorded anywhere. Tags versus folders covers where each system is actually the right tool, and it's a useful read before deciding how much of a given folder is even worth tagging by hand.
It's also worth being direct about a real gap here, not a small one: refern can describe an untagged image in a sentence — its own example is "dramatic lighting" — and surface pictures that carry no matching tag at all. That's search by meaning, and Coii Ref doesn't have it. What's above is search by fact: literal, but requiring nothing to have been typed first. The two are genuinely different capabilities rather than two names for the same thing, and a query line built entirely from file facts will never find an image on the strength of its mood or subject alone if that image carries no tag and no note describing either. The full comparison goes through what that difference means in practice and where each approach actually wins, which is worth reading honestly before assuming file-fact search covers everything a meaning-based search would.
A worked example: forty thousand images, three weeks in
Picture a library indexed three weeks ago, forty thousand images across two drives, almost none of it tagged yet. Rather than starting a tagging project, the day-to-day habit becomes fact-based queries first, tags only where facts run out. Looking for last week's client shoot: filter by date and file type, no tag required, because the folder it landed in and the date it arrived already say enough. Looking for "the moody portrait from that shoot in the spring" a few months later: date range narrows it to a few hundred candidates, rating narrows it further if it was ever rated, and only the last, most subjective step — actually finding the one that's "moody" — needs a human eye rather than a filter, because that's the one part of the description nothing on disk recorded automatically.
Building the habit of stacking filters
The queries above work best treated as building blocks rather than fixed
recipes. Type narrows to images or video; a dimension filter narrows to a
size range worth caring about; a date range narrows to a project window; a
rating or status narrows to quality; no:tags or has:notes narrows by
whether anything's been recorded about a file at all. Stacking two or three
of these almost always gets to a manageable, specific set faster than
opening a folder and scrolling, and none of the individual pieces requires
having tagged anything in advance.
The habit worth building isn't memorising every key — it's reaching for a file fact first and only falling back to a tag search when the question is genuinely subjective enough that no fact could answer it.
What this looks like for video
The same approach carries over to video without any special handling,
because video is indexed on the same pass and addressable from the same
query line rather than living behind a separate mode. A clip is filtered by
duration the way a still is filtered by dimensions, and type:video behaves
exactly like type:image in every other clause it's combined with.
For anyone whose reference habit is mostly footage rather than photographs, this is the part worth testing directly rather than taking on faith: the untagged tail of a video-heavy library is just as searchable by date, format and rating as an image-heavy one.
Common mistakes worth avoiding
Treating no:tags as a to-do list rather than a fact — the goal isn't
necessarily to empty it, since plenty of images never need a tag at all if
file facts already answer every question anyone will ask about them.
Building overly narrow queries that combine five clauses when two would do
— each additional filter is one more thing that has to be exactly right,
and a query that returns zero results is often over-specified rather than
genuinely empty. And assuming a rating or a note can always substitute for a
tag — they can't, once you need to search by a category that applies to
many images across the library rather than describing one image at a time.
Why this is worth doing before tagging, not instead of it
None of the above is an argument against tagging — it's an argument about order. Building fact-based habits first means the library is useful from day one, before a single tag exists, and tagging afterward becomes a targeted activity aimed at the specific gaps file facts can't close, rather than a prerequisite standing between an indexed folder and a searchable one. Libraries that try to tag first, before trusting file facts to do their share of the work, tend to stall halfway through the tagging pass and never fully catch up — which leaves them worse off than one that never started tagging at all, since a half-tagged library often searches worse than an honestly untagged one that leans on facts consistently instead.
What to do as the untagged pile grows
The steps don't change at scale, only the reliance on them does. The larger a library gets, the more the file-fact queries above do the day-to-day finding, and the more tagging narrows down to just the handful of concepts that genuinely can't be read off a file — which is a much shorter list than it feels like at the start, once ratings, notes and file facts have taken over everything they're suited to. What EXIF actually is is worth reading if you're relying on it for dates or camera details, since not every image carries the same fields, and the query syntax in full covers every key beyond the ones used here. Ask whether you need this at all if your library is still small enough to answer these questions by scrolling — for a lot of people it still is. Otherwise: thirty days, every feature, no tagging required to start.