Search screenshots by what is in them, not by filename

Why screenshots are always hard to find again

Your memory stores content; the filesystem stores pixels; there is a missing layer in between. You remember "last week's expense receipt", "the meeting room address somebody sent", "that path in the error dialog" — and the only dimensions the filesystem offers are name, modification time and folder, none of which correspond to any of that. So the real procedure for finding a screenshot becomes scrolling thumbnails backwards through time until your eyes give up and you ask somebody again.

General photo managers do not help here, because they index capture settings, geolocation and faces — metadata that belongs to photographs, not to screenshots. Almost one hundred percent of the information in a screenshot is in the words rendered into its pixels: amounts, ticket numbers, paths, times, names, URLs. Without reading those words, any search is guesswork.

So the missing layer is quite specific: pull the text out of every screenshot and store it as searchable text, add a vector that can express "means roughly the same thing", and let both ways of finding work at once. That is the one thing this feature does, and it does it on your own machine.

What exactly goes into the index

The index is not a black box. These four things are all of it — there is no fifth:

• OCR text: after a capture is saved, a local PP-OCR pass runs in the background, downscaling anything with a long edge over 1600 pixels first. What gets stored is not a pile of loose fragments but text that has been through layout reconstruction: skew from the line boxes, clustering into visual lines, paragraph breaks on an em-normalised gap threshold.
• QR contents: OCR cannot read a QR pattern, so a screenshot of one would be invisible to search. The code is decoded separately and its payload is indexed as text.
• Page text, and only if you turn it on: when a URL appears in the recognised text or inside a QR code, the public page behind it is fetched and its body text is indexed alongside. HTTP and HTTPS only, a ten-second per-page timeout and a 3MB cap. This is off unless you enable it.
• A 1024-dimension embedding of the above, which is what makes "meeting room" find a screenshot that only ever said "conference room".

Everything in that list is written to your own disk. No account, no upload, no cloud index. The two models involved are downloaded on demand from Settings — resumable, sha256-verified, and importable from a file if you already have them.

Keyword and semantic search, fused rather than chosen

Keyword search is exact and unforgiving: it finds the invoice number you half-remember, and it finds absolutely nothing when you type a synonym. Semantic search is the opposite: it copes with paraphrase and fails to prioritise an exact string that appears verbatim. Picking one means accepting the other one's failure mode permanently.

So both run, and their rankings are fused with reciprocal rank fusion. Keyword matching combines substring hits with a Chinese bigram Dice coefficient, which is what makes partial Chinese phrases behave sensibly; the semantic side compares the query embedding against the stored vectors. Each result card is labelled with how it was found — text, meaning, or both — so the ranking is legible rather than magic.

If the embedding model is not present, search does not break. It falls back to keyword mode and says so in the index status line, rather than handing you a search box that silently returns nothing.

Getting out of the way of the screenshot itself

A background indexer that makes the capture hotkey feel sluggish has defeated its own purpose, so the AI work is explicitly second-class. Three gates enforce that: the queue checks for an active capture session before dequeuing anything; starting a session aborts generation that is already in flight; and models unload entirely after ten idle minutes rather than sitting resident.

The practical result is that indexing happens in the gaps. A freshly taken screenshot is searchable a few seconds later — you can watch the text appear on the gallery cards — and at no point does pressing Ctrl+Shift+A have to wait for it.

Practical notes

• Only saved captures are indexed. A capture that went to the clipboard and nowhere else leaves no file, so there is nothing to index; turn on auto-save, or use Save as.
• You can see what any single screenshot contributed: open it in the preview and press "Indexed text". That panel is read-only and does not trigger re-indexing.
• If you turned indexing on after already collecting a pile of screenshots, "Rebuild index" walks the backlog in the background.
• Removing an entry from the gallery does not delete your file. The index reconciles on the next pass and only drops entries whose file is genuinely gone.

Frequently asked

Are my screenshots uploaded anywhere to make them searchable?

No. Recognition, embedding and the index are all local, and the index file is on your own disk. The models are downloaded once from Settings and then run offline.

What if I only download one of the two models?

Everything degrades gracefully. Without the embedding model, search falls back to keyword mode and the status line says so. Without either, capture, annotation, scrolling capture and text extraction are entirely unaffected.

How soon after taking a screenshot can I search for it?

A few seconds, once the background pass finishes — the text showing up on the gallery card is the visible signal. Indexing always yields to an active capture session, so a busy moment can push it slightly later.

Does searching also look at page content behind links in my screenshots?

Only if you turn that on. It is off by default, restricted to http and https, capped at 3MB per page with a ten-second timeout, and it fetches nothing but the public page at that URL.

Read next