Skip to content

Most people with a real image collection have already done the organising — folders by year, by client, by project — and the actual problem is narrower than "organise my files." It is that none of the built-in tools can search what is already true of them: which ones are rated, which ones are tagged, which ones are video versus stills, all at once, across every folder rather than one at a time.

Where folders alone stop being enough

A folder view sorts by name or date and shows everything in it, which is fine until the question is not "what's in this folder" but "which of the four hundred photos across six folders are rated four stars and tagged studio." Spotlight finds a file by its name; it does not know a tag exists or that a rating was set. Finder tags exist but do not combine with rating, type or dimensions in a single search, and neither one reaches across external drives that are not currently mounted. The folders were never the problem. Searching what they actually contain is.

One line, every key at once

/type:image tag:any:portrait,studio rating:>=4 -is:favourite
typeimagetagany:portrait,studiorating>=4notisfavourite
58 items
Four filters in one line, each one a chip you can delete — type, tag, rating and a negated flag, searched across every registered folder at once.

The same query line drives the grid, the autocompleter and any saved view: type picks the media, tag:any:a,b matches either tag, rating:>=4 sets a floor, and a leading - excludes. AND across keys, OR inside a comma list, no parentheses — grouping is what makes a query impossible to autocomplete or draw as chips.

ext:mov type:video rating:>=3        clips worth keeping, not top-rated
has:notes no:tags                    written up, never actually filed
width:>4000 -in:Archive              large originals outside the archive
added:>2026-01                       everything indexed so far this year

A word the parser does not recognise renders as free text rather than an error, so the grid never stops returning something while you are still typing a term it may not know.

Pointed at folders exactly as they already are

~/Pictures
  • 2023 Clients
  • 2024 Clients
  • 2025 Clients
  • Archive
  • coii-thumbnailswritten by Coii Ref
  • coii-proxieswritten by Coii Ref
  • coii.dbwritten by Coii Ref
A folder structure built up over years, registered as one workspace without moving a single file — the three rows Coii Ref writes sit beside them, not inside them.

Registering a workspace reads the folder you point it at and writes its database, thumbnails and proxies inside that same folder — never a separate copy, never a rename. A structure built up over years of client work, sorted by year because that made sense at the time, stays exactly as it is; the search layer sits on top of it rather than requiring it to change shape first.

A saved search instead of retyping the same line

A query typed once and used often is worth saving rather than retyping, and a saved view stores the text of the query itself rather than a fixed list of results. rating:>=4 tag:any:hero-shot saved today keeps returning the right set six months from now even after new files are added and old tags are renamed, because it re-parses the same text every time it opens rather than remembering which specific files matched on the day it was created.

Searching across drives that are not always connected

A real collection is rarely on one disk — an internal drive, an external archive, a backup drive that only gets plugged in occasionally. Each one registers as its own workspace, keeping its own index, so a query run against a currently unmounted drive's last known state still returns results instead of an empty grid, and reconnecting the drive brings the index back in sync with whatever changed while it was away.

Beyond a filename and a folder, Coii Ref reads dimensions, EXIF and colour out of each image at index time, which is what makes width:>4000 or a search scoped to a particular camera's files possible without opening anything by hand first. It reads that data; it does not edit it, and the original file is never rewritten to add what the app has read.

Comparing this to relying on Finder tags alone

Finder tags are free and already on every Mac, and for a modest, well-tended set of files they can be enough on their own. Where they stop scaling is combining a tag with a rating or a file type in one search, or reaching across a drive that is not currently mounted — both of which a query line handles as one line rather than a sequence of Finder filters applied one at a time.

Comparing this to Apple Photos' own library

Apple Photos searches well within its own library, but getting files into that library means importing them into Photos' own managed storage first, which is a real step for a folder of reference images gathered from elsewhere rather than shot on your own camera. Coii Ref searches folders exactly where they already sit, with nothing to import.

What it costs and what it runs on

$19 once, three Macs, updates included, nothing that renews. The trial runs 30 days with every feature enabled, no card and no account required to start. It needs macOS 11 Big Sur or later, on Apple Silicon or Intel, as two native builds.

The app's entire outbound network activity is a licence check on Activate and a launch-time read of a server's Date header only, so a wound-back clock cannot extend a trial. There is no in-app updater, so no update check, and no analytics or crash reporting.

Past day thirty of an unpaid trial, growing the library — registering a new folder, running the importer, starting an index by hand — needs a licence. Search, tags, ratings, notes and the folder watcher all keep working permanently on whatever is already indexed.

What keeps a search accurate as files move

Search only stays useful if it stays true, and a rename or a move in Finder would normally leave an index describing files that no longer exist where it thinks they do. The folder watcher turns a filesystem event into the smallest re-scan that makes the database correct again, so a file renamed next month is still the same tagged, rated file under its new name, not a new unfiled entry with a lost history.

What "search" means when nothing has been tagged yet

A folder that has never been tagged is not a folder search cannot help with — type:image width:>3000 or ext:mov both work against files that have never had a tag or a rating applied, because dimensions and file extension are read at index time regardless of whether anything has been manually filed. Tagging makes a search more specific over time, but an untagged folder is searchable from the first index, on whatever the files already carry in themselves.

Turning up what a folder search never surfaces

A question like "everything I have never rated" or "images with no tags at all" is awkward to answer by browsing a folder view but direct as a query: no:tags or rating:0 -is:favourite returns exactly that set, across every registered folder at once. That kind of negative search — not what matches, but what has been missed — is often the more useful one on a collection old enough that parts of it were clearly never finished being filed.

What happens the first time a folder is registered

Registering a workspace triggers one pass over the folder to read dimensions, EXIF and colour and to write thumbnails and proxies beside the originals — the only step that takes real time, and it happens once per folder rather than every time a search runs afterward. A search itself reads the already-built index, which is why a query against forty thousand files returns as fast as one against forty, once that first pass is done.

What changes on a drive with tens of thousands of files

The difference between searching four hundred images and forty thousand is not the query line itself — the same type:image rating:>=4 works either way — it is whether the index behind it stays fast to build and fast to keep current. Indexing a large folder is a first pass done once and walked away from; after that, the folder watcher turns an ordinary Finder rename or move into the smallest re-scan that keeps the database correct, so a library that has grown for years does not need a full re-index every time a handful of files change.

Why a query line beats a stack of dropdown filters

A filter panel with a dropdown for type, a slider for rating and a checkbox list for tags usually runs out of room the moment a real search needs four conditions at once, and switching between panels to build one query is slower than typing it. A single query line scales the other way: type:video ext:mov rating:>=4 -is:favourite is no harder to write than a one-condition search, and the same line can be saved, shared as text in a message, or typed from memory the next time a similar question comes up, none of which a set of dropdowns supports as directly.

What a search actually returns when nothing matches exactly

A query that returns zero results is not always a dead end — narrowing a search too far, like combining a rare tag with too strict a rating floor, is a common way to end up with an empty grid on a library that clearly has something close. Because each key in a query is independent, loosening just one of them — dropping rating:>=4 to rating:>=3, or widening tag:any:a to tag:any:a,b, is enough to see whether the problem was the search or the library, rather than rebuilding the whole query line from scratch to find out.

What autocomplete actually helps with on an unfamiliar library

Typing a query against a library somebody else built — a shared studio drive, an inherited archive — means guessing at tags that were never your own vocabulary to begin with. Because the same query line drives the autocompleter, starting to type tag: and seeing the tags that actually exist in that workspace turns a guess into a fact, which matters most on exactly the library where the person searching had no hand in building the vocabulary they are now trying to use.

What a query line costs to learn

There is no separate syntax to study beyond the handful of keys the app already recognises, and a term outside that set never breaks a search — it just becomes something to match as plain text. Most people write a useful query within the first few searches, by trial and correction rather than by reading anything first.

Who this actually suits

Anyone whose folders are already reasonably organised and whose actual problem is that nothing built into macOS can search across type, tag, rating and EXIF at once. The round-up of offline-first image organisers covers the wider field if search alone is not the whole need, and the infinite canvas page covers the other half of this app's job — arranging what a search turns up. The general reference manager page makes the same argument without the search-specific framing this page leads with.

Thirty days, every feature, no card and no account: download it and point it at whatever folder structure you already trust. The first search that returns instantly is the one that shows whether this was ever really a filing problem at all.

Questions

Do I have to reorganise my folders before it can search them?
No. Coii Ref indexes folders exactly where they already sit. Registering a workspace does not move, rename or restructure a single file.
Can I search by more than one thing at once, like rating and tag together?
Yes. `rating:>=4 tag:any:portrait,studio` combines them — every key in a query is ANDed together, and a comma list inside one key is ORed.
Does it search inside PDFs or documents mixed into the same folders?
No. Coii Ref indexes images and video only. A PDF sitting in a registered folder is left alone rather than indexed or shown.
Can I save a search so I do not have to retype it?
Yes. A saved view stores the query text and re-parses it on open, so renaming a tag later does not break a view built on it.
What does it cost?
$19 once, three Macs, updates included, nothing that renews. The trial is 30 days with every feature, no card and no account.