Data control

Your library lives on your disk — and erases on your command

On-device isn't just about where the computing happens — it's about where the data rests. MediaFind's entire index is a folder on your Mac: files you can back up, move, inspect, or delete. No export request, no support ticket, no waiting.

“We don't upload your media” is necessary but not sufficient. If the derived data — transcripts, thumbnails, face vectors — lived in some opaque place you couldn't reach, you still wouldn't be in control. So MediaFind keeps everything in one plainly-located data folder, in formats you can open, and gives you direct buttons to wipe the sensitive parts.

It's a folder, and you can see it

Settings has an Open data folder action that reveals exactly where your library lives in Finder. Inside, there's nothing exotic:

~/…/MediaFind/ index.sqlite3 SQLite · segments, vectors, people index.sqlite3-wal / -shm write-ahead log (crash-safe writes) prefs.json your settings · no secrets needed thumbs/ frame thumbnails (content-hashed) faces/ opt-in · only if faces are on (model cache) open weights · shared HF cache one folder · portable · inspectable · yours to delete
The whole library is files in one folder: a SQLite database (plus its write-ahead log), hashed thumbnails, and a plain-JSON settings file. The open model weights live in the shared Hugging Face cache, not necessarily this folder. Nothing here requires a server to read.

A few things worth calling out:

Because it's just files, it's portable

Owning your data means being able to pick it up and walk. The data folder can be relocated — onto an external drive, into a backed-up location, wherever — and the app keeps working. Earlier on, relocation used to break thumbnails, because the database stored absolute paths that went stale the moment the folder moved. The fix taught a durable lesson: store stable identifiers, not brittle ones.

The relocation bug, and the fix: thumbnails are saved under content-hash filenames, which never change. So when a stored absolute path goes missing after a move, the thumbnail endpoint just re-resolves it by basename against the current folder — and every thumbnail surface heals at once. The principle generalizes: anything that points at a location should degrade gracefully when that location changes.

Erasing it is a first-class feature, not an afterthought

The real test of data ownership is how easily you can make data disappear. MediaFind treats deletion as something you do routinely, with direct controls rather than a buried “contact us”:

You want to…Do this
Forget all face & people datamediafind people --forget
Reclaim space from the thumbnail cacheSettings → Clear thumbnail cache
Permanently delete quarantined items/cleanup/purge (all) or /cleanup/purge-items (specific)
Wipe everythingDelete the data folder — it's the whole library

Two design choices make this trustworthy. First, the most sensitive category — biometrics — has its own dedicated forget command, so you can drop face data without touching the rest of your index. Second, permanent deletion is split into an “empty everything” route and a “delete just these items” route, so a cleanup of one bad import can't force you to nuke the lot.

And a mode for shared machines

If you're showing MediaFind to someone — a demo on a borrowed laptop, a kiosk — Demo mode loads the bundled example clips, unlocks the Pro features so everything is explorable, and blocks adding your own media. It's a clean way to let someone try the product without their files (or yours) ending up in the index.

Ownership means reach

The throughline: your library isn't a row in our database that we let you peek at through an export tool. It's a folder on a disk you control. You can read it, copy it, move it, and delete it with ordinary commands — and the most sensitive slice of it, the biometrics, has a one-line off switch. That's what “your data” should actually mean.

Own every byte of your library

One local folder. Yours to back up, move, or erase — no export request required.

Download for macOS