Why OCR gets it wrong, and how to get better results

When recognition output is disappointing, the instinct is to look for a better engine. Almost always the bigger gains are upstream, in the image the engine was given.

The factors that dominate accuracy

Resolution

Recognition needs enough pixels per character to distinguish similar shapes. The classic confusions — 0/O, 1/l/I, rn/m, cl/d — are decided by a handful of pixels.

For 10–12 point text, 300 DPI gives roughly 30–40 pixels of character height, which is comfortable. At 150 DPI you have half that and error rates climb noticeably. Below 100 DPI, results are unusable for anything but headlines.

Upscaling a low-resolution scan does not help. Interpolation invents smooth pixels; it does not recover detail that was never captured. Rescan if you can.

Contrast

Recognition depends on a clean separation between ink and paper. What breaks it:

• Grey or coloured paper, which narrows the gap.
• Faded print, carbon copies, thermal receipts.
• Photographs where one side of the page is lit and the other is in shadow — a single global threshold cannot suit both.
• Show-through from double-sided printing, which adds ghost marks that get segmented as characters.

Scan in greyscale, not in the scanner's black-and-white mode. Greyscale keeps the intermediate tones so thresholding can be done well later; the scanner's own bilevel mode makes an irreversible decision in hardware.

Straightness

Segmentation cuts text into lines by looking for horizontal bands of ink. A page rotated by even two or three degrees smears those bands together, and accuracy drops before any character is examined.

Most engines deskew automatically, but they work better when there is less to correct. Align pages in the feeder; when photographing, hold the phone parallel to the sheet rather than at an angle — perspective distortion makes text larger at one edge than the other, which deskewing cannot fix.

If a page is flat-out sideways, correct it with Rotate PDF before recognition.

Language selection

The language model resolves ambiguity between visually similar characters. Running an English model over a French document produces a specific and recognisable failure: accented characters mangled, and correctly-shaped words "corrected" into wrong English ones. Select the actual language of the document. For genuinely mixed-language pages, run the dominant language and proofread the rest.

The paper itself

Staple holes, punch holes, coffee rings, highlighter (which reduces contrast in exactly the passage you care about), handwritten annotations over print, and folds that cast shadow lines — all of these generate spurious characters. Cropping away a damaged margin with Crop PDF before recognition is often quicker than cleaning up the output.

Difficult layouts

Multi-column pages

The engine must decide whether a line of text continues across the gutter or stops at the column edge. When it decides wrongly, you get sentences interleaved from two columns — text that is individually accurate and collectively meaningless.

If the output is scrambled this way, the fix is to recognise each column separately: crop the page to one column, recognise, then repeat. Tedious, but reliable.

Tables

Most engines return the text within a table but not its structure. Cells come out as a stream of values, and reconstructing which value belongs to which row and column is left to you.

Two things help. Tables with full ruling lines fare better than tables separated by whitespace, because the lines give layout analysis a real boundary to find. And recognising a table region on its own, cropped away from surrounding prose, avoids the engine merging table rows into the body text.

For a table you actually need as data, accept that transcription may be faster than correcting a mangled recognition.

Forms

Printed labels recognise well; handwritten entries usually do not. Checkbox states are not recognised at all — a tick is just a mark. Treat form OCR as making the blank structure searchable, not as data capture.

Small print

Footnotes, legal fine print and reference lists are often several points smaller than body text. If they matter, scan the whole page at 400–600 DPI rather than accepting a good body result and a bad footnote result.

Checking the result

Recognition errors are frequently plausible, which makes them dangerous. A misread digit in an invoice total or a date is not visibly wrong.

• Search the searchable PDF for three or four distinctive words you can see on the page. Failures cluster, so a couple of hits gives reasonable confidence.
• Pay specific attention to numbers, reference codes and names — these have no dictionary support, so the language model cannot rescue them, and they are exactly the fields people rely on.
• For anything consequential, remember the visible page image is unchanged and remains the authoritative copy. That is a feature of searchable PDFs, not a workaround.

A capture checklist

1. 300 DPI, greyscale.
2. Flat page, aligned, no shadow across the sheet.
3. Crop away damaged or empty margins.
4. Correct rotation before recognising.
5. Select the document's actual language.
6. Recognise complex columns and tables as separate crops.
7. Spot-check numbers and names in the output.

For turning a large stack of paper into a usable archive, see paper to searchable archive.