Skip to main content
Upcoming discountNext discount: 10% off — today 19:00.starts in--:--:--Get a quote →
Client Login
Home News The PDF Translation Problem: Why Do Files Get Stuck in CAT Tools?

Translation Technology 5 August 2026

The PDF Translation Problem: Why Do Files Get Stuck in CAT Tools?

PDF was designed to be read, not to be edited. That is why it causes trouble in translation tools. We explain where the loss happens and how it is prevented.

A significant share of the files that reach translation agencies are in PDF format. The reason is obvious: a PDF looks the same on every device, it is easy to share and it is the standard output format for official documents. The problem is that these very qualities are at odds with the translation process.

Contents

The PDF translation problem does not come from the file being bad, but from its having been designed for another purpose. PDF was made to be read, not to be edited. A translation tool, for its part, expects an editable text structure.

This article sets out the difference between the two types of PDF, what is lost during conversion, the limits of optical character recognition, how all this feeds through to the schedule and the price, and the way of working that keeps the loss to a minimum.

Why is PDF a format closed to editing?

A PDF describes how a document will look. It records which character sits at which point on the page, in which typeface and at which size. As a description of appearance it is flawless; as a description of structure it is incomplete.

In a word processor document, where a paragraph begins and ends, what level a heading sits at and how many columns a table has are all written down explicitly. In a PDF this information is not always reliably present. What looks visually like a paragraph may be a set of unrelated lines inside the file.

The consequence for translation is this: when the file is imported into the translation tool, segments are split in the wrong places. A single sentence may be scattered across three separate lines; text in two different columns may be merged as though it were one sentence. This corruption is then written into the memory as faulty units as well.

Multi-column layouts, footnotes, header and footer areas, watermarks and boxed warnings all add to the confusion. The more designed the document, the greater the structural loss.

Two kinds of PDF: with a text layer, and scanned

The first distinction that determines how problematic a PDF is for translation is whether or not there is text inside it. PDFs produced on a computer have a text layer; you can select the writing, copy it and search in it.

A scanned PDF, by contrast, is nothing more than a photograph of paper. There are no letters inside it, only pixels. As far as the computer is concerned, the file is an image rather than a text. When it is imported into a translation tool, nothing is found to translate.

There is a practical way of telling the two apart: open the file and try to select a word with the mouse. If the word can be selected, there is a text layer. If it cannot, and a region of the page is marked out as a box instead, the document has been scanned.

There is also a third kind in between: scans that have already been through optical character recognition. These do have a text layer, but it contains recognition errors. In a document that looks correct to the eye, the hidden text layer may hold faulty characters. This kind is the most deceptive of all.

What is lost in conversion?

There are several ways of making a PDF translatable, and each way has losses of its own. The table below compares the common scenarios.

SourceMethodTypical lossAdditional workload
Original Word fileDirect processingNoneNone
PDF with a text layerAutomatic conversionParagraph and table structureLow–medium
Designed PDFConversion and re-layoutPage layout, placement of boxesHigh
Scanned PDFOptical character recognitionCharacter errors, table structureHigh
Scan containing handwritingTyping by handSections that cannot be recognisedVery high

The column to watch in the table is the additional workload. That workload is not translation; it is the preparation that has to be done before translation. Agencies that work transparently show it as a separate line in the quotation instead of hiding it inside the translation fee.

The second thing to notice is where the loss is spotted. Structural loss shows up not during translation but at delivery. For that reason, in PDF-sourced jobs the format check has to be planned as a step separate from the language check.

The limits of optical character recognition

Optical character recognition turns a scanned image into text by recognising the letters in it. On a clean, high-resolution, straight scan the result is usually good. The problem is that most documents in the real world do not meet those conditions.

The error types are familiar. Characters of similar shape are confused with one another; digits and letters change places. Where a stamp, seal or signature sits on top of the text, the letters underneath cannot be read. On pages scanned at an angle, the lines run into each other.

Tables are a difficulty of their own. Optical recognition does not always detect cell boundaries correctly; once row and column information is lost, figures can fall into the wrong row. In financial statements and technical schedules this type of error has serious consequences.

Recognition output is therefore never handed straight to translation. A comparison step comes in between: the resulting text is placed side by side with the original image and checked at the level of figures, names and dates. When this step is skipped, the error belongs to the source rather than to the translation, and it is far harder to notice.

How does the PDF translation problem affect time and price?

In PDF-sourced jobs the total time is made up of three items: preparation, translation and rebuilding the format. When an editable source file arrives, the first and third items are close to zero. When a PDF arrives, those two items can take up a significant share of the total time.

The effect on price works in much the same way. Preparation calls for effort that is independent of translation volume; a short but complex document can need more preparation than a long but plain one. Pricing that looks only at the word count is therefore misleading for PDF jobs.

The second effect is on the memory side. A PDF processed with a broken structure leaves faulty segments in the memory. When those records come back as suggestions in later projects, the expected gain from repetition does not materialise. Today’s shortcut, in other words, lowers tomorrow’s productivity.

The third effect is delivery risk. In official procedures a document whose layout has been disrupted may be rejected. What is lost in that case is not only the translation fee but the delay to the procedure. That is why we set out price comparisons on the pricing page with these items shown separately.

The right way: working from the source file

There is a single step that removes most of these problems: working from the original file in which the document was produced. A PDF has usually been generated from a word processor, spreadsheet or design file. That file is still on somebody’s computer, and it turns up when it is asked for.

If the source file cannot be found, the next best route is to plan the conversion as a deliberate preparation step. In this step the text is extracted, the structure is rebuilt, the tables are reworked, and only then is the file imported into the translation tool. Once preparation is seen as a job in its own right, its quality also becomes measurable.

The third step is to decide the delivery format at the outset. Is the document wanted back as a PDF, or in editable form? Is it going to print, or is it going to be submitted to an institution? The answers to these questions determine how much care the preparation stage requires.

The last step is the comparative check. The document to be delivered is opened side by side with the original PDF and checked for page count, heading order, table structure and numerical fields. This check is independent of the language check and is indispensable in PDF-sourced jobs.

The Türkiye context

In Türkiye most of the documents submitted for translation are official papers, and those papers circulate mainly as PDFs. Printouts of civil registry extracts, diplomas, academic transcripts, criminal record certificates and trade registry gazettes are typical examples of this group. In such documents, preserving the layout matters as much as the translation.

One positive development is that public documents are increasingly produced electronically. Documents obtained through e-Devlet generally contain a text layer and can be processed directly. Older diplomas, court judgments and documents arriving from abroad, on the other hand, still come in as scans.

Another difficulty specific to Turkish is letter recognition. The dotted and cedilla-marked letters of the Turkish alphabet can be confused with their look-alikes in low-resolution scans. In the spelling of first names and surnames, a difference of a single letter causes a notarised translation to be rejected. Proper names are therefore typed by comparing them against the source image rather than trusting the recognition output.

What does this mean for you?

For you the practical upshot is very concrete: the format of the file you send has a direct effect on the delivery time and the price you will be given. A little preparation lightens the whole process.

  1. If an editable original of the document exists, send it along with the PDF; the preparation item often disappears entirely.
  2. If you have to scan, scan straight, at high resolution and as a full page; use a scanner rather than a phone photograph.
  3. Make sure that stamps and signatures do not cover the text; if they do, add a second, legible copy.
  4. Send the correct spelling of first names, surnames and institution names in a short note; it heads off recognition errors.
  5. Ask for preparation, translation and format checking to be shown as separate items in the quotation.

To find out which class your document falls into and what preparation it calls for, you can send your file through the quotation page.

Frequently asked questions

Why is a PDF file not suitable for translation?

PDF is a display format; it stores text by its position on the page rather than as structure. Because paragraph, table and heading relationships are not always reliably recorded, the structure can break when the file is imported into a translation tool.

What is the difference between a PDF with a text layer and a scanned PDF?

A PDF with a text layer was produced on a computer, and the writing inside it can be selected and copied. A scanned PDF is a photograph of paper; there is no text inside it, only an image. The second one needs optical character recognition first.

Does using OCR solve the problem completely?

No. Optical character recognition extracts most of the text, but the margin of error is high with handwriting, stamps, low-resolution scans and complex table structures. The resulting text has to be compared by a human.

What should I do if all I have is a PDF?

Send it, but send it knowing that the preparation stage may show up in the schedule and the price. If a Word or similar editable version of the document exists, adding it removes the preparation cost.

References

  • Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation: Insights from a Case Study. London: Routledge Focus, pp. 12–31.
  • ISO (2008). ISO 32000-1: Document management – Portable document format. International Organization for Standardization.
  • Bowker, L. (2005). Productivity vs quality? A pilot study on the impact of translation memory systems. Localisation Focus, 4(1), pp. 13–20.
  • O’Brien, S., Ehrensberger-Dow, M., Connolly, M. & Hasler, M. (2017). Irritating CAT tool features that matter to translators. HERMES, 56, pp. 145–162.
Share

Document ready? See your price in minutes

Get an Instant Quote
See your price in 2 minutes Get an Instant Quote
Chat on WhatsApp