Tools › Guides › Why OCR gets things wrong, and how to get better results
Why OCR gets things wrong, and how to get better results
Text recognition accuracy is decided mostly before the tool runs. Resolution, contrast and skew matter more than which engine you use. Here is what to fix and what to expect.
Accuracy is set by the image, not the engine
Swapping OCR engines changes results at the margin. Changing the picture changes them completely.
A clean 300 DPI scan of printed text runs at around 99% character accuracy on any competent engine. A photograph of the same page taken at an angle in poor light can drop to 70%, which sounds survivable and is not: at 70%, roughly one word in three has something wrong with it, and the output is faster to retype than to correct.
So the useful work is nearly all in the input.
Resolution: 300 DPI, and why
The rule of thumb OCR engines are built around is at least 20 pixels of height per character: ideally 30.
For 10-point text that works out at about 300 DPI. Below roughly 150 DPI the strokes that distinguish similar letters stop being resolvable and accuracy falls off a cliff rather than degrading gently.
Going much above 300 does not help and slows everything down. 400 is worthwhile for small print: footnotes, terms and conditions, dense tables. 600 is for damaged originals.
If you are photographing rather than scanning: fill the frame with the page. A page occupying a quarter of a 12-megapixel photo is about 100 DPI, which is not enough, and no amount of upscaling afterwards puts the strokes back.
The other things that matter, in order
Contrast. Black on white is what engines are tuned for. Grey on beige, text over a photograph, or a page shot through a shadow all lose accuracy. Increasing contrast before recognition genuinely helps: this is one of the few preprocessing steps that reliably does.
Skew. Most engines assume text lines are horizontal. A page rotated by more than a couple of degrees degrades noticeably, and one rotated by ten can fail entirely. Straightening first is worth more than any setting.
Focus. Motion blur and misfocus destroy the fine strokes that separate rn from m, l from 1, and 8 from B. There is no recovering from this; retake the photograph.
Even lighting. A gradient across the page: one side bright, the other in shadow, breaks the threshold between ink and paper. Diffuse light beats a bright lamp at an angle.
Flatness. A book photographed open curves away at the spine, and the text near it is both distorted and out of focus. Pressing the page flat, or scanning, is the fix.
What OCR is reliably bad at
Worth knowing so you check the right things:
0/Oand1/l/I. Context usually saves it in words and never
saves it in serial numbers, licence keys or account numbers. Always verify those by eye.
- Tables. Recognising the characters is the easy half; reconstructing
which cell they belong to is a different problem and most engines do it poorly.
- Multiple columns. Without layout analysis, a two-column page is read
straight across and comes out interleaved.
- Handwriting. A different problem from printed OCR. Print recognition
engines produce confident rubbish on it.
- Unusual faces. Blackletter, script faces, heavy stylisation, and very
condensed type are all far outside the training distribution.
- Watermarks and stamps crossing the text confuse the ink/paper decision
exactly where the text is.
Language matters more than people expect
Telling the engine which language it is reading is not a formality. It selects the character set and, more importantly, the dictionary used to resolve ambiguity. Recognising French text as English throws away every accent and makes worse guesses on the rest.
For mixed-language documents, pick the dominant one. For anything with a different script (Greek, Cyrillic, Arabic, CJK) the right data has to be loaded or the result is meaningless rather than merely wrong.
Running it in the browser
OCR is CPU work on an image, which is the kind of thing a browser is genuinely good at. The engine and its language data are a download of a few megabytes, cached afterwards.
The trade is a few seconds per page against your own processor instead of a server's, and in return the document is never transmitted. Given that the things people OCR are overwhelmingly bank statements, contracts, invoices, letters and ID documents, that is not a small consideration.
Expectations worth setting
- Clean printed scan at 300 DPI: 98–99%+. Usable with a proofread.
- Good phone photo of a printed page: 90–97%. Usable, needs checking.
- Poor photo, angled, dim, low resolution: 60–85%. Faster to retype.
- Handwriting: do not.
If you are getting a bad result, retake the picture before trying another tool. It is almost always the picture.