Screenshots end up containing some of the most sensitive text on your Mac almost by accident. You screenshot a password reset email to reference a code, a banking app to remember a balance, a benefits portal to save a confirmation number — not because you meant to archive sensitive data, but because a screenshot was the fastest way to capture what was on screen in that moment. If that image then gets read by OCR and indexed for search, the obvious question is: read by what, and indexed where?
The recognition step runs on your Mac, full stop
ScreenClipr reads the text in every capture using Apple's Vision framework — specifically a VNRecognizeTextRequest running at its "accurate" recognition level, with language correction and automatic language detection turned on. All of that runs as a local, on-device request against the image in memory. There is no API call involved in getting text out of a screenshot, no upload of the image to a server for processing, and no third-party OCR service anywhere in the pipeline. The recognition happens the same way Live Text recognition happens elsewhere on your Mac — locally, using the operating system's own vision stack — and it works identically with your Mac completely offline.
The index itself is a file on your disk, not a database somewhere else
Once text is recognized, it's written into a local search index — a SQLite database using the FTS5 full-text search extension — that lives on your Mac alongside your captures. Searching your library means querying that local file, not sending a request to a server and waiting for results to come back. There's no account required to use search, no sign-in that ties your search history to an identity on someone's backend, and no dependency on an internet connection for search to work at all. If your Mac has no network access, search still works exactly the same, because it was never talking to the network in the first place.
What this actually means for a sensitive screenshot
Put concretely: if you screenshot a two-factor code, a bank statement, or a field full of a family member's medical information, the text ScreenClipr extracts from that image is recognized by a local system framework and written to a database file on your own disk. It is never transmitted to ScreenClipr, to Apple's servers beyond what Vision itself does locally, or to anyone else — because nothing in that path makes a network call. There's no moment where that text exists on a server you don't control, no log of your searches sitting in a cloud account, and no scenario where a data breach at a vendor's backend could expose what was in your screenshots, because there is no vendor backend in that loop to breach.
The trade-off cloud-based OCR makes, and why local avoids it
Some screenshot and productivity tools process OCR or search in the cloud — sending the image, or the recognized text, to a server so the heavier processing or indexing can happen there instead of on your machine. That's a legitimate engineering choice, and it isn't automatically careless: a well-run service can encrypt data in transit and at rest, and plenty of people are comfortable with it. But it is a meaningfully different trust model from a purely local pipeline. The moment recognized text leaves your machine, its handling depends on another party's infrastructure, retention policy, and security practices — all of which can change, get breached, or simply be interpreted differently than you assumed when you first read the privacy policy. A local-only pipeline sidesteps that dependency entirely: there's no server-side copy of your screenshot text to be governed by a policy at all, because it was never sent anywhere for one to apply to.
Why this was the design from the start
This isn't a privacy feature bolted onto an otherwise cloud-first product — the whole capture-to-search pipeline (capture, OCR, indexing, and the search itself) runs locally by construction, because screenshots are exactly the kind of file where "probably fine" isn't a comfortable enough answer. A screenshot tool that indexes everything you capture for instant search is genuinely useful specifically because it doesn't ask you to think about what's sensitive before you capture it — and that only holds up if the indexing itself doesn't quietly become the thing you have to think about instead.