A scan can look like a document while behaving like a photograph: the words appear on the page, but your software can’t select them, count them or translate them reliably. Converting that scanned PDF to editable Word before translation can help, but the result depends on the scan, the OCR method and how much layout the DOCX needs to preserve.
The practical choice isn’t simply “Which tool makes a Word file?” It’s “Which workflow gives this document a usable text layer without creating more cleanup than it saves?” A short letter, a form with boxes and a report full of tables call for different checks.
This guide compares Word, Google Drive, Acrobat, ABBYY FineReader PDF and OCR-first document translation. It also gives you a repeatable review process for deciding whether the converted Word file is ready to translate or needs repair first.
What you need to do before translating a scanned PDF¶
A scanned PDF is typically image data rather than searchable text. OCR, short for optical character recognition, identifies shapes in the page image as letters and words, then creates text that software can select and process. Adobe explains its OCR workflow as recognizing text in a scanned file to make its contents searchable.
That distinction matters because seeing text on screen doesn’t mean the PDF contains text. Try selecting a sentence and copying it into a plain-text editor. If the paste contains nothing useful, or if the page behaves like one large image, the document probably needs OCR before a text-based translation workflow can use its contents.
OCR doesn’t automatically create a polished Word document. Recognition and layout reconstruction are separate jobs. The software has to work out which marks are letters, which lines belong together, whether a page has columns, and whether a bordered area is a table or a collection of separate text blocks.
As Adobe Acrobat Help explains: “When you scan a paper document to PDF, the resulting file contains only image data, not searchable text.”
The quote describes the common case, not every PDF. Some files combine ordinary selectable text with scanned pages, stamps or inserted images. Check the actual file rather than assuming that every page has the same structure.
Before choosing software, separate the task into three outcomes:
- Recognize the text. The OCR output should include the words, numbers, punctuation and language that appear in the scan.
- Rebuild a usable document. Paragraphs, headings, tables and reading order should make sense in the editable file.
- Prepare the content for translation. The source text should be clean enough that a translator or translation system won’t confuse OCR mistakes with what the document actually says.
A searchable PDF can be enough when the next step is simply finding or copying text. A translation team that needs to edit the source, split work or review layout may prefer DOCX. The target format should follow the workflow, not habit: converting everything to Word can introduce layout changes that a searchable PDF would avoid.
A useful first test is one representative page, not the whole archive. Pick a page that includes the document’s hardest feature, such as a table, a stamp or two columns. Run the proposed workflow, then compare the result with the scan. If the sample fails, processing every page will only produce a larger cleanup job.
The difference between a searchable PDF and a translation-ready Word file is also covered in how to quote a scanned document when Word count finds nothing. The important point here is that OCR creates a starting point. Someone still needs to confirm that the recognized words and reconstructed layout match the source.
The main conversion options and what each one is good at¶
The conversion options differ in how directly they handle OCR, how much layout they can reconstruct and how much review they leave to you. The table is a shortlist, not a promise that one tool will preserve every page perfectly.
| Option | What it does | Where it can fit | Main caution |
|---|---|---|---|
| Microsoft Word desktop | Opens a PDF and converts a copy into a Word document | PDFs that are mostly text and need basic editing | It isn’t a dependable OCR-first route for a fully image-based scan |
| Google Drive and Google Docs | Opens a PDF or image file in Docs and applies OCR | A simple, sharp scan that fits Drive’s stated input limit | Lists, tables, columns, footnotes and endnotes may not be detected |
| Adobe Acrobat | Recognizes text in a PDF and creates a searchable version | OCR work where you want to recognize text in the PDF before handling DOCX separately | Text recognition and DOCX layout conversion are distinct checks |
| ABBYY FineReader PDF | Converts scans and PDFs into editable formats, including Word | Repeated or layout-heavy conversion work that warrants a dedicated OCR workflow | A recognized document still needs comparison with the source |
| OCR-first document translation | Recognizes scan content as part of a document translation workflow | Teams that want translation and formatted document output in one process | Scan quality, layout and language support still affect the result |
Microsoft says its PDF conversion works best with files that are mostly text. Word opens a copy, leaving the original PDF unchanged, but a page made largely of graphics may be inserted as an image rather than converted into editable text. That makes Word convenient for some PDFs, but not a safe assumption for a scan with no existing text layer.
Google Drive’s instructions cover PDF and JPEG, PNG and GIF inputs for its OCR method. The stated maximum input size for this method is 2 MB, so check the file size before planning to process a batch. Google recommends right-side-up pages, sharp images, even lighting, clear contrast and text at least 10 pixels high. It also recommends common fonts such as Arial or Times New Roman.
Adobe’s approach starts inside Acrobat’s Scan & OCR tools. Its help page describes selecting a page range and language before choosing Recognize Text. Adobe also notes that its recognition uses language-specific dictionaries, so the selected language should match the scanned document. The page describes recognition for one file or multiple files, which can suit teams handling several PDFs in a batch. Adobe’s current instructions are the place to verify the interface labels before processing.
ABBYY positions FineReader PDF as OCR software for converting scans and PDFs into editable Word and Excel documents. Its pricing page describes local, on-premise installation and license options; Windows volume licensing is also listed. The ABBYY pricing page displayed European store prices of €99 per year for Standard for Windows, €165 per year for Corporate for Windows and €69 per year for Mac at the time of research. Regional prices, taxes and renewal terms can differ, so check the current page for your market before comparing costs. The page also lists a 5,000-page monthly limit for Corporate automated Hot Folder processing at the time of research; that limit applies to that automated workflow, not as a general promise about every kind of use.
OCR-first translation is a different choice: instead of making a DOCX first, the translation service handles OCR as part of the job. Google Cloud Document Translation supports PDF input and PDF or DOCX output, along with DOC/DOCX, PPT/PPTX and XLS/XLSX formats. Google says the service supports native and scanned PDFs but warns that scanned PDF translation can lose formatting. Complex tables, multicolumn layouts, and charts with labels or legends can lose formatting too.
A direct translation route can save a conversion step, but it doesn’t remove the need to inspect the text and layout. Google recommends translating an editable DOCX or PPTX instead of a PDF when that original exists, because the editable source generally preserves layout and style better. The comparison is similar to the broader question of preserving formatting when translating Word, PDF and Excel documents: an editable source gives the workflow clearer structure to work with.
How to choose based on the scan, not the software name¶
A tool comparison becomes useful when you match it to the document in front of you. Page count alone doesn’t tell you whether OCR will be easy. A short form with a table, a signature and a stamp can be harder to reconstruct than a longer letter with clean, single-column text.
Start by checking the physical quality of the scan. RWS recommends a minimum scan resolution of 300 dpi for OCR, as well as black-and-white scanning rather than grayscale or color, and single-language PDFs where possible. Treat 300 dpi as RWS’s vendor recommendation, not a universal legal rule. RWS also warns that skew, stains, folds, handwriting and poor contrast can impair recognition.
Then check how the page is arranged. A report with regular paragraphs is easier to inspect than a page where sentences run through columns, text boxes or table cells. RWS notes that complex layouts containing columns, embedded images, tables or floating text boxes may need manual extraction and cleanup before machine translation. Its PDF-processing guidance also advises against line breaks or tabs inside sentences because those breaks can hurt machine translation output.
A practical selection guide looks like this:
| Document characteristics | First option to test | Why | What to review closely |
|---|---|---|---|
| Mostly text, already selectable | Open a copy in Word | Word is designed to convert text-heavy PDFs to DOCX | Page breaks, tables, footnotes and comments |
| Sharp, short scan with simple paragraphs | Google Drive OCR | A direct way to create editable text in Docs | Input size, line breaks and missing structure |
| Scan needs a searchable text layer before export | Acrobat OCR | Lets you recognize text in the PDF with a chosen language | Recognition errors and the later DOCX export |
| Repeated jobs or complex page layouts | ABBYY FineReader PDF | A dedicated scan-to-editable-document workflow | Cost, license fit and manual correction |
| You need a translated document rather than a DOCX source | OCR-first document translation | Combines text recognition and translation processing | Layout loss, scan restrictions and source-language recognition |
The table suggests where to start, not which product will win on every file. Take a page with a difficult layout and compare the resulting editable document against the scan. A visually close page can still contain wrong text; a textually correct page can still have columns in the wrong reading order.
For an archive of mixed documents, consider sorting files into groups before processing: clean text pages, forms and tables, and damaged or handwritten pages. A single conversion setting applied across every group can hide different failure patterns. A clean letter may need only spot checks, while a form may need a manual comparison of every field.
OCR language selection is another make-or-break decision. Adobe says the recognition process uses language-specific dictionaries and that non-Latin scripts require the appropriate language selection. If a multilingual PDF contains pages in different languages, test whether the tool handles each page correctly. Where it doesn’t, split the file into language groups if your workflow permits it, then make sure page order stays intact.
Mixed native-and-scanned PDFs deserve a separate check. A selectable paragraph next to a scanned attachment doesn’t prove every page can be processed the same way. Google Cloud says that, for mixed native-and-scanned PDFs, scanned content isn’t translated; its scanned PDF to DOCX conversion isn’t supported in the same way as native PDF, since PDF-to-DOCX is available for batch translation of native PDFs only. Google’s documentation describes those limits, so check the file’s page types before choosing a direct API route.
Translation risk changes with the document’s purpose. A misspelled word in a draft manual can be easy to repair if the source scan is available. A wrong digit in an account number or a misread name in an official document needs explicit verification, not a guess based on sentence context. Keep the original PDF beside the editable file throughout review.
Where layout and OCR go wrong¶
The biggest mistake is judging conversion by how the page looks at a glance. A DOCX can resemble the scan while putting text in the wrong order, merging separate fields or silently dropping a small label. Those errors can survive until translation, when a reviewer sees a fluent sentence built from the wrong source.
Google Drive Help warns: “Lists, tables, columns, footnotes, and endnotes are not likely to be detected.”
Google says its OCR may retain bold or italics, font size and type, and line breaks. That doesn’t mean it reliably reconstructs document structure. A table that becomes a run of adjacent words may be readable as text yet unusable as a form or translation source. Treat layout as something to verify, not something to infer from a close-looking page.
Word has a related limitation, though it appears at a different stage. Microsoft describes PDF as a fixed-layout format that may not encode the relationships among paragraphs, tables and columns. Conversion software must infer Word structures instead of simply recovering the original document’s structure. Microsoft lists conversion issues including tables with cell spacing, page colors and borders, frames, footnotes that span pages, endnotes, bookmarks and comments. Page breaks and layout can change too.
OCR can make text errors that aren’t obvious when you read quickly. Common review targets include:
- Names and identifiers: Compare proper names, account references, document numbers and addresses against the scan character by character.
- Digits and punctuation: Check dates, decimal points, minus signs and other marks that can change a value or make a field ambiguous.
- Accents and special characters: Confirm that the source language’s characters appear correctly, especially when scan quality is uneven.
- Reading order: Follow sentences across columns, text boxes and tables to confirm that a paragraph hasn’t been stitched together in the wrong sequence.
- Repeated headers and footers: Make sure page furniture hasn’t been inserted halfway through a sentence or mistaken for body text.
- Stamps and handwriting: Mark unclear content for human review instead of letting OCR invent a confident-looking word.
The translation stage can amplify source errors. A recognizer that changes a technical term or misreads a short name gives a translator a different source from the one on the page. Machine translation can then produce a coherent sentence that hides the original mistake. For a team workflow, record uncertain text and resolve it against the scan before handing the document off.
RWS notes that “Since PDFs are complex formats, especially when resulting out of scanning another document, you may need to perform some manual extraction of the document to an editable format.” The full guidance makes the practical point: automated conversion doesn’t remove the need for hands-on cleanup when the layout or scan quality is difficult.
One often-missed problem is line breaks inside sentences. OCR can insert hard returns after every visual line, even when a sentence continues across the page. RWS warns against line breaks or tabs inside sentences because those breaks can hurt machine translation output. Check paragraph flow before translation, especially when a tool treats each line or text block as a separate unit.
A good failure-handling rule is simple: don’t repair uncertain text by guessing. Keep a marker, note the page and location, and ask someone who can compare the source image. That is safer than turning a blurry name into a plausible but incorrect one. The guide to translating scanned PDFs and photos with OCR explains the broader OCR-to-translation workflow.
A review workflow that prevents expensive rework¶
The workflow below makes OCR output easier to evaluate before translation. It works for a single document and can also become a shared checklist for a team.
- Inspect the PDF before conversion. Try selecting a sentence, check whether every page behaves the same way, and note any mixed scanned and selectable content. Keep the original unchanged.
- Choose a representative sample page. Include the hardest layout in the document, such as a table, a column, a stamp or a form field.
- Prepare the scan where you control the source. Straighten rotated pages, improve contrast, and choose the document’s actual language in the OCR tool. RWS’s guidance recommends at least 300 dpi for OCR and cautions that skew and poor contrast can impair recognition.
- Run one candidate workflow. Use Word when the PDF already contains mostly text; test Drive for an eligible, simple scan; use an OCR-focused tool where recognition and layout reconstruction need separate attention.
- Compare the editable result with the image. Verify names, digits, section order, field labels, tables and footnotes. Don’t rely on a word count or an attractive-looking page as proof of accuracy.
- Repair structure before translation. Fix broken paragraphs, reading order and table cells. Flag uncertain characters for someone to check against the scan.
- Decide whether DOCX is actually needed. If your translation tool accepts the PDF and the document’s layout survives, conversion may add work rather than remove it. If editable content or source-side review matters, use DOCX and preserve the original alongside it.
- Run a final source check. Confirm that page order, headings, repeated content and all uncertain items have been resolved before translation begins.
For a team, save the review notes with the job. A short record of the OCR tool, selected language, pages requiring correction and unresolved source questions helps the translator distinguish genuine source wording from cleanup artifacts. The MTPE pricing comparison is useful when you’re deciding how to budget human review after an OCR or machine-translation first pass.
The cost of checking depends less on the name of the software than on how much correction the output needs. Compare time spent reviewing the sample with time spent manually extracting the same page. If OCR creates broken tables and unclear text, a clean manual extraction may be faster. If the scan is sharp and the layout is plain, OCR may provide a useful editable draft.
Microsoft says, “The conversion works best with files that are mostly text.” Microsoft’s scan-and-edit guidance also notes that the workflow uses desktop Word in supported versions, that web and mobile behavior may differ, and that the converted document may not preserve page-to-page correspondence.
That last point matters when reviewers refer to a page number in comments. Conversion can change pagination, so use a stable reference such as the original PDF page and a heading, table label or paragraph opening. Keep the scan available rather than expecting the DOCX to map page for page.
Online OCR and translation: when one workflow is enough¶
An online workflow can reduce handoffs when the goal is to translate a document, not to create a polished Word source for later editing. The right choice depends on whether the service can read the scan, handle its format and deliver the kind of output your team needs.
Google Cloud Document Translation accepts PDFs and can return PDF or DOCX output. Google says scanned PDFs are supported, but scanned PDF translation can lose formatting. The online request limits shown in its current documentation are 20 MB for PDFs; scanned PDFs are limited to 20 pages, while native PDFs can be processed up to 300 pages when the native-PDF option is enabled, or 20 pages with shadow removal enabled. Those limits and features are from Google’s documentation at the time of research, so check the current service guidance before building them into a production workflow.
Google also recommends translating DOCX or PPTX instead of PDF when editable originals exist. That recommendation is particularly relevant when a client supplied both the scan and the source Word file: use the editable original, rather than spending time trying to reconstruct structure from a scan. For mixed native-and-scanned PDFs, Google’s documentation says scanned content isn’t translated, and scanned PDF to DOCX conversion isn’t supported like native PDF conversion.
For smaller teams that need document translation rather than a full translation-management system, ChatsControl is one option to compare. You upload a PDF, DOCX or PowerPoint file, and its document workflow runs OCR on scanned files before returning a formatted translation; side-by-side review shows source and translated text together. A free tier with a character allowance is available, with paid top-ups for heavier use. The tool is cloud-based, isn’t a full CAT tool or TMS, and isn’t built for handwritten or very poor-quality scans, which still need human review against the original.
That option makes sense when you need a translated document with formatting and a review view, not when your main requirement is a clean OCR-only DOCX or offline processing. Check the output against the scan, particularly tables, proper names and unclear marks. Product capabilities, including OCR and review features, are described in the ChatsControl product reference.
If the goal is only text extraction, a translation service may be more than you need. If the document needs a human translation or certified output, automated OCR and translation are not substitutes for checking what the receiving organization requires. For a broader comparison of PDF translation workflows, see AI options for PDF translation.
FAQ¶
How do I convert a scanned PDF to editable Word before translation?¶
Run OCR with the document’s actual source language, export the recognized content to DOCX, and compare the result against the scan. Check names, numbers, reading order, tables and unclear marks before translation begins.
Can Microsoft Word convert a scanned PDF directly into editable text?¶
Word can open a PDF and convert a copy to Word, but Microsoft’s guidance says the feature works best with mostly textual PDFs. A page that consists mostly of graphics may be inserted as an image, leaving its text uneditable. See Microsoft’s PDF conversion guidance.
Is Google Drive OCR suitable for a scanned PDF translation workflow?¶
Google Drive can OCR PDF files by opening them with Google Docs, but its help page sets a 2 MB maximum input size for this method. Google also warns that lists, tables, columns, footnotes and endnotes are not likely to be detected, so review the structure before translating. Google Drive Help lists the input and layout guidance.
Which OCR tool is best for preserving tables and formatting?¶
No tool guarantees that every table will survive conversion as an editable Word table. Test a representative page and compare both the text and the structure with the source; choose the workflow that needs the least correction for your document.
Should I OCR a scanned PDF before machine translation?¶
Yes, when the PDF contains page images and the translation workflow needs selectable text. Check the OCR result first, because recognition mistakes in names, numbers or sentence order can become translation errors.
Can I translate a scanned PDF without converting it to Word?¶
Some document translation workflows accept scanned PDFs and run OCR as part of processing. Google Cloud supports scanned PDF translation but warns that formatting can be lost, so check the output carefully and use an editable original when one exists.