Find a screenshot by the text inside it

You remember the error message. You do not remember whether you took the screenshot on Tuesday or Thursday, and the file is called Screenshot 2026-07-14 at 09.12.44.png like every other one. Searching for what the image says, rather than for what it is called, is the only version of this that works.

Why filenames fail

A screenshot filename records the one thing you already know, the moment you took it, and nothing about why. A folder of them is sorted by an attribute nobody remembers. So the search you actually perform is opening images one at a time until you recognise the right one, which is not a search at all.

Renaming them as you go is the advice everyone gives and nobody follows, because the cost lands at the moment you are busiest and the benefit lands weeks later. Anything that depends on discipline at capture time loses to anything that works without it.

What text recognition changes

Screenshot Files reads the words in each image and stores them alongside it. The image itself is unchanged; what is added is a searchable transcript of what is visible in it. From then on the search box matches on that text as well as on names and tags, so typing part of an error message, an invoice number, a domain, or a person's name in a chat screenshot brings the image back.

Screenshots are unusually good input for this. Unlike a photograph of a document, a screenshot is already flat, evenly lit, at a sensible resolution, and made of rendered text rather than printed text. That is the easy case for recognition, which is why this works well on interface captures, error dialogs, chat threads and dashboards.

It runs in your browser, not on a server

The recognition happens in the page you have open. The engine is downloaded once, runs on your own machine, and the image is not sent anywhere to be read. What reaches our servers is the recognised text, so search can match it, and never the image for the purpose of analysing it.

This is the part that decides whether the feature is usable at work. Screenshots are the single most sensitive category of file most people produce casually: they contain customer records, internal dashboards, private messages, and whatever else happened to be on screen. A tool that ships those to a third-party vision API to make them searchable has bought you convenience with someone else's data. Doing the reading locally avoids the trade entirely.

It also means recognition works with no network at all, and that a slow or unavailable service can never be the reason your library is unsearchable.

What it costs you in practice

Nothing is free. Reading an image takes a second or two of your own processor rather than someone else's, so recognising a large batch is noticeably busier than doing nothing. The engine is fetched on first use, so the very first screenshot you index waits for that download and every one after it does not.

Recognition is currently English. Interface text in other languages will often still produce useful fragments, especially names, numbers and domains, but do not expect a clean transcript of a page written in a language the engine was not trained on.

The stored text is capped, so an unusually dense screenshot is indexed up to that cap rather than in full. In practice a screenshot with more text than the cap is a screenshot of a wall of text, and the first part of it is enough to find the image again.

How to search once your library is indexed

There is one search box and it matches everything at once: the screenshot name, its tags, the page it came from, and the recognised text. You do not choose a mode. Type the most distinctive thing you remember, which is usually a fragment nobody else would have written: an order number, an unusual surname, the exact wording of an error.

Two habits make the difference. Prefer a rare word to a common one, because "error" appears in half your library and "ECONNREFUSED" appears in one screenshot. And search for what was on screen rather than what you would have called it, because the transcript contains the former.

Very broad searches are capped at a few hundred matches, and the library says so when that happens rather than quietly handing back a shortened list. If you see that notice, add a second word.

Common questions

Does the image get uploaded to be read?

No. Recognition runs in your browser. Only the recognised text is stored, so that search has something to match against.

Can I copy the text out of a screenshot?

Yes. The same recognition that makes an image searchable also gives you its text to copy, which is the fastest way to get an error message out of a screenshot and into a search engine or a ticket.

Are older screenshots searchable too?

Screenshots are indexed as they pass through the tool, so a library that predates the feature becomes searchable as those images are opened rather than all at once.

What if the screenshot has no text?

Then text search cannot help, and names and tags are what you have. This is worth knowing about your own library: photographs, diagrams and design mockups benefit far less from this than interface captures do.