How to Organise a Photo Library by Person — Without Retagging Everything
Organising tens of thousands of photos by person fails when it depends on manual tagging. Build a person library from one photo per person and let the index do the grouping instead.
Published 2026-09-26 3 min read
- photo organisation
- person libraries
- workflow
Most photo organisation systems ask you to do the work up front: create an album, drag photos into it, add a name to a face. That model collapses somewhere around the ten-thousandth photo, because the effort is paid once per photo and the payoff arrives much later.
There is a cheaper way to get 90% of the value: keep your folders exactly as they are, and build an index of people alongside them. You supply one photo per person; the index does the grouping.
Why folder-based organisation breaks
Folders answer “where was I when I took this?” Very few of your real questions are shaped like that. The questions people actually ask are:
- Which photos is my mother in?
- Which of these contains the client I met last spring?
- Who was at that event?
None of these are folder questions. They are person questions, so the only organisation scheme that answers them is one indexed by person.
Build a person library from one photo each
A person library is just a folder of reference photos:
- Name the file after the person — the file name becomes their name in SnapByFace.
- Sub-folders are optional — SnapByFace scans them recursively, but the name still comes from the file name.
One clear photo per person is enough to start. Add more reference photos only for people whose appearance varies a lot across your library — children growing up, someone with and without glasses, a decade of change.
:::tip Start with the two or three people you search for most. Index the rest when you actually need them; the index is incremental, so adding someone later only analyses what is new. :::
Then index the media, not the people
Point SnapByFace at the folders holding your photos and video and let it walk them recursively. No reorganisation required — you do not flatten, rename, or restructure anything. SnapByFace reads your media and never writes to it.
Every face it finds is remembered in an index that stays on your own disk. Add new photos later and only the new ones are looked at.
Grouping, not moving
This is the part worth emphasising: the output is a view, not a reorganisation. You get:
- By person — every hit for one reference photo, sorted by similarity.
- By file — everyone found in one photo.
Your original folder structure stays untouched. If a particular set of results matters, export it to CSV and use that list elsewhere — in a filing system, a client deliverable, or a spreadsheet.
Choosing a threshold that matches your tolerance
The similarity threshold decides what counts as a match — 0.45 by default, adjustable between 0.30 and 0.80.
- If your goal is a complete list (a client wants as many matches as possible), lower it and accept that you will review a few false positives.
- If your goal is a clean list (a slideshow you will not hand-check), raise it.
Adjusting the threshold does not re-analyse anything — your photos have already been looked at once, so it is just a stricter or looser cut-off over the same findings.
What this does not replace
Be clear-eyed about the scope:
- It does not tag or rename files. Results live in the index; your library is read-only to the app.
- It does not identify strangers. Only people you added as references are found.
- It does not curate. It answers “where is this person”, not “which of these are good photos”.
Where your data stays
Recognition and search run on your own computer. Your photos and videos never leave it — everything the app knows about them stays in ~/.snapbyface/, and there is no account to sync to.
The only thing that leaves is an optional device statistics ping (machine code, app version, operating system, language, activation state and plan), which contains no photos, face data, file paths or search activity, and can be switched off in Settings.