12 Ways to Improve OCR Accuracy on Difficult Images
July 2026 • 10 min read
When OCR returns garbage, the instinct is to blame the engine. Almost always the problem is the image. OCR engines are pattern matchers working on pixels, and they are excellent at clean input and hopeless at ambiguous input. These twelve fixes are ordered roughly by how much difference they make, so start at the top.
1. Give it enough pixels per character
This is by far the biggest lever, and the one people most often get wrong. What matters is not the megapixel count of the photo but how many pixels tall each letter is. Below roughly 20 pixels of cap height, accuracy falls off a cliff; around 30–40 pixels, most engines are comfortable.
For scanned documents, 300 DPI is the standard recommendation and it exists for this reason. For a phone photo, this translates to filling the frame with the text rather than capturing the whole page from a distance. A 12-megapixel photo of a whole noticeboard gives each letter fewer pixels than a modest photo of one paragraph.
Note the asymmetry: you cannot fix this after the fact. Upscaling a small image invents pixels rather than recovering detail, and OCR is not fooled by invented detail.
2. Crop to just the text
Cropping helps in two independent ways. It removes distracting content that the layout analyser might misread as text, and it means processing effort goes entirely into the region you care about.
It also solves a specific and frustrating failure: when a page has both text and photographs, the engine sometimes tries to interpret texture in the photo as characters, producing random strings interleaved with your real text. Cropping the photo out removes the problem entirely.
3. Straighten the text
OCR reads along horizontal lines. Most engines tolerate a couple of degrees of skew and start degrading beyond about five. Rotation from photographing a page at an angle is the usual culprit.
Worse than plain rotation is perspective distortion — photographing a page from an angle so the far edge is narrower than the near one. Letters change size across the image and lines curve, which breaks line detection. Shoot straight down over the page, or use a phone's document-scan mode, which corrects perspective automatically.
4. Maximise contrast, not brightness
OCR wants a clear separation between ink and paper. Dark text on light background is the ideal. Faded receipts, pencil, and low-contrast grey-on-grey design all suffer.
Raising contrast usually helps far more than raising brightness — brightening a faded scan lifts the paper and the ink together and changes nothing useful. If your editor has a levels or curves control, pulling the black point up and the white point down until text is nearly black and paper nearly white is the single most effective preprocessing step available.
5. Convert to greyscale before thresholding
Engines binarise internally — reducing everything to black and white — and they make better decisions from a clean greyscale image than from a colour one, especially when text and background are different hues of similar lightness. Red text on a green background can look nearly identical in brightness terms and confuse the split. Converting to greyscale yourself lets you check that the text is still clearly darker than the background before the engine has to guess.
6. Fix uneven lighting
A photo of a page under a desk lamp is bright on one side and shadowed on the other. A single global threshold cannot serve both regions: it either loses the text in the shadow or floods the bright side.
The best fix is at capture time — diffuse, even light, and no shadow from your own hand or phone. Failing that, a shadow/highlight adjustment or a "flatten background" filter evens things out. Curved pages from a thick bound book have the same problem plus geometric distortion near the spine; photograph one page at a time, pressed flat.
7. Set the correct language
OCR does not merely recognise shapes; it uses language models to resolve ambiguity. With the wrong language selected, the engine's expectations actively work against you.
This matters most for accented and non-Latin scripts. Vietnamese diacritics, German umlauts and Polish diacritics will be dropped or mangled if the engine expects plain English. For genuinely mixed-language documents, running the image twice with different language settings and combining the results often beats one pass with a multi-language model.
8. Prefer screenshots to photos of screens
If the text is on a screen, capture it digitally. A screenshot gives perfect pixels, perfect contrast and no distortion, and OCR on a screenshot is near-flawless.
Photographing a monitor adds moiré interference patterns from the camera sensor beating against the pixel grid, reflections, screen glare and rolling-shutter banding. It is the hardest possible input, and it is entirely avoidable.
9. Handle columns and tables deliberately
Layout analysis is a separate problem from character recognition, and it is where otherwise-good OCR results become unusable. A two-column page may be read straight across, interleaving both columns into nonsense sentences. Tables lose their structure, and once rows and columns are flattened into a single stream, a table of numbers is worthless.
The reliable workaround is to crop each column or region and run it separately. It is more steps, but it preserves reading order, and for anything financial or numerical that reliability is worth far more than the convenience of one pass.
10. Accept that some fonts will fail
Engines are trained mostly on ordinary printed text. Reliably difficult cases include script and handwriting-imitation fonts, heavy condensed or stretched type, all-caps set with tight letter spacing, decorative display faces, and text with effects like outlines, drop shadows or gradients over it.
Also expect confusion between genuinely similar glyphs: 0/O, 1/l/I, 5/S, rn/m. These are not laziness on the engine's part — in many typefaces the shapes really are near-identical, and only context distinguishes them. If you are extracting serial numbers or codes where context cannot help, plan to verify by eye.
11. Remove background interference
Watermarks, decorative patterns, ruled lines, stamps and coffee stains all get read as potential characters. Table borders in particular often become stray pipes and dashes in the output.
If you are photographing a document, place it on a plain surface that contrasts with the paper, so the page boundary is unambiguous. A white page on a white desk gives the engine no clue where the document ends.
12. Know when to stop
Some images are not worth rescuing. A blurry photo of a faded receipt in a decorative font will consume twenty minutes of preprocessing and still produce text you have to proofread word by word. Retyping forty characters takes a minute.
A useful threshold: if the first pass is below roughly 80% correct, re-capturing the image properly will nearly always beat trying to clean up the one you have. If you cannot re-capture it and the text is short, type it. OCR is a tool for saving time, and it is worth noticing when it has stopped doing that.
A quick pre-flight checklist
- Are letters at least ~25 pixels tall?
- Is the image cropped to just the text?
- Are the lines horizontal, with no perspective skew?
- Is the text clearly darker than the background?
- Is the lighting even, with no shadow across the page?
- Is the correct language selected?
- Is this a screenshot rather than a photo of a screen?
- Have multi-column or tabular regions been separated?
Eight yeses will get you a clean extraction from almost any ordinary document. Most bad OCR results fail two or three of these, and fixing them takes less time than proofreading the mess.
Put it into practice
Our Image to Text tool runs OCR entirely in your browser, so you can iterate freely — crop, adjust, retry — without uploading sensitive documents to anyone's server. That matters when the thing you are digitising is a medical record or a contract rather than a book page.
