What Tesseract does with a screenshot
Optical character recognition is the process of turning pictures of letters back into letters. The engine here is Tesseract, an open-source project that began at Hewlett-Packard in the 1980s, was released as open source in 2005 and spent years under Google’s stewardship. Modern versions recognise text with a neural network trained on line images rather than by matching individual character shapes, which is why they cope with fonts they have never seen.
Running it in a browser tab is possible because the whole engine is compiled to WebAssembly, along with the trained data for each language. The work happens inside a Web Worker, a background thread, so the page stays responsive while your processor does the recognition. It runs single-threaded, and not as a compromise: the OCR package ships only single-threaded WebAssembly cores, so there is no threaded build to choose. This site could not have used one in any case, because the cross-origin isolation headers such a build depends on are ruled out here.
Practically, the engine wants what any reader wants: reasonably large characters, decent contrast against the background, and lines that run roughly horizontal. Give it a clean screenshot of typed text and the output is often perfect. Give it a photo of a curved page shot at an angle in a dim room and it will do its best with a hard problem.
Five languages, and what picking the wrong one costs
The Text language selector offers English, Spanish, French, German and Portuguese. That is deliberately narrower than the hundred-plus languages Tesseract can be trained for, because each one is a separate model file that has to be downloaded and verified rather than merely listed.
Choosing the wrong one does real damage, so it is worth a moment’s thought. The model carries a language’s character repertoire and its statistical expectations about which letter sequences occur, and those expectations are used to resolve ambiguous shapes. An accented Spanish word read with the English model loses its accents; a German compound noun read as English gets guessed apart at the wrong place. Match the selector to the language actually printed in the image, not to the language you would like the output in.
Running recognition on a batch
- Drop your JPG, PNG, WebP or BMP images into the box above, or use Choose files. Files accumulate across drops.
- Set Text language to the language written in the images. It applies to the whole batch.
- Click Extract Text from Image (OCR). The first run downloads the engine and the trained data for that language before recognition starts.
- Watch the progress bar, which advances through each image in turn as it is recognised.
- Download the results. Each image produces its own
.txtfile, named after the source with the extension replaced.
The first run fetches a model, the rest reuse it
There is a real pause at the start of the first recognition, and knowing why makes it less alarming. The worker script, the WebAssembly core and the trained data for your chosen language all have to arrive before a single character can be read.
After that, the worker stays alive for the rest of the tab’s life and is reused for every subsequent image in the same language, so a batch of thirty photos pays the setup cost once. Switching to a different language on a later run shuts the old worker down and starts a new one with the new model, which means the wait comes back. Cancelling mid-run terminates the worker outright and clears the tool, so the next attempt starts from scratch.
Handwriting, small captures and multi-column pages
Three situations account for most disappointing results.
Handwriting is the first, and there is no gentle way to put it: the models are trained on printed and rendered type, so cursive is largely out of reach and even careful block capitals are unreliable. Second is resolution. Recognition works on the pixels that make up each character, so text that occupies eight pixels of height has very little shape left to identify, and enlarging the image afterwards adds no information the capture did not contain. Screenshot at a higher zoom level, or photograph closer, rather than scaling up later.
Third is layout. The engine segments the page before reading it, and a newspaper-style two-column page, a form with boxes, or a table with narrow columns can be segmented in an order that makes the output read strangely even when every individual word is correct. Nothing is wrong with the recognition; the reading order is the part that failed.
Plain text out, and what that leaves behind
This tool asks the engine for the recognised text and nothing else. It does not request per-word coordinates, confidence scores or block structure, so what lands in the .txt file is a stream of lines with no positional information attached. That is the right output for pasting into a document, searching, translating or feeding to something else, and it is the wrong output if you needed to know where on the page each word sat.
Once you have the text, Word Counter gives you the length and reading time, and the wider text tools hub covers cleaning, converting and reformatting it. If the picture contains a QR code rather than words, QR Code Reader decodes that instead.
When the source is a scanned PDF
Converting PDF pages to images and running them through here works, but it throws away the thing that usually makes a scanned document useful, which is the document itself. OCR PDF takes the opposite approach: it rasterises each page, recognises the words with their positions, and writes an invisible text layer back over the original page image, so the file still looks exactly like the scan while becoming searchable and selectable.
Use this page for screenshots and photographs, where a plain transcript is what you were after. Use the PDF route when the output has to remain a document. The rest of the image toolkit is on the image tools hub.