Best OCR for Translation: Compare Engines for Scanned Documents

A scanned contract can look perfectly readable on screen and still turn into a string of broken names, dates, and table cells when a translation workflow tries to process it. The OCR engine sits between the page image and the translation, so its mistakes can travel downstream.

Choosing an OCR engine for document translation isn’t just a question of which one recognizes the most words. You also need to know whether it handles your languages, preserves reading order, exposes uncertainty for review, accepts your files, and fits your deployment needs. The right choice comes from testing your own documents, not trusting a generic accuracy claim.

Start with the file: not every PDF needs OCR¶

OCR, or optical character recognition, is software that turns text shown in an image into machine-readable characters. A scanned PDF is often just page images inside a PDF wrapper, so a translation workflow has to recognize the words before it can translate them.

A born-digital PDF may already contain selectable text. When it does, a workflow can often extract that text directly rather than running OCR. Google Document AI’s documentation says its Enterprise Document OCR supports extraction of embedded or native PDF text, including rotated or unusually styled text; check the current documentation before implementation because product behavior can change (Google Document AI Enterprise Document OCR).

That distinction matters for hybrid files. A PDF can contain digitally created pages, scanned pages, or both. An OCR sidecar file from OCRmyPDF contains text found through OCR, but text already present on pages may be absent from that sidecar. A mixed PDF can therefore produce an incomplete sidecar if you treat it as a full-document text export (OCRmyPDF cookbook).

Before comparing engines, find out what kind of input you actually have:

• Select text in a PDF viewer and copy a short passage into a plain-text editor. If the text comes through in the right order, direct extraction may be enough.
• Check whether some pages are selectable while others behave like images. Treat those as mixed pages, not as one uniform input.
• Inspect the page image itself. Rotation, skew, blur, glare, tiny print, stamps, and low contrast can all make recognition harder.
• Keep the original file unchanged. A cleaned or deskewed copy can help recognition, but image processing can also damage content you need.

Google documents page-level image-quality metrics for issues including blur, unusually small fonts, and glare, along with deskewing options; confirm which features apply to the processor version and region you use (Google Document AI Enterprise Document OCR). Those checks help you sort difficult pages before translation rather than discovering recognition gaps in a translated file.

The most important workflow decision happens before engine selection: separate text extraction from image recognition. If the PDF already contains usable text, adding OCR creates another processing step without solving a real problem. If the PDF is a scan, direct text extraction has nothing meaningful to extract.

Decide what “best” means for your translation workflow¶

An OCR engine can return a plain text stream, words with coordinates, a document hierarchy, confidence values, or a reconstructed searchable PDF. Those outputs solve different problems. A workflow that translates a contract and rebuilds its layout needs different evidence from a workflow that only indexes a stack of receipts.

Use these questions to define your requirements:

1. Which languages and scripts appear? Count the source languages, not just the intended translation languages. A page can have a letterhead in one language and body text in another.
2. Does layout affect meaning? Tables, two-column pages, forms, footnotes, and labels can become confusing if reading order is wrong.
3. Which errors have the highest cost? A misspelled company name, a changed digit, or a misplaced table value can matter more than a typo in a repeated heading.
4. How will reviewers find uncertain text? Confidence scores and word coordinates can help direct review to suspicious parts of a page.
5. What needs to happen after recognition? Searchable PDF output may be useful for archiving, while a translation pipeline may need structured text and geometry.
6. Where can the document be processed? A cloud API and a locally run open-source engine differ in deployment and operational requirements.

The first decision is not a contest between product names. It is a definition of what a passing result looks like. One team may need readable text for translation, while another needs extracted table cells and coordinates to rebuild forms.

Google describes Enterprise Document OCR as “Recommended when extracting text from documents.” The same documentation distinguishes it from Cloud Vision text detection, which it positions for general text extraction requiring low latency and high capacity (Google Document AI Enterprise Document OCR). In other words, choose a document-oriented processor when page structure is part of your task, and assess a general text-detection service against its own intended role.

A useful evaluation doesn’t rely on a single “accuracy” number. The official product documents describe different output features, but those details don’t establish that one engine will recognize your particular files better than another. A clean printed English page, a mixed-language form, and a faded scan are different tests. Score each candidate against the same sample and the same error priorities.

Teams comparing translation systems as well as OCR engines can use the MT engine bake-off guide to structure a fair comparison. The same principle applies here: hold the input and review criteria steady so the result reflects the engine rather than a different test setup.

Compare the main OCR options¶

The table is a starting point, not a ranking. Product behavior, supported languages, file formats, and quotas can change, so verify the current documentation and test the version you plan to deploy.

Google Document AI: document structure and page checks¶

Google’s Enterprise Document OCR returns a hierarchy that can include blocks, paragraphs, lines, words, and symbols. The documentation also describes deskewing PDFs and images, language detection, language or handwriting hints, rotation correction, and page-range selection (Google Document AI Enterprise Document OCR).

Google’s live processor listing says Enterprise Document OCR supports text, including handwritten text, in more than 200 languages and includes a machine-learning readability assessment. That figure reflects the listing checked for this article, not a promise that every language and script combination works equally well. Check the supported-language list for the exact language and script in your pages before choosing it (Google Document AI processor list).

Google’s documentation lists PDF, GIF, TIFF, JPEG, PNG, BMP, and WebP as accepted formats. The same live documentation gives request limits of 15 pages for synchronous processing, 500 pages for asynchronous processing, and 30 pages in synchronous imageless mode; verify current limits and processor configuration before building a batch workflow (Google Document AI Enterprise Document OCR).

The processor’s page-quality signals can help a reviewer prioritize bad pages. A page with glare or unusually small type may need a closer look even when the output looks mostly complete. Quality signals are not a substitute for checking the extracted words against the original.

Amazon Textract: confidence, layout, and tables¶

Amazon Textract’s FAQ says each word and line can come with a bounding box and a confidence score. Coordinates give downstream tools a way to locate text on a page, while confidence can help reviewers decide where to look first (Amazon Textract FAQ).

The same FAQ describes a layout feature that returns titles, headings, paragraphs, lists, figures, page numbers, and footers in natural reading order. Textract’s table extraction covers rows, columns, and merged cells. Those features are worth testing if your translated documents include forms, financial tables, or multipage reports where the relationships between cells matter (Amazon Textract FAQ).

Textract documents printed-text detection in more than 40 languages and English handwriting recognition. Its forms or key-value extraction is documented for English, German, French, Spanish, Italian, and Portuguese. Those are separate capabilities, so don’t assume the language support for printed text automatically applies to handwriting or forms (Amazon Textract FAQ).

Input limits can shape a batch workflow. AWS’s live quota documentation says Textract supports JPEG, PNG, PDF, and TIFF but not XFA-based PDFs. For asynchronous PDF or TIFF processing, the documented fixed limits are 500 MB and 3,000 pages; synchronous PDF or TIFF processing is limited to one page and 10 MB. Confirm current service quotas before deployment (AWS Textract document limits).

AWS also documents a minimum detectable text height of 15 pixels, described as about 8-point text at 150 DPI, and recommends the highest-quality image possible, ideally at least 150 DPI. Those are documentation details to use when preparing test files, not a guarantee that every scan at that resolution will be recognized accurately (AWS Textract document limits).

Azure Document Intelligence: mixed-language text and searchable PDF¶

Azure Document Intelligence Read version 4 accepts PDF, JPEG or JPG, PNG, BMP, TIFF, HEIF, DOCX, XLSX, PPTX, and HTML, according to Microsoft’s version-specific v4 documentation. The same documentation lists a PDF or TIFF maximum of 2,000 pages, a 500 MB file size for paid S0, and a 4 MB file size for free F0, where only the first two PDF or TIFF pages are analyzed. Check current tier and format limits before planning production volume (Azure Document Intelligence Read v4).

Azure’s universal deep-learning OCR models can extract mixed-language lines without a language code. Microsoft warns against forcing a language when you’re unsure: applying only the wrong language model can produce incomplete or incorrect text. The language matrix is version-specific, so check the exact languages in your documents before making a decision (Azure OCR language support).

Microsoft states in its guidance: “Don’t provide the language code as the parameter unless you are sure of the language and want to force the service to apply only the relevant model.” The practical point is simple: don’t guess a language setting on mixed or uncertain pages. Test automatic handling against a correctly specified language on representative material (Azure OCR language support).

Azure Read can also output a searchable PDF with extracted text embedded over scanned page images. The v4 documentation says searchable-PDF output has no additional cost and is supported by prebuilt-read; confirm current pricing and support before making it part of a production process (Azure Document Intelligence Read v4).

Tesseract: open-source control, with language setup to manage¶

Tesseract is an open-source option for teams that want to run OCR through a command line and manage the surrounding workflow themselves. Its command-line documentation describes the LSTM neural engine and the --oem 1 setting, and shows multiple language models specified together, such as eng+deu (Tesseract command-line usage).

Tesseract’s documentation says English is the default if no language is specified. That default can be a quiet source of errors: a non-English page may still return output, but the output can be wrong. OCRmyPDF’s language documentation is explicit that Tesseract can’t identify an unknown input language on its own, and assumes English unless told otherwise (OCRmyPDF language packs).

Tesseract can produce searchable PDFs, hOCR, and TSV. hOCR can include word bounding boxes, while TSV output can include word-level confidence values, giving a downstream review process useful coordinates and signals (Tesseract command-line usage).

OCRmyPDF adds a practical distinction between two common image corrections: --rotate-pages corrects a page’s cardinal rotation, while --deskew corrects a slight tilt. Its documentation advises reviewing pages after image-processing options because cleanup can damage content you want to keep (OCRmyPDF cookbook). Open source doesn’t remove the need for a quality process. It shifts more of the language-pack setup, version management, and workflow maintenance to your team.

Build a fair test with your own documents¶

A short, repeatable bake-off is more useful than choosing an engine from feature lists. Select pages that represent the work you’ll actually send for translation, then run every candidate on the same inputs and inspect the same types of error.

Use a sample that contains:

• Each source language and script in the real workload, including lines where languages are mixed.
• Tables, forms, columns, labels, footnotes, and headers where reading order affects meaning.
• Company names, people’s names, addresses, dates, reference numbers, and amounts.
• Pages with clear print and pages with the quality problems you expect to receive.
• A mix of selectable-text pages and scans if your real files include both.

The exact sample size depends on the variety and volume of your files. The important point is to test representative pages rather than invent a generic page count or use only a pristine sample. No universal accuracy score can be inferred from the product documentation alone. Compare current engines on your own versions and inputs.

Record a small set of results for every page:

Score critical errors separately from minor text noise. A missing digit in an amount is not equivalent to a punctuation difference in a repeated heading. Ask the people who review translations to identify which OCR errors would force them to stop and consult the original.

Amazon Textract’s word- and line-level confidence scores can help direct attention, but a confidence score isn’t proof that a word is correct. Google offers page-level image-quality measures, which describe image conditions rather than certifying each translated result. Treat both as review aids, not replacements for comparing source and extracted text (Amazon Textract FAQ; Google Document AI Enterprise Document OCR).

A useful test also checks the steps around the engine. Can your workflow send a page for review when a name or number looks uncertain? Can it preserve coordinates when the document is reconstructed? Can it keep a mixed native-and-scanned PDF complete? An OCR output that reads well in a demo but can’t be reviewed or routed sensibly may not be a good fit for a translation pipeline.

Protect layout and meaning after recognition¶

OCR reads words from pixels, but translation must also keep track of how those words relate to each other. A heading above a table, a label beside a value, and a footnote at the bottom of a page don’t mean the same thing if they enter the translation step in the wrong order.

A PDF isn’t a word-processing document with paragraphs and tables built into it. Its text can be stored as separate items positioned at coordinates. A workflow that pulls out just the text may receive a stream that has lost the page relationships a reader relies on. Recognition and layout reconstruction are therefore related, but separate, tasks.

Amazon Textract’s layout output can return document elements in natural reading order and its tables feature extracts rows, columns, and merged cells. Google returns a hierarchy of blocks, paragraphs, lines, words, and symbols. Those outputs give a pipeline more structure to work with, but you still need to check whether the specific elements you care about survive in the shape your translation system expects (Amazon Textract FAQ; Google Document AI Enterprise Document OCR).

A common test failure happens when a team checks only whether every word appears somewhere. A table may contain all the right words while moving a value to the wrong row. A two-column page may contain all the paragraphs while reversing their order. Review for relationships, not just word presence.

How translation handles the layout matters too. In ChatsControl, a scanned PDF or photo is read first, then rebuilt as a formatted Word document, with tables, fields, and page elements placed to follow the source layout. The document can then be translated as a formatted file. The service is built for document translation, not for handwritten text or very poor, degraded scans, which still need closer human review (ChatsControl).

A useful workflow makes the scan’s condition visible instead of treating every page as equally reliable. ChatsControl assigns scans a good, fair, or poor quality grade and counts words its check still finds missing. That can help a reviewer decide where to inspect the original before relying on the translation; it doesn’t make a difficult scan legible by itself.

For translation teams, bilingual review best practices can help turn OCR output into a reviewable process. The reviewer should be able to compare the extracted source with the page image and then compare the translation with the source, especially for numbers, names, and table relationships.

Pitfalls that can make a good engine look bad¶

A poor result doesn’t always mean the engine is the wrong one. File preparation, language settings, image cleanup, and incomplete extraction can all create errors that appear to come from recognition.

Wrong or missing language settings¶

Tesseract defaults to English if you don’t specify a language, and OCRmyPDF says Tesseract can’t identify an unknown input language on its own. A team that installs only the default model can misread a page without seeing an obvious processing failure (Tesseract command-line usage; OCRmyPDF language packs).

Azure takes a different approach for its universal deep-learning OCR models, which can extract mixed-language lines without a language code. Microsoft’s warning is to avoid forcing a code unless you’re sure of the language and want to apply only the relevant model (Azure OCR language support). The right setup depends on the engine: don’t copy a language-setting rule from one tool to another.

Rotation and skew are different problems¶

A page turned sideways needs rotation correction. A page tilted slightly needs deskewing. OCRmyPDF documents separate options for those jobs, and warns that image cleanup may damage useful content, so inspect pages after processing rather than assuming every correction improves them (OCRmyPDF cookbook).

Google Document AI also documents rotation correction and deskewing features. Verify that the features are supported by the processor version and region you plan to use, then check corrected pages against the original (Google Document AI Enterprise Document OCR).

OCR errors get translated as if they were source text¶

A translation engine can’t reliably infer that a printed name was read incorrectly. If OCR changes a digit or substitutes a character in an identifier, the translation stage may preserve the mistake or render it in another script. Check high-risk items in the extracted source before translation, not only in the final target-language file.

ChatsControl’s translation workflow includes a separate automatic QA check for issues such as numbers, names, terminology, and omissions. That check can help flag translation issues, but it doesn’t remove the need to verify the OCR output against a difficult source image (ChatsControl).

A sidecar file can be incomplete¶

OCRmyPDF notes that a sidecar contains text found through OCR, while text already present on pages may not appear in that file. A workflow that treats the sidecar as the complete text of a mixed PDF can silently omit native text (OCRmyPDF cookbook).

Test mixed documents explicitly. Check whether the workflow combines native-text extraction with OCR results, and whether it avoids duplicates when the same page has both embedded text and an image.

A specification number isn’t a quality guarantee¶

Page limits, accepted formats, and supported language lists tell you whether a service may handle your input. They don’t tell you how well it will read the specific type, script, scan, or layout in your document. Google’s support for more than 200 languages, for example, is a live processor-list claim; check the exact language and script rather than assuming every page will work equally well (Google Document AI processor list).

Amazon Textract’s documented 15-pixel minimum text height and its image-quality recommendation can inform your file preparation, but a page that meets a documented threshold can still contain difficult characters, blur, or layout problems (AWS Textract document limits). Test against actual source pages before setting acceptance rules.

Choose by the whole workflow, not one feature¶

The right OCR engine for translation is the one that fits your pages and your review process. Use Google Document AI when its document hierarchy, language options, and quality signals match your requirements. Assess Textract when confidence data, bounding boxes, layout, tables, or forms matter. Test Azure when mixed-language lines or searchable PDF output fit your workflow. Consider Tesseract when you want an open-source command-line process and can manage language models and maintenance.

Before selecting a tool, make sure you can answer these questions:

• Does the source have selectable text, scanned pages, or a mix?
• Can the engine handle every language and script in the sample?
• Does the result keep reading order, table relationships, and useful page coordinates?
• Can reviewers find and correct uncertain names, dates, amounts, and labels?
• Do file formats, page limits, and deployment requirements fit the job?
• Have you tested the same representative pages through every candidate?

The best OCR for translation isn’t a universal brand name. It’s a tested part of a document pipeline that gets the source text, structure, and uncertainty into a form your translators and reviewers can use. A short evaluation on representative documents can expose problems before a whole translation batch depends on the result.

FAQ¶

Which OCR engine is best for translating scanned PDFs?¶

There’s no universal winner. Compare Google Document AI, Amazon Textract, Azure Document Intelligence, and Tesseract on representative pages, then judge recognition, reading order, tables, review data, formats, and deployment fit.

Is Tesseract good enough for multilingual document translation?¶

Tesseract can use multiple specified language models, such as eng+deu, but it can’t identify an unknown input language by itself. Install the models you need and test mixed-language pages before relying on the output (Tesseract command-line usage; OCRmyPDF language packs).

Which OCR tools preserve tables and reading order in translated documents?¶

Amazon Textract documents natural reading order and table extraction for rows, columns, and merged cells. Google Document AI returns document hierarchy and documents reading-order improvements for a specified version; test the exact output and version your translation workflow will use (Amazon Textract FAQ; Google Document AI Enterprise Document OCR).

How should a business test OCR accuracy before translating documents?¶

Run the same representative pages through each candidate. Compare names, dates, numerals, tables, mixed-language text, reading order, and difficult scans, then review the extracted text against the page before translation.

Can OCR guarantee an accurate translation of a scanned document?¶

No. OCR converts pixels into text, and recognition mistakes can carry into translation. Check the extracted source against the original, especially when names, dates, numbers, or table cells matter.

Do I need OCR for every PDF?¶

No. A born-digital PDF with selectable text may allow direct extraction without OCR. Scanned pages need recognition, and mixed PDFs need a process that handles both embedded text and page images.