What OCR Is Actually Good For, and How to Get Cleaner Results
Optical character recognition has quietly become one of those utilities you reach for several times a week once you know it is there. The AI OCR tool runs a WebAssembly build of the Tesseract engine inside your browser tab, which means a payslip or a medical letter can be turned into editable text without ever being uploaded. This article covers where OCR pays off and how to feed it images it can actually read. For the click-by-click version, see How to Extract Text from Any Image.
Where OCR earns its keep
The obvious case is a scanned document, but the everyday wins are smaller and more frequent than that.
- Receipts and invoices. Pull the vendor, date and total out of a photographed receipt instead of retyping it into an expense sheet. Numbers are the part you should always proofread, but the surrounding text saves the bulk of the typing.
- Whiteboards and printed notes. A photo of a meeting whiteboard is unsearchable. A text file of the same content is greppable, pasteable and takes up almost no space.
- Screenshots of error messages. Stack traces and error codes are miserable to retype and impossible to search from an image. OCR turns them back into something you can paste into a search box or a bug report.
- Book and article pages. Photograph a paragraph you want to quote, extract it, then check it against the page rather than transcribing by hand.
- Business cards, labels and serial plates. Anything short, printed and awkwardly placed for typing.
- Accessibility. Text trapped in an image is invisible to screen readers. Extracting it gives you the raw material for a proper alt attribute or caption.
How the engine reads a page
Modern OCR is not template matching against letter shapes. The image is first converted to a clean black-and-white version, then analysed for layout: blocks of text, then lines, then words. Each text line is fed through a neural recognizer that reads it as a sequence rather than as isolated glyphs, and a language model nudges ambiguous characters towards plausible words. That last stage is why choosing the right language in the dropdown matters. English, Spanish, French and German are available, and the matching training data is fetched the first time you use it, which is why the first extraction takes noticeably longer than the ones after it.
Sequence recognition cuts both ways. The language model is what lets the engine correctly read a smudged word in a sentence. It is also why a serial number, licence key or product code can come back subtly wrong: there is no dictionary to fall back on, so every character is decided on pixels alone. Always verify codes character by character.
Capture habits that beat any setting
Recognition quality is decided long before you press the extract button. In rough order of impact:
- Resolution. Small text is the single biggest cause of garbage output. If the lowercase letters are only a handful of pixels tall, no engine will read them reliably. Photograph closer or scan larger rather than upscaling afterwards.
- Even lighting. A shadow gradient across a page pushes half of it towards grey and breaks the black-and-white conversion. Diffuse light beats a bright lamp at an angle.
- Square-on framing. Text photographed at an angle arrives as trapezoids. The Perspective Straightener can flatten a photographed page before you run OCR on it.
- Tight cropping. Remove the desk, the hand and the facing page with the Image Cropper so the layout analysis only has one column of text to reason about.
- Contrast, not saturation. Dark text on a light background is what the engine expects. If your source is low contrast, boost it before extraction rather than hoping the engine compensates.
- Avoid heavy compression. A JPEG saved at low quality smears the edges of every character with ringing artifacts. Screenshots are best kept as PNG.
What OCR still struggles with
Setting expectations saves time. Cursive handwriting is largely out of reach, and even neat printing by hand is hit and miss. Decorative, condensed and script fonts confuse the recognizer. Text laid over a photograph or a gradient loses the contrast the binarisation step depends on. Tables usually survive as text but lose their column structure, so expect to rebuild the layout yourself. Rotated, curved or vertical text needs to be straightened first. And a watermark printed across a paragraph will contaminate the characters it crosses.
When you proofread, the confusions are predictable: zero against capital O, the digit one against lowercase l and capital I, five against S, and the pair "rn" reading as "m". In anything financial, check decimal points and thousands separators specifically.
Why doing it locally matters here
The documents people most want to digitise are exactly the ones they should be least willing to upload: bank statements, tax paperwork, insurance forms, prescriptions, contracts. Running the recognizer in your own browser removes that tradeoff entirely - the file is read from disk into a canvas and never sent anywhere. It also means the extracted text does not sit in someone else's processing log.
Two follow-up steps are worth knowing about. If you are sharing the source screenshot as well as the text, cover the sensitive fields first; the article on choosing a redaction method explains why a solid block beats a light blur for anything guessable. And if you photographed a document with your phone, the image still carries location and device data, which is what the piece on what EXIF data reveals is about.