OCR Language Support and Accuracy

OCR accuracy is quoted in marketing material as a single number — 99%, 99.5% — and that number is close to meaningless without knowing the language, the script, the scan quality, and what counts as an error. A 99% character accuracy rate means roughly one wrong character every two lines, which in a page of prose is a nuisance and in a page of account numbers is a disaster. This covers what actually drives accuracy, how language support varies, and how to get better results from the same documents.

What drives accuracy, in order of impact

1. Scan quality. By a wide margin the dominant factor. 300 dpi is the threshold below which accuracy falls off a cliff, because OCR engines need roughly 20–30 pixels of lowercase letter height to work reliably — the arithmetic is in scanning resolution and DPI for documents. Skew, low contrast, JPEG artefacts, show-through from the reverse side and shadows near the binding all cost accuracy directly.

2. Typeface and print quality. Clean modern typography scans beautifully. A degraded photocopy, a dot-matrix printout, a nineteenth-century Fraktur type, or a decorative display face are all substantially harder. Condensed fonts with tight letter spacing produce the most common error class: adjacent characters merged into one, or one wide character split into two.

3. Layout complexity. Multi-column text, tables, sidebars, figures with captions, and forms with rules and boxes all require the engine to segment the page correctly before recognising anything. Segmentation errors are worse than character errors because they scramble the reading order — a paragraph of correctly recognised text in the wrong place. See reading order in tagged PDFs for why order matters downstream.

4. Language and script. Covered below.

5. The engine. Real differences exist, but they are smaller than differences 1 to 3. A good engine on a bad scan loses to a mediocre engine on a good scan, every time.

Language support in practice

Tesseract, the dominant open-source engine, ships trained data for over 100 languages. Quality varies enormously across that list:

• Excellent: English, German, French, Spanish, Italian, Portuguese, Dutch, and most Latin-script European languages with large training corpora.
• Good: Russian and other Cyrillic scripts, Greek, Turkish, Polish, Czech, and the Nordic languages.
• Variable: Arabic and Hebrew, where right-to-left rendering, cursive joining and optional diacritics make the problem structurally harder. Arabic in particular remains substantially less accurate than Latin scripts on comparable scans.
• Specialised: Chinese, Japanese and Korean need their own models and generally different tooling; character sets in the thousands change the problem entirely. Japanese with mixed vertical and horizontal text is among the hardest common cases.
• Thin: many South Asian, African and minority-language scripts have models that exist but are trained on far less data.

Two practical points that make a large difference:

Specify the language. tesseract input.tif output -l deu for German. Running the default English model on a German document produces markedly worse results, because the language model that corrects ambiguous characters is doing the wrong job. The single most common misconfiguration in OCR pipelines is leaving the language at the default.

Specify multiple languages when the document is mixed: -l eng+fra. This costs some accuracy on each but handles the bilingual documents that are common in Canada, Switzerland, Belgium and the EU institutions.

Commercial engines — ABBYY FineReader, Adobe's OCR, Google Cloud Vision, Amazon Textract, Microsoft Azure AI Document Intelligence — generally have broader and better language coverage, particularly for non-Latin scripts and for handwriting. ABBYY has historically led on European languages and on layout retention; the cloud services lead on scale and on structured extraction. This is a real reason to look past the free option for non-English archives at volume.

Character accuracy versus word accuracy versus useful accuracy

Three different measures, frequently conflated.

Character accuracy counts individual characters. 99% sounds excellent and means about 25 errors per page of ordinary prose.

Word accuracy counts whole words. It is always lower — a single wrong character breaks the word — and it is closer to what matters for search, because a misrecognised word simply will not be found.

Task accuracy is the one that counts and is rarely measured: does the output serve the purpose? For full-text search of a research archive, 95% word accuracy is genuinely useful, because you are looking for documents and enough words survive. For extracting invoice totals into an accounting system, 99.9% is not good enough, because the one wrong figure per thousand enters the ledger with the same confidence as the rest.

That distinction should drive your process design. Search-grade OCR can be automated and left alone; data-extraction OCR needs validation, whether by checksum, cross-field arithmetic, or human review.

Getting better results from the same document

Preprocessing before recognition is where most of the available improvement lives:

• Deskew. A page rotated even 1–2° costs measurable accuracy. ocrmypdf --deskew handles it, and most scanner drivers do it in hardware.
• Rotate correctly. A sideways page recognises as noise. ocrmypdf --rotate-pages detects and fixes orientation.
• Increase contrast and remove background. Scanning in greyscale and thresholding well beats scanning bilevel and hoping.
• Remove speckle. --clean in OCRmyPDF (via unpaper) removes scan noise that the engine would otherwise try to recognise.
• Crop out the furniture. Page edges, punch holes and binding shadows generate spurious characters.
• Rescan if you can. Ten minutes rescanning at 400 dpi greyscale beats hours of post-processing a 150 dpi bilevel scan.

A reasonable default command:

ocrmypdf --deskew --rotate-pages --clean -l eng+deu input.pdf output.pdf

More on the surrounding workflow in PDF OCR explained and how to make a PDF searchable with OCR.

Where the errors cluster

Knowing the common confusions makes proofreading efficient, because errors are not uniformly distributed:

• rn read as m, and vice versa. The single most common Latin-script error.
• 1 / l / I, and 0 / O — especially in sans-serif faces where the shapes genuinely are near-identical.
• 5 / S, 8 / B, 6 / G in degraded scans.
• Hyphenated line breaks kept as literal hyphens, splitting words in the extracted text.
• Punctuation invented or lost: full stops from specks, commas read as full stops.
• Diacritics dropped when the language was not specified.
• Numbers in tables, where the surrounding rules confuse segmentation and where the language model cannot help — a language model corrects "recieve" to "receive" but has no opinion about whether a figure is 1,234 or 1,284.

The practical rule: numbers are where OCR is least reliable and most consequential, because the language model that fixes prose errors has nothing to say about digits. Any workflow that extracts figures from scans needs a validation step — totals that must sum, dates that must be plausible, account numbers with check digits.

Modern alternatives

Two developments have changed the landscape:

Vision-language models read documents rather than recognising characters, using context to resolve ambiguity in a way classical OCR cannot. They handle messy layouts, handwriting and mixed content notably better. They also hallucinate: where classical OCR produces a garbled character, a language model may produce a plausible wrong word, silently. That is a different and in some ways more dangerous failure mode, because the output looks clean. See multimodal LLMs and PDF documents and AI vs traditional OCR.

Structured extraction services — Textract, Document Intelligence, and similar — combine recognition with layout understanding and return fields rather than text. For invoices and forms at volume this is a substantially better fit than raw OCR. See AI data extraction from PDFs and extracting tables from PDFs with AI.

Both involve sending documents to a third party, which is a decision to make deliberately: risks of using AI on confidential PDFs.

Summary

Accuracy is driven far more by scan quality than by engine choice: 300 dpi minimum, greyscale, deskewed, decently contrasted. Always specify the language — the default-English model on a non-English document is the most common self-inflicted accuracy loss there is. Expect good results on Latin scripts, variable results on Arabic and Hebrew, and specialised tooling for CJK. And treat numbers differently from prose: the language model that quietly fixes your text errors does nothing at all for your figures.