Two answers, not one, and the right one changes per project

Anyone asking how to organize references by project is usually expecting a single rule — folders, always, or tags, always — and the honest answer is that the two solve different versions of the same problem. A project whose files genuinely belong to it and nowhere else is a folder. A project that shares assets with two others, or reuses a location library across an entire season of work, needs something that doesn't force one file to live in only one place. Most real libraries end up using both, and deciding which applies to which project is the actual skill here, not memorizing one convention and applying it everywhere.

The reason this needs deciding at all, rather than defaulting to whichever structure a different tool trained you to expect, is that both folders and tags cost something different. A folder is free to search — in: scopes to it with no setup — but assumes a file belongs to exactly one place. A tag costs a moment of applying it by hand but lets a single file answer to as many projects as actually use it. Neither is more "correct" than the other; they're suited to different shapes of project, and the steps below work through both.

Step 1: Default to a folder when a project owns its files outright

If a shoot, a client job or a piece of work produces references that belong entirely to it, a dedicated folder is the simplest structure and the one that needs the least explaining to anyone else who opens it later.

Registering that folder as part of the wider workspace means everything inside it is searchable the moment it's indexed, with no separate import step for each new project — the folder itself is the only setup required.

Neither approach requires deciding on a library-wide policy before starting a single project. A photographer with one recurring client and a dozen one-off jobs can run folders for the one-offs and a tag for the recurring client's work, in the same workspace, without either choice interfering with the other — the app has no concept of a library-wide organizing scheme to violate, only files, folders, and tags applied to individual files.

Step 2: Scope a search to one project with in:

Once several project folders exist side by side, in: keeps a query from returning results outside the one you're actually working in.

That scoping is free — it doesn't require a project-specific tag or any setup beyond the folder already existing where it does. For a project whose files genuinely stay inside its own folder, in: is often the only project-level filter that's ever needed.

Both structures answer the same underlying question — "what belongs to this project" — using entirely different mechanisms, which is precisely why they compose rather than compete: a folder answers it by physical location, a tag answers it by an explicit label applied per file, and a single project can lean on either or both depending on how its own files actually behave.

Step 3: Reach for a tag when a file serves more than one project

A folder assumes exclusive ownership, and not every file has that. A location library reused across a season, a texture set that shows up in three unrelated jobs, or a recurring model's turnaround sheet — none of those want to be duplicated into every folder that references them. A tag handles that case directly: apply project-atlas to a file without moving it anywhere, and it shows up in that project's searches without leaving wherever it already lives.

Whether a project is folder-based or tag-based isn't an either-or across the whole library; it's a call made per project, based on whether its files are actually exclusive to it.

A project can also change which approach fits it partway through its own life — a job that started as a single self-contained shoot and grew into something drawing on a shared asset library doesn't need to be rebuilt from scratch when that happens. The folder stays exactly where it is; a tag gets added for the shared pieces once they're actually needed, layered on top of a structure that was already working fine for everything else.

Step 4: Keep the project's boards inside its own folder

A canvas saved outside the project it belongs to is easy to lose track of the moment the project wraps. Saving it inside the same folder — a Boards subfolder is a reasonable convention — means the project's layout work travels with everything else the moment that folder gets archived, backed up or handed to someone else.

Sharing a board without a cloud account and keeping a board under version control both assume this: a board that already lives inside its project's folder is one file away from being sent or tracked, rather than something to hunt down first.

Step 4b: Naming a project folder so it sorts the way you'd expect

A short, consistent naming pattern for project folders — client name first, or date first, whichever gets used more often when scanning a folder list by eye — makes a growing set of project folders easier to scan without opening any of them, which matters more the moment there are enough active and recently finished projects sitting side by side that alphabetical order alone stops being enough to find the right one quickly.

Step 5: Save a view per active project instead of retyping the scope

A project that's being searched repeatedly over weeks is worth turning its in: query into a saved view once, rather than retyping the same folder path every time a search starts. The view re-parses on open, so renaming the project folder is the only thing that would ever require updating it.

Step 6: Archive a finished project without losing what's in it

A project that's done but staying in the active workspace can be tagged archived rather than moved, which keeps it searchable but easy to exclude from day-to-day results with a simple -tag:archived. A project leaving active work entirely is better moved onto an archive drive registered as its own workspace — either way, because the project's files, tags and boards live together in one folder, archiving is a move or a tag, not a multi-step export.

Step 7: Combine both inside a single project when it needs it

A folder-based project isn't limited to in: alone once it's underway — a tag for status within that project, draft or approved, layers on top of the folder scope without contradicting it. in:~/Projects/Harbor-Campaign tag:approved is a normal query, folder and tag together, and it's a reminder that the folder-versus-tag decision above is about how a project relates to the rest of the library, not a rule about what's allowed inside one project's own folder.

Step 8: Bring a new collaborator up to speed on the structure

Handing a project folder to someone who's never worked in this library before goes faster when the structure inside it is self-explanatory — consistent subfolder names, a board that's easy to find because it's always in the same place relative to the images. Nothing about that consistency is enforced by the app; it's a convention worth deciding on before the second project exists, since retrofitting a naming pattern onto folders that have already diverged is far more work than starting with one.

Step 6c: A single asset library shared by every project

Some references never belong to one project at all — a swatch library, a standing set of brand assets, a texture archive built up over years and drawn on by whatever's currently active. Those are worth their own root, registered independently of any individual project folder, tagged by category rather than by project, and reached from inside a specific project's search only when a project tag is deliberately combined with one of the shared library's own tags.

A worked example: one recurring location across four projects

A studio location shot repeatedly across a year of unrelated client work is the clearest case for a tag over a folder — the images don't belong to any one project, and copying them into four separate project folders would mean four copies to keep in sync every time a new shot gets added.

Tagging the location once and letting each project's own tag sit alongside it — tag:project-harbor tag:studio-b-location on the handful of files that are both — covers the overlap without either project owning files it shouldn't.

Step 9: What changes when a project outgrows its folder

A project that starts small and grows — a single shoot that becomes a season-long campaign, say — doesn't need its structure rebuilt from scratch. The folder it started in keeps working exactly as it did; what usually needs adding is a status tag once "everything in this folder" stops being specific enough, or a split across more than one drive once the project's raw footage alone outgrows the drive it started on. Both of those layer on top of the original folder structure rather than replacing it, which is the practical benefit of starting with the simpler option: growing into tags or multiple drives later costs a query adjustment, not a reorganisation of files that already exist.

Common mistakes worth avoiding

Forcing every project into a folder, including ones that share assets with others, is the most common one — it leads to the same file copied into several folders, which then drift out of sync the moment one copy gets tagged or rated and the others don't. The opposite mistake is tagging everything and never using folders at all, which works but loses the free scoping that in: provides for a project whose files genuinely are exclusive to it. And leaving a project's board in a separate, general "Boards" folder outside any project structure — convenient in the moment, and the first thing that goes missing when the project itself gets archived or handed off.

Deciding which projects get which treatment, quickly

For anyone starting a new project and unsure which structure fits, the question worth asking is simply: will anything in this project ever need to be found from a search that isn't scoped to this project alone? If the answer is no — a self-contained shoot, a one-off job with no shared assets — a folder is the right and simpler choice. If the answer is yes — a recurring location, a shared prop library, an ongoing client whose work spans several distinct jobs that still need to be told apart — a tag, or a folder with a tag layered on top for the shared pieces, is worth the extra step of applying it by hand. That one question settles the decision faster than trying to reason abstractly about the tradeoffs each time a new project starts.

What to do as the number of active projects grows

A consistent subfolder pattern — sources, approved, boards — repeated inside every project folder makes each new project fast to set up and easy to navigate without relearning its structure. For projects that lean on tags instead, keeping the tag vocabulary to one tag per project, rather than a project tag plus several sub-tags, keeps -tag:archived and similar exclusions simple even once dozens of projects, active and finished, share the same workspace.

Organizing reference images on a Mac covers the broader structure this fits into, and setting up saved views covers step five in more depth. What a smart folder is and tags versus folders for images are worth reading for the wider version of the folder-or-tag question this page answers per project rather than once for the whole library. Or try it on your next project — thirty days, every feature, no card and no account, is enough to set up one project folder and one cross-project tag and see which shape actually fits the work.