OCR Accuracy: The Seven Things That Actually Affect It

People tend to think of OCR quality as a property of the software. It is much more a property of the input. The same engine, on the same page, can go from near-perfect to unusable based on decisions made before the document ever reached it.

1. Resolution

300 DPI is the sweet spot for standard body text. Below 200 DPI, character strokes merge and the classic confusions appear: rn reads as m, cl reads as d, 0 reads as O. Above 400 DPI you gain almost nothing and pay in processing time. If you control the scanner, set it to 300 and stop thinking about it.

2. Contrast and lighting

Phone photos of documents fail more often than scans, and it is almost always lighting. A shadow across the page from your own hand shifts the local threshold and swallows a whole column. Shoot in even, indirect light, or use a scanning mode that flattens and thresholds per-region.

3. Skew

Even two or three degrees of rotation hurts, because line-detection assumes horizontal baselines. Most engines deskew automatically, but they do it better when the page edges are visible — so do not crop tightly before OCR.

4. The font itself

Standard serif and sans-serif body faces are what engines are trained on. Condensed fonts, decorative headers, and anything below 8pt are materially worse. Handwriting is a different problem entirely and needs a handwriting model, not a print OCR model.

5. Language selection

OCR uses a language model to resolve ambiguous glyphs. Running a French document through an English model produces confident, plausible, wrong words — accented characters get silently normalised away. Always set the language, and for genuinely bilingual documents, run each language over the relevant pages separately.

6. Layout complexity

Multi-column layouts, sidebars, footnotes and tables are where OCR output becomes technically accurate but practically useless: every character is right, but the reading order interleaves two columns into nonsense. If you care about downstream text, check the reading order before you check the spelling.

7. Prior compression

A scan that has already been aggressively JPEG-compressed carries ringing artefacts around every character edge. The engine sees those artefacts as ink. This is the single most common cause of 'the scan looks fine to me but OCR is terrible' — your eye corrects for the artefacts and the algorithm does not.

A realistic quality checklist

• Scan or photograph at 300 DPI equivalent, in even light.
• Keep the page flat and roughly square to the sensor.
• Do not compress before OCR. Compress after.
• Set the correct language.
• Spot-check numbers first — digits have no dictionary to fall back on and fail silently.

How to verify without reading everything

Search the OCR'd document for three words you know appear in it, including one that is unusual. Then search for a number you can verify. If all four hit, the page is broadly sound. If the unusual word misses, the engine is guessing from its dictionary, and you should treat every proper noun in the document as suspect.

A worked example: taking a bad scan from unusable to usable

Consider a photographed page of a contract, taken on a phone under a ceiling light, slightly skewed, at roughly 180 DPI equivalent resolution once cropped. Run through OCR as-is, this kind of page commonly produces garbled output in the first and last few words of every line, where the perspective distortion is worst, while the center of the page reads acceptably.

1. Re-shoot or re-scan rather than trying to fix the existing image; no amount of downstream processing recovers detail that was never captured, and this is the step people skip because it feels like starting over.
2. If a re-shoot is not possible, apply perspective correction first so the page edges become parallel to the image edges — this alone fixes a large share of the line-start and line-end garbling, because it restores a consistent baseline.
3. Increase local contrast or apply adaptive thresholding rather than a single global brightness adjustment, since a single overhead light source creates a brightness gradient across the page that a global adjustment cannot correct.
4. Deskew explicitly if the automated deskew in your OCR pipeline is not confident — most engines report a skew-correction confidence value, and a low one is a signal to intervene manually before proceeding.
5. Re-run OCR with the language explicitly set, then spot-check five specific tokens: two proper nouns, one number, one date, and one uncommon word, rather than reading the whole page.

Accuracy ranges by input condition

These ranges describe general tendencies observed across typical office and scanning conditions, not a guarantee for any specific engine or document.

• Clean flatbed scan, 300 DPI, standard sans-serif body text, single column: character accuracy is typically very high, with most errors confined to unusual proper nouns and non-standard punctuation.
• Same conditions but at 150 DPI: noticeably more character-level substitution errors, particularly among characters with similar strokes such as e/c, 1/l/I, and 5/S.
• Phone photo, good lighting, minimal skew: close to scanner quality once perspective-corrected, but font rendering artifacts from the camera sensor introduce more noise than a flatbed scan at the same nominal resolution.
• Phone photo, poor lighting or visible shadow: accuracy degrades unevenly across the page rather than uniformly, which is a distinguishing signature of a lighting problem versus a resolution problem.
• Multi-column academic paper or newspaper layout, correct resolution and lighting: character accuracy remains high but reading-order errors become the dominant source of unusable output, not spelling errors.

Common mistakes in OCR workflows

• Running the entire document through a single default language model without checking whether it contains mixed-language content, such as an English report with a French appendix.
• Treating OCR confidence scores as a proxy for correctness rather than for legibility; an engine can be highly confident about a wrong word if the wrong word is a common dictionary word that resembles the actual ink shapes.
• OCR-ing a document that has already been through a fax transmission or multiple photocopy generations, where each generation adds its own noise pattern on top of the last.
• Ignoring rotated or upside-down pages mixed into an otherwise upright scan set — most engines handle 90-degree and 180-degree rotation detection, but confirm rather than assume for legacy scan batches.

Troubleshooting persistent errors

Numbers are systematically wrong

Digits have no dictionary to fall back on, so an engine that is otherwise 98% accurate on prose text can still misread a meaningful share of numeric strings, especially in tables where digits are tightly kerned. Treat every number in an OCR'd financial or legal document as needing independent verification; this is not a tuning problem, it is an inherent limitation of dictionary-assisted recognition.

Whole paragraphs are missing

This usually indicates a layout-analysis failure rather than a character-recognition failure — the engine did not identify that region as text at all, which commonly happens with text set over a colored or textured background, text inside a table cell with tight borders, or text rendered as a low-contrast watermark-style overlay.

Output text is right but unusable

If every word is correct but paragraphs read in the wrong order, the fault is in reading-order reconstruction, not recognition. This is common with multi-column layouts and text boxes. Some pipelines let you define column boundaries manually before OCR, which resolves it directly rather than requiring post-processing cleanup of the output text.

Edge cases

• Tables with merged cells: OCR often duplicates or drops values because the underlying layout analysis assumes a regular grid.
• Stamped or handwritten annotations over printed text: the two require different recognition models, and running one model over both usually sacrifices accuracy on whichever content type the model was not built for.
• Right-to-left languages mixed with left-to-right numerals or Latin text: reading-order reconstruction needs to be aware of the mixed directionality or numbers and dates will be transposed.
• Very old or degraded documents with faded ink: increasing contrast can help, but past a certain degradation point no amount of preprocessing recovers strokes that are physically gone from the page.

Reference points worth knowing

Most modern OCR engines are built on either an LSTM-based recognition architecture, as used by the open-source Tesseract engine from version 4 onward, or a broader deep-learning layout-and-recognition pipeline. Searchable OCR output layered invisibly under a scanned image, so that the image is what a person sees while the underlying text is what a search or copy operation retrieves, is stored as a standard PDF text layer defined by the ISO 32000-2 PDF specification — the same content stream and font mechanism used by any other PDF text, just positioned to be invisible or matched exactly to the visible glyphs.

When OCR is not the right tool

If the source document exists as an editable file anywhere — the original word processor file, the original spreadsheet, the original design file — retrieving or requesting that file will always beat OCR-ing a rendered or printed version of it, because OCR is fundamentally a reconstruction of information that has already been lost once through rasterization. Do not use general print OCR on handwriting, sheet music, or mathematical notation; each of those needs a purpose-built recognition model, and forcing a print-text engine onto them produces confident nonsense rather than a clear failure you would notice and route around.