Extract Text From an Image
Reads printed text out of a photograph, screenshot, or scan using optical character recognition that runs on your own device rather than a server. The engine is about nine megabytes and is downloaded only when you press the button, then cached — so the first run is slow and every one after it is not. A confidence score comes back with the text, so you know how carefully to check it.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Optical character recognition entirely on-device
- Confidence score with a warning when it is low
- Engine and language model served from this site
- Nothing downloaded until you ask for recognition
- Copy the result or save it as a .txt file
How to use Image to Text (OCR)
- 1
Choose an image
Drop in a photo, screenshot, or scan containing printed text. Straight-on, evenly lit images work considerably better than angled ones.
- 2
Press Read the text
The first run downloads the recognition engine and the English model, roughly nine megabytes. Nothing is fetched before you press it.
- 3
Check the confidence
A score below about 70 percent means the result needs proofreading. The tool says so explicitly rather than leaving you to guess.
- 4
Copy or download
Take the text to your clipboard, or save it as a plain .txt file.
How it works
Optical character recognition is several steps, and knowing them explains why some images work and others do not.
The image is first converted to a clean black-and-white version, because the engine works on shapes rather than colors. Then it is analyzed for layout — finding text blocks, then lines within blocks, then words within lines, and finally individual character shapes. Each character shape is fed to a neural network trained on printed type, which returns the most likely letter and a confidence. Finally a language model corrects unlikely sequences, which is why "rn" is usually not misread as "m" in a real word.
Everything above runs in WebAssembly inside this tab. The engine is a compiled build of Tesseract, the long-standing open-source OCR system, and the language model is its English training data. Both are served from this site rather than from a content delivery network, which is a deliberate choice: this site tells you your files never leave your device, and fetching the engine from a third party the moment you press the button would undercut that even though no image is being sent anywhere.
Every step depends on the earlier ones. If the binarisation loses faint text, nothing downstream can recover it. If the line-finding stage misreads a skewed page, characters are sampled at the wrong angle. This is why photograph quality dominates results so completely, and why no software setting substitutes for taking a better picture.
When you'd use this
Getting text out of a screenshot, which is the case OCR handles almost perfectly. Error messages, chat excerpts, and anything captured from a screen where the text cannot be selected.
Photographs of printed documents — a letter, a form, a page of a book — where retyping is the alternative.
Scanned PDFs, indirectly. A scanned document has no text layer, so a text extractor finds nothing. Converting a page to an image and running it through here is the route to its contents.
Whiteboards and slides after a meeting, where printed or neatly written text is usually recoverable and handwriting usually is not.
What to expect, honestly
Screenshots and clean scans: very good, typically above 90 percent confidence, usually needing no correction beyond the odd punctuation mark.
Straight, well-lit photographs of printed pages: good, with occasional errors in numbers, unusual names, and anything in an unusual typeface.
Angled, dim, or low-resolution photographs: unreliable, and the confidence score will say so.
Handwriting: not supported in any practical sense.
Tables, multi-column layouts, and text over images: the characters are often recognized correctly while their arrangement is lost, because reading order is a layout problem rather than a recognition one.
The confidence score exists so that you do not have to work out which of these categories you are in by proofreading. If it is high, skim it. If it is low, read it against the original.
Examples
A screenshot of an error message
Screenshots are the easiest case by a wide margin. The text is pixel-perfect, evenly lit, perfectly straight, and rendered in an ordinary typeface — every condition that recognition depends on. This is where OCR is genuinely reliable rather than merely useful.
A receipt photographed at an angle
61 percent is the tool telling you not to trust the numbers without checking them. The causes here are geometric rather than technical: the receipt is skewed, the thermal print is faint, and the top of the image is brighter than the bottom. Re-photographing straight on in even light lifts this far more than any software setting.
Frequently asked questions
Why is the first run so slow?
Because it downloads a recognition engine of about 6.5 megabytes and an English language model of another 2.8. That is what OCR costs to do locally, and there is no smaller honest version of it. Everything is cached permanently afterwards, so the second and every later run start immediately. Nothing is downloaded until you press the button.
Does it work on handwriting?
Not usefully. This engine is trained on printed type, and handwriting recognition is a genuinely different problem that needs different models. You will get output from a handwritten image, but it will be mostly wrong. Neat block capitals sometimes work; ordinary cursive does not.
How do I get better results?
Improve the photograph rather than the settings. Shoot straight on rather than at an angle, get even lighting with no shadow across the page, fill the frame with the text, and hold still enough to avoid blur. A crisp 1000 pixel-wide image of a paragraph beats a blurry 4000 pixel one. Cropping to just the text before running it also helps.
What does the confidence score actually mean?
It is the engine's own average certainty across the characters it recognized, not an accuracy measurement. Above about 90 percent the output is usually clean. Between 70 and 90 expect scattered errors, particularly in numbers and punctuation. Below 70 the result needs reading against the original rather than trusting.
Is my image uploaded to be recognized?
No, and this is the main reason to use a local OCR tool. The engine, the language model, and the worker are all served from this site, and the recognition happens inside this browser tab. Nothing is transmitted at any point. That matters because the things people photograph to extract text from are receipts, letters, medical documents, forms, and whiteboards after meetings.
Further reading
- OCR Recovered Every Character Flattening Had RemovedA flattened PDF has no text layer, which is often described as the text being lost. It is not lost, it is only no longer written down — the words are still drawn on the page, and reading them off a picture is exactly what OCR does.
- JPEG Compression Made No Difference to OCR Accuracy At AllScanning guides tell you to save as TIFF or PNG because JPEG artifacts confuse OCR. It sounds obviously right — lossy compression smears exactly the hard edges that letter recognition depends on. We measured it across a wide range of quality settings and found no difference whatsoever, which changes the storage arithmetic for anyone digitising a lot of paper.
- OCR Reads Nothing at 72 DPI and Everything at 150The standard advice for scanning documents you intend to run through OCR is 300 DPI. We measured where the accuracy actually changes, and it is not a gentle curve with 300 comfortably on the good end. It is a cliff between 96 and 150, and everything above 150 was identical.