Translating scanned documents without destroying the layout

A scanned page has no text layer, so translation has to rebuild the document as well as the words. Where the pipeline breaks, and how to keep tables and formatting intact.

Translating a digital PDF is mostly a solved problem. Translating a scanned one is not, and the reason is structural: a scan is a picture of a document. There is no text layer to translate. The pipeline has to read the page, translate it, and then rebuild it — and each of those three stages can fail independently.

Why the layout is the hard part

Text expansion is the first thing that breaks a scanned translation, and it breaks it visually rather than semantically.

German runs roughly 30% longer than English. Finnish and Russian expand too. Japanese and Chinese contract sharply. Arabic and Hebrew reverse the reading direction of the whole page. None of that matters in a plain text file, and all of it matters the moment you are placing translated text back into a fixed-width table cell that was sized for the original.

A translation engine that returns correct sentences and a document that no longer fits its own table is not a usable result. This is why "translate the text" and "translate the document" are different products.

Where the pipeline actually breaks

Reading order. Multi-column layouts, sidebars, and footnotes have no inherent order in an image. Get this wrong and the translation is fluent, coherent, and about the wrong thing — sentences from column two spliced into column one. This failure is particularly nasty because the output looks fine.

Tables. Cell boundaries in a scan are visual, not structural. Faint rules, merged cells, and rotated headers all confuse detection, and a table that gets flattened into a paragraph is unrecoverable downstream.

Numbers and identifiers. Invoice totals, dates, part numbers, dosages. These pass through OCR like any other text and are misread like any other text — but a misread digit is a materially different failure from a misread word, and translation engines will not flag it because there is nothing linguistically wrong.

Stamps, signatures, and handwritten annotations. Frequently the legally significant part of the page, frequently the part the pipeline silently drops.

Mixed-language pages. A contract with an English body and Japanese annotations needs per-region language detection. Systems that detect one language per document get the minority language badly wrong.

What to check in the output

Read the translated document as a document, not as text. Specifically:

  • Do the tables still have the same number of rows and columns as the original?
  • Are page numbers, headers, and footers present and sane?
  • Do the totals in any table still add up? (This catches OCR digit errors that translation review will not.)
  • Is anything in the original missing entirely — a stamp, a margin note, a footnote?
  • For expanding languages, is text overflowing or clipped anywhere?

That list takes a couple of minutes per document and catches the overwhelming majority of real failures.

Choosing an approach

If the source is already a digital PDF, use a document translator directly — there is no OCR stage to go wrong, and tools like 술술번역 handle the format round-trip without the extra risk.

If the source is a scan or a photograph, you want a pipeline that keeps OCR and layout reconstruction together rather than handing plain text to a separate translator. Scanned.to is built around that specific case, and for text extraction on its own — when you don't need the document back, just the words — ScanRead.ai is the lighter path.

If the source is a photograph of a page rather than a flatbed scan, spend thirty seconds improving the input before anything else: crop to the document, flatten it, shoot in even light. Every downstream stage inherits that quality, and no model recovers detail that was never captured.

The honest limitation

For anything with legal or medical consequence, machine translation of a scanned document is a first draft. Not because the translation is bad — it is often very good — but because the OCR stage underneath it introduces a class of error that reads as fluent and confident. The document looks right. That is exactly what makes it worth checking.