Machine Translate a PDF: What Breaks and How to Check

A sales team sends a translated product sheet to a distributor, and the words look plausible until someone notices that the table headings no longer match the figures beneath them. The PDF still opens, but the document no longer says quite what the source said.

Machine translation can produce fluent sentences from extracted PDF text while missing the page structure that gives those sentences context. The result may have a reading-order problem, an omission, a layout failure, or several at once. A readable paragraph is not proof that the whole PDF was translated correctly.

The first useful question isn’t “Which translation engine should we use?” It’s “What kind of PDF are we sending, and how will the tool read it?” A text-based PDF, a scanned page, and a file that mixes both can look similar on screen while presenting very different problems to translation software.

Why a PDF is harder to translate than a Word file¶

A PDF is a page description, not a Word document with editable paragraphs and tables waiting to be replaced. Much of its content is text positioned on a page, and that difference matters as soon as a translation tool extracts the words.

In a DOCX file, paragraphs and table cells are explicit structures. A program can read the text in a paragraph or a cell, translate it, and put the translated text back into the corresponding place. In a PDF, words can instead be placed at particular coordinates. The file may look like a neatly aligned table to a person, while its underlying content doesn’t identify a true table at all.

That distinction explains why direct PDF translation can fail even when each individual sentence looks reasonable. An extraction step needs to work out which words belong together, where one reading sequence ends, and how a translated sentence should fit back onto the page. If the structure isn’t recognized correctly, fluent translation can be built from text in the wrong order.

A research paper on scientific document translation makes the point plainly:

“Non-textual elements in scientific and technical documents are not ignorable — the arrangement of paragraphs, mathematical equations, tables, and figures have rich and important meanings.”

The arrangement is part of the information. A chart legend placed beside a graph, a note connected to a table, or a mathematical expression placed inside a paragraph can change how a reader interprets the words. Removing those relationships may leave all the text present but still change what the page communicates.

The paper describes a layout-aware workflow that detects page layout, extracts text, translates it, and places the translated text back into the layout (PDFMathTranslate). That workflow is a useful way to think about the task even if you’re evaluating a different system: text extraction, translation, and page reconstruction are separate stages, and a failure at any stage can affect the delivered file.

Translation also changes the shape of text. A sentence can become longer or shorter in the target language, and a label that fitted inside a box in the source may overflow or wrap in the output. The system then has to decide whether to shrink the text, move it, change the box, or leave part of it outside the visible area. A page that looks nearly identical isn’t necessarily faithful if the longer sentence has been clipped.

The same distinction applies to visual fidelity and linguistic completeness. A file can preserve colors and fonts while leaving a scanned note in the source language. Another file can translate every extracted sentence but turn a structured page into a wall of text. Reviewing only the translated wording or only the appearance misses the other half of the job.

What fails when a translation tool reads a PDF¶

PDF translation problems usually begin before the translation model writes a sentence. The important question is what the software can actually read and how it represents the page content.

Text extraction can change reading order. A person generally reads a page by following its visual structure. Software may instead collect text based on coordinates, object order, or an inferred sequence. On a two-column page, an extractor could read across a line from the first column into the second, or collect one column before the other. A sidebar, caption, or footnote can also interrupt the main text.

Adobe’s accessibility documentation explains that rendering order doesn’t have to match reading order. Tagged PDF uses a logical structure intended to correspond to the content order, while tools working with an untagged file may have to infer that order from the page. Tags can help expose the intended structure, but they don’t guarantee perfect extraction (Adobe’s PDF accessibility guidance).

A practical example is a two-column safety leaflet. The page may show one complete column followed by another, but the extracted text can alternate between them. The translation then joins unrelated sentences. Even if every word is recognized and translated, a reader may follow an instruction from the wrong section or mistake a warning for an explanation.

Tables can become a sequence of disconnected words. A visually clear table depends on row and column relationships: a label in one column belongs to a value in the next. If extraction takes the text but doesn’t preserve those relationships, the translation may leave headings attached to the wrong figures or put cells in a misleading order. A table may also expand when the translated labels take up more space.

Graphs can lose the relationship between labels and data. A chart may use short labels, an axis, a legend, and notes placed close to the visual. Translating those parts as an undifferentiated text stream makes it harder to tell which label belongs to which line or category. Google’s Cloud Translation documentation identifies tables, multi-column pages, and graphs with labels or legends as examples of complex layouts where formatting may be lost (Google Cloud document translation documentation).

Scanned pages introduce a recognition step. A scanned PDF page is a picture of text, not editable text that a translation program can select. OCR, or optical character recognition, attempts to identify the characters in that image and convert them into searchable or editable text. Adobe describes OCR as converting PDF image content into editable or searchable text (Adobe’s OCR documentation).

Recognition happens before translation, so an OCR error can become a translation error. If a scan misreads a name, a decimal point, or a short label, the translation system may never see the correct source text. OCR itself doesn’t translate the words or confirm that a translated sentence means the same thing as the source.

A mixed PDF can hide untranslated pages. A document can contain selectable text on some pages and scanned image content on others. The file extension alone won’t tell you whether every page is readable text. Google’s Cloud Translation documentation says scanned content in a mixed native-and-scanned PDF isn’t translated by its document translation API. That makes page-by-page inspection essential, not optional.

Text can sit outside the main body. A PDF can place important wording in a callout, label, image, or form field. Some translation workflows can also overlook text boxes in supported editable documents. Google Cloud says text inside text boxes in supported DOC, DOCX, PPT, and PPTX files isn’t translated and remains in the original language. The example isn’t a universal rule for every product, but it illustrates why checking only body paragraphs is risky.

Font and character support can affect what readers see. Even correctly translated text can display incorrectly if the output lacks suitable glyphs or handles text direction poorly. The problem is separate from whether the translation is linguistically right: missing characters, unusual line breaks, or displaced punctuation can make a correct sentence difficult to read. For a closer look at the difference between character display and document content, see multilingual font and encoding problems.

Right-to-left scripts add another layer. Arabic and Hebrew are read from right to left, but digits and embedded Latin words usually run from left to right. Unicode’s Bidirectional Algorithm explains how a line can mix both directions and still be displayed according to logical character order (Unicode Standard Annex #9).

The Unicode standard states:

“The Unicode Standard prescribes a memory representation order known as logical order.”

Logical order describes how characters are represented; visual order describes how the text appears on screen. A reviewer who checks only the visual line may miss a sequence problem in extracted text, and an output that places a name or number oddly can be hard to interpret even when the individual characters are present. A PDF translated into or from a right-to-left language deserves a visual check of names, dates, and mixed-script lines.

Translation can overflow the original design. A text box that fitted a short heading may not fit the translated one. The output can shrink text, wrap it into a new line, or clip the final words. A quick glance at the page may miss the problem, particularly if it affects a footnote, form instruction, or label rather than the main heading.

How to check whether text, numbers, and layout survived¶

A translation check should compare the source and output in two ways: as language and as pages. The source text tells you what was meant; the rendered pages show you what a reader can actually see.

Start by identifying the PDF type. Try selecting and copying a line of text from each page, not just the first page. Selectable text suggests that a page contains native text, but it doesn’t prove that the reading order or structure will extract correctly. A page with no selectable text is likely to need OCR. A file with some selectable pages and some image pages needs a mixed-content check.

Then inspect one representative page from each type of layout in the file: a regular paragraph page, a page with columns, a table, a diagram, and a scanned page if present. One successful page doesn’t establish that the rest of the file is covered. Different pages can use different content types and layouts.

Use this checklist during review:

1. Compare page coverage. Match every source page to an output page. Look for blank pages, missing sections, untranslated scanned pages, or a translated file that ends before the source does.

2. Check reading order. Follow headings, paragraphs, sidebars, captions, and footnotes in the order a reader should encounter them. Compare extracted text with the visible page if two columns or floating elements appear.

3. Recheck numbers and dates. Compare amounts, quantities, decimals, percentages, reference numbers, and date components. A changed value can be more consequential than an awkward sentence.

4. Verify names and identifiers. Check personal names, company names, product codes, addresses, and labels. For official forms, look closely at names written in more than one script. A related guide explains why surname apostrophes can cause transliteration problems in foreign databases.

5. Inspect tables cell by cell. Confirm that each translated heading still belongs to the correct column and that each row’s values stay together. Don’t infer correctness from the table’s overall appearance.

6. Review charts and illustrations. Check legends, axis labels, callouts, and any text embedded in an image. A translated paragraph near a chart doesn’t prove the chart itself was translated.

7. Look at text containers. Inspect form fields, callout boxes, labels, headers, footers, and text boxes, not only the main body paragraphs. Verify that no text remains in the source language.

8. Read the rendered output. Look for clipped words, overlapping labels, broken symbols, unexpected line breaks, and text that has become too small to read comfortably.

Numbers need an independent pass because fluent translation can conceal a small but significant alteration. A decimal point, minus sign, unit, or date can be separated from the text that explains it. Compare the source and translation as values, not just as strings: different date formats may represent the same date, while superficially similar numbers may not.

A useful review sheet can record the source page, content type, check performed, and finding. For example:

The table is a working aid, not a substitute for reading the document. A reviewer can mark every page as checked and still miss a problem if the check covers only spelling or only visual layout.

When a document is large, use a risk-based order. Check scanned pages, dense tables, multi-column pages, diagrams, and right-to-left text before straightforward paragraphs. That approach doesn’t excuse leaving other pages unchecked; it helps find the highest-risk failures early.

A second reviewer can help with consequential content, but reviewers need a clear task. Ask one person to compare facts and numbers, another to inspect layout and coverage, or ask the same reviewer to perform separate passes. “Proofread the translation” is too broad to catch every type of PDF failure.

Choose a translation route that matches the source¶

The right workflow depends on what the PDF contains and what file you can access. The easiest-looking route isn’t always the one that preserves the most useful information.

When an editable original exists, start there. Google Cloud recommends translating an available DOCX or PPTX rather than its PDF counterpart, then converting the translated file to PDF. Its documentation says that DOCX and PPTX layout and style are generally preserved better than PDF. The word “generally” matters: an editable source can still contain unsupported objects, text boxes, or layout choices that need review.

An editable source also makes it easier to check paragraphs and table cells as structured content. A PDF may be the final presentation copy, while the DOCX is the actual working file. If you can get the original from the person or team that created the PDF, ask for it before rebuilding the layout from scratch.

When only a native-text PDF exists, extract with a layout-aware workflow. A tool may detect blocks and positions, reconstruct them into an editable document, translate the content, and place it back into a page layout. A research workflow for PDF translation describes those stages explicitly: detect layout, extract text, translate it, and restore the translated content to the layout (PDFMathTranslate).

The output still needs a check. A reconstruction can interpret a table incorrectly, misread columns, or give translated text too little space. Ask whether the resulting file is an editable document, a rebuilt PDF, or plain text. Those outputs support different kinds of review, and a plain text result can’t preserve the original page design on its own.

When only a scanned PDF exists, treat OCR as a separate quality gate. Confirm that the system can process image pages, then inspect what it recognized before treating the translation as complete. A stamp, skewed scan, faint print, or image with poor contrast can make recognition less dependable. A scan that appears to contain all the words visually may still produce incomplete extracted text.

For browser-based document translation, check the tool’s stated scope. Google’s browser-based Translate document feature lists PDF support up to 10 MB and 300 pages in documentation checked for this article in November 2026. The same documentation warns that scanned or image-based page text can appear untranslated in the output (Google Translate Help). Those limits describe that feature, not every translation tool.

Google Cloud documents a separate set of online PDF translation limits: 20 MB, up to 300 pages for native-only PDFs, and 20 pages for scanned PDFs. The documented limit is 20 pages when shadow removal is enabled. Google Cloud also says PDF-to-DOCX output is available for batch translation of native PDFs, and that hyperlink, font-size, and font-color preservation applies only to native PDFs (Google Cloud documentation). Product limits and behavior can change, so check the current documentation before planning a job around them.

Those differing limits are a reason to name the exact service and mode when evaluating capacity. “PDF translation supports 300 pages” is too broad if the limit changes for scanned files or depends on whether the job is online or batch. The file type, content type, and output format all matter.

When the PDF is important, keep the source and output side by side. Don’t overwrite the source file or rely on a translated PDF as the only record. A reviewer should be able to compare the two page by page, and a business should be able to return to the original if extraction or reconstruction failed.

The distinction between automated checking and human review matters too. Post-editing means a person reviews and corrects machine-translated text; it doesn’t automatically mean that the page layout, every figure, or every scanned label has been checked. See what machine translation post-editing involves for the language-review side of that process.

Common PDF translation mistakes and when direct translation isn’t enough¶

The most expensive mistakes often come from assuming that a file is complete because the main paragraph reads smoothly. A PDF can be persuasive on screen while still omitting a footnote, misplacing a number, or leaving a page image untranslated.

Mistake: checking only the first page. A cover page may be selectable text while later pages are scanned images. A document may also switch from simple paragraphs to tables or diagrams without changing its file extension. Inspect representative pages and compare every page in the final review.

Mistake: treating OCR output as verified text. OCR is a recognition step, not a translation-quality check. If it reads a character incorrectly, a translation model can faithfully translate the wrong input. Compare recognized text with the scan before relying on the translation, especially around names, numbers, and short labels.

Mistake: trusting a page that looks tidy. A polished layout can’t tell you whether a table heading matches the correct column or whether a graph label belongs to the correct series. Review content relationships as well as spacing, fonts, and alignment.

Mistake: treating tagged PDF as a guarantee. Tags can expose the intended logical structure, which helps software understand content order. Adobe’s accessibility guidance notes that untagged PDFs can still have some structure inferred, but the result may be less satisfactory. Tags improve the information available to a tool; they don’t guarantee flawless extraction or translation.

Mistake: confusing a complete text dump with a complete translation. A text extraction may omit words embedded in an image or fail to include content in a container. Comparing only text against text can miss an untranslated label in a diagram. Comparing only pages can miss a change in meaning. Run both checks.

Mistake: assuming a single set of limits applies to all PDFs. Native PDFs, scanned PDFs, and mixed PDFs may have different support or page limits in the same service. Google’s browser-based feature and Google Cloud document translation publish different limits and caveats, as described above. Check the current documentation for the specific service and mode, rather than applying one number to all PDF workflows.

Mistake: expecting the output to be a legally acceptable translation. Machine translation may help a team understand an internal document or prepare a draft, but a translated PDF isn’t automatically certified or accepted by an authority. If a document must meet formal requirements, check what the receiving institution requires before choosing a workflow. Translation quality and legal status are separate questions.

Direct machine translation can be reasonable when you need a quick working version of a simple, text-based document and the cost of a minor layout issue is low. A short internal memo with selectable text and no complex layout is a different risk from a form, a contract, a medical document, or a page of financial tables.

Use a more controlled process when a document contains important numbers, instructions, legal or financial wording, dense tables, scanned pages, or text in several writing directions. When the content will be used to make a decision or submitted to someone else, assign a reviewer who can compare the translation with the source and verify the facts that matter.

A PDF is a container, not a guarantee that all its contents are readable or translatable. Check what each page contains, how the tool reads its structure, and whether the output preserves both the words and their relationships. That simple distinction catches many problems before a translated document reaches the person who has to rely on it.

FAQ¶

Why does machine translation break PDF formatting?¶

A PDF positions text on a page rather than storing it as editable paragraphs and tables. Extracting and translating the words can lose column, table, and reading-order relationships, and translated text may not fit the original layout.

Why are scanned PDF pages not translated correctly?¶

A scanned page is an image, so software must first recognize the words with OCR. Recognition errors, mixed scanned and native pages, or a tool that doesn’t translate image text can leave words missing or untranslated.

How do I check whether a PDF translation omitted text or changed numbers?¶

Compare each translated page with the source, checking headings, footnotes, table cells, labels, numbers, names, and text inside images or boxes. Compare meaning as well as visual placement, and check extracted text against the page.

Is it better to translate a PDF or its original Word file?¶

When an editable DOCX or PPTX source is available, translating it is generally preferable. Google Cloud recommends this approach because DOCX and PPTX layout and style are generally preserved better than PDF.

Why does text come out in the wrong order when I extract a PDF?¶

PDF rendering order and reading order don’t have to match. Without a reliable logical structure, an extraction tool may infer order from visual positions and sequence columns, labels, or sidebars incorrectly.

What should businesses check after machine translating a PDF?¶

Check page coverage, reading order, table and column structure, text inside images and boxes, names, dates, numbers, and links. Review the rendered pages alongside the source and investigate any OCR or extraction gaps.