How to Translate a PDF Without Losing Formatting
Why PDF translation wrecks columns, tables and ligatures — and a step-by-step way to translate a PDF that keeps the original layout intact.
The short answer: don't translate the text of a PDF. Translate the PDF.
Almost every tool that "loses formatting" does the same thing under the hood — it rips a plain-text stream out of the file, sends that to a translation engine, and hands you back a wall of paragraphs. The layout was thrown away in step one. To keep columns, tables, figures and equations, you need a tool that treats the page geometry as data worth preserving, not as packaging to be discarded.
Here is why it breaks, what your options actually are, and how to check that the result is good.
Why formatting breaks in the first place
A PDF does not store paragraphs. It stores positioned glyphs: instructions of the form "draw this character, in this font, at this x and y coordinate on this page." There is no reliable notion of "this is a heading," "these two boxes are one table," or "column A continues on the next page."
So any tool that wants the text has to reconstruct it — guess which glyphs belong together, guess the reading order, guess where a paragraph ends. That guess is where formatting dies, and it dies before translation even starts.
Four things go wrong most often:
- Multi-column pages. Extractors frequently read straight across the page, so the left column and the right column interleave line by line.
- Tables. A table is usually just text drawn at grid coordinates, with the lines drawn separately as vector art. Flattened to text, the cells run together and the row-column relationship is gone.
- Footnotes, headers, captions. These are glyphs like any other, so they get spliced into the middle of body sentences.
- Ligatures and drop caps. A typographic ligature such as "fi" may be one glyph that maps back to two characters — or doesn't map cleanly at all. A decorative drop cap is a separate, much larger glyph, so it detaches from its own word.
What that actually looks like
This is real output from running a standard text extractor over page 1 of a two-column government fact sheet — a normal, well-formed, digitally-produced PDF:
S
ince the early 1990's, the
magnitude and location of an
Not long ago, the fi rst thing that most
people did after feeling an earthquake was to
Read it carefully. The drop cap "S" is orphaned on its own line. Two different columns are interleaved mid-sentence. The "fi" ligature has become "fi " with a stray space, turning "first" into "fi rst."
Now imagine sending that to a translation engine. It will translate it — confidently and fluently — into scrambled nonsense, because the reading order was already wrong. No amount of model quality fixes an input that was destroyed before the model saw it. This is the single most important thing to understand about PDF translation.
Your options, and what each one costs you
Copy-paste into a web translator. Free and instant. You get exactly the failure above, plus you lose every table, image and equation. Fine for reading one paragraph of a simple one-column page. Not fine for anything you will show another person.
Convert to Word or a generic document translator. Better than copy-paste, and sometimes good enough for simple one-column reports. But PDF-to-Word conversion is itself a reconstruction step with its own guesses, so you now have two lossy stages stacked on each other. Complex layouts — academic papers, datasheets, financial filings — usually come out visibly broken, and the target language changing length shifts everything downstream.
Layout-preserving translation. The tool parses the document into a structure that keeps the visual layout separate from the text, translates only the text, then re-anchors the translation back onto the original geometry. Formulas and figures are held aside as untouchable objects rather than translated as prose. This is the approach that survives a two-column paper with equations, and it's how PDFPal works.
Translating a PDF while keeping the layout: step by step
- Confirm your PDF has a text layer. Open it and try to select a sentence with your cursor. If nothing highlights, the page is an image and there is nothing to translate — see the last section below.
- Upload the PDF. Drag and drop it, or pick it from your files. Up to 100 MB, PDF input only.
- Set source and target. Leave the source on auto-detect unless the document is mixed-language, and pick from 40+ target languages.
- Pick an engine. Google is fast and deterministic and free to start. A free pooled Qwen model gives you an LLM-style read. Premium engines — OpenAI and Claude — handle nuance and terminology better and are available on a paid plan at a higher per-page rate.
- Optional: add a glossary. If your document has house terminology, product names or a standard translation for a technical term, import a simple two-column CSV of source and target terms so those stay consistent throughout.
- Check the estimated cost, then translate. Pricing is one credit per page, so a 12-page paper is 12 credits on a standard engine. Signing up gives you 20 free pages with no card.
- Download the version you need. You get a translated-only PDF that mirrors the source page for page, and a bilingual side-by-side version — which is the one to send to a reviewer who reads both languages.
If a job fails, the credits are refunded automatically and you can retry, optionally on a different engine.
How to check the result
Don't just skim the first page. Run this checklist:
- Open the side-by-side preview and step through the pages. Page count should match the original exactly, page for page.
- Check every table. Confirm the cells still line up with their headers and that no row wrapped into the row below it.
- Check figures and captions. Images should be in the same place; captions should sit under the right image, not the neighbouring one.
- Check the math. Equations should be identical to the source — untouched, not "translated."
- Look for overflow. German, French and Spanish typically run longer than English. Watch for text that got clipped by a tight box, or lines that collide with a figure.
- Spot-check terminology. Pick three terms that matter in your field and confirm they were translated the way your readers expect. If not, add them to a glossary and re-run.
You can see what good output looks like on real documents — six public-domain PDFs, original and translated — on the examples page.
What still cannot be preserved
Be realistic about the hard limits. These are not tool-specific complaints; they are properties of the format.
Scanned PDFs. If the pages are photographs or scans, there are no glyphs — only pixels. There is no text layer, so there is nothing to translate. PDFPal does not do OCR, and it will tell you this rather than silently producing garbage. The fix is to run the file through a dedicated OCR tool first, then translate the OCR'd PDF. (There is a "scanned-PDF mode" toggle, but it only improves rendering of already-extractable text on scan-like pages — it does not perform text recognition.)
Heavily stylised typography. Text set on a curve, letter-spaced display headlines, text baked into an image, and hand-tuned kerning will not survive a language change. Nothing can re-typeset a logo.
Very tight text boxes. If the original designer fitted English into a box with two millimetres to spare, a noticeably longer German translation has nowhere to go. Layout-preserving tools rescale paragraphs to fit, but there is a floor below which the text becomes unreadable. Documents designed with breathing room translate far better than ones designed to the millimetre.
Password-protected files. These have to be unlocked before any tool can open them.
If your document is a normal, digitally-produced PDF with selectable text, though, keeping the layout is a solved problem. Start with the 20 free pages and check the output against the list above — see pricing if you need more.
