PDF to Word: what survives and what doesn't

Short answer: a PDF-to-Word converter does not read the document you see. It reads a text layer stored alongside the pictures, and that layer is missing pieces more often than not — unembedded fonts with no character map, images in formats the engine cannot decode, ligature glyphs that tear words like flight in half. We batch-tested 134 real PDFs against our own browser-based converter and traced every failure to something inside the file itself. Here is what actually determines whether your conversion comes out clean.

The test corpus was not a set of tidy sample files. It was 134 real documents — invoices, business plans, exam papers, government forms, mixed Chinese and English — run end to end through a converter built on pdf.js. The headline result: 130 files converted identically with and without one critical fix, 4 files lost all of their Chinese text, and 1 file produced permanent garbage. Every one of those failures was silent. No error message, no crash. The file just came out wrong.

That silence is the theme of this guide. A converter almost never fails loudly. It fails by handing you a document that looks finished and isn't.

First: a converter reads the text layer, not the picture

A PDF is not a document format in the way Word is. It is a printing instruction set: place this glyph at these coordinates, draw that image in this rectangle. There is no requirement that the letters carry their own identity. When you "convert to Word", the converter reads back those instructions and tries to reconstruct paragraphs, headings and lists from coordinates alone.

This is why scanned documents are the hard boundary. A scanned PDF contains photographs of pages — there are no glyph instructions at all, just pixels. No text layer means nothing to convert. Any converter that returns an empty Word file for a scan without telling you is hiding the most important fact about your document. A good one says so explicitly: these pages contain no readable text; you need OCR, and OCR is a different product.

Even non-scanned PDFs carry image-shaped traps. Scanned-and-OCR'd hybrid files, fax archives and legacy systems often use JBIG2, a two-color bitmap format. If the conversion engine lacks a JBIG2 decoder, whole pages vanish from the output — again with no error, because the engine simply never receives the image.

The vanishing-Chinese problem: unembedded fonts and character maps

The most expensive defect in our test did not produce garbage. It produced nothing.

Many Chinese PDFs do not embed their fonts. Instead the font descriptor says "decode my character codes using UniGB-UCS2-H" — a predefined mapping table that lives outside the file, in the reader. If the conversion engine has that table, every character resolves. If it doesn't, font loading fails — and the failure mode is not an error message. The extractor hands back whatever the raw character codes look like, or nothing at all.

We measured this with a 32-page Chinese document. Before the fix, the converter extracted 459 words — page numbers and table-of-contents dots, essentially. After shipping the mapping tables (pdf.js loads them on demand from a cMapUrl directory), the same file produced 16,996 words. Thirty-seven times more text, from the same file, with no error message at any point in between.

Across the full 134-file batch, 4 documents had Chinese disappear this way — about 3%. In total 24,533 characters were rescued in those four files alone.

Two properties make this defect nasty:

• Word counts can't catch it. Garbage text still has length. The only reliable check is comparing actual content between two runs of the extractor — one with the tables, one without.
• Spot-checking can't catch it. In 134 files the defect appeared in 4. If you test five files at random, the odds of hitting one are under 15%. Only a full run reveals the pattern.

The mojibake nobody can fix — including Acrobat

A second, rarer failure looks similar but is fundamentally different. Some PDFs contain a CID font with no character map at all: the file never says which glyph number means which letter. The information does not exist. No converter can recover it, because there is nothing to recover.

This appeared in exactly 1 of our 134 files, and its signature is distinctive: on the same page, some lines convert perfectly while others come out as +$1*=+28. Different fonts on one page — one embedded with a mapping, one without.

If you hit this: it is not the converter's fault, and no competitor will do better. The PDF Association is explicit that PDF/A conformance level "b" guarantees visual reproduction only and does not require a Unicode mapping in embedded fonts. The usual sources are older toolchains — early Microsoft Office exports, LaTeX without CMap packages, LibreOffice before version 6. The only workaround anyone has, including Adobe Acrobat, is running OCR on the affected page. Knowing this saves you an afternoon of blaming your tool.

One more number worth knowing: the signature (a CID font without a mapping) appeared in 5 files, but only 1 produced actual garbage. A risky structure usually still converts fine through fallback paths. Judge by the extracted text, not by scary internals.

Three ways images disappear without a word

A 701-page, 41 MB mixed Chinese-English document taught us the image lessons. It contained 775 real images. Our converter's first pass extracted 253.

1. Undecodable formats. 500+ of the missing images were JPEG 2000, a format pdf.js does not ship a decoder for. Each failed image returned nothing, the code skipped it, and the counter never moved. The fix is shipping a WebAssembly JPEG 2000 module — but the deeper lesson is that a missing decoder is silent unless you instrument it. Count every image you fail to decode, and print the number.
2. Budget as a gate. Our first version spent a byte budget in document order: the first 400 pages consumed it entirely, so pages 501–643 had zero images in a 62 MB output file that "looked fine" by every other metric. A budget should divide, not gate — reserve proportionally for the pages you haven't reached yet.
3. Objects that never arrive. Some image objects in real PDFs are permanently broken — the object reference exists, the data does not. We used to wait 8 seconds per unreadable image. One file with 31 broken images took 252 seconds, almost exactly 31 × 8. After shortening the wait to a per-document ladder (generous first try, brief thereafter), the same file took 23 seconds — and the unreadable count was identical. Be suspicious of any speedup claim here: we did not rescue a single image. We stopped waiting for images that were never coming.

One broken page should not sink forty good ones

In a 20-page document, only page 2 was corrupt — a damaged compressed stream. The other 19 pages were fine. Our first implementation reported "conversion failed" for the whole file, because the error from that one page escaped and aborted everything.

The fix is per-page error isolation: count the failure, skip the page, keep going, and tell the user at the end — "2 of 20 pages were damaged and could not be read." Total failure should be reserved for the case where every single page failed, which usually means there was no text layer at all.

Words torn in half, and the search problem

The subtler failures corrupt individual words. Two mechanisms, both invisible:

• Ligature tearing. Some generators draw the fl in flight as a single ligature glyph from a different font, with a tiny position jump between them. The extractor reads the jump as a word space and produces fl ight. In a 96-page test document we counted 21 torn words on the first seven pages alone — flight, find, first, benefit. Every one became unsearchable in the resulting Word file, plus Word wraps the line where the fake space landed, which is how users usually notice.
• Letter-spacing. Wide-tracked text — answer blanks, justified lines — gets read as Q u a l i t y. The gaps between letters are real, but they are not word boundaries. Fixing this requires measuring whether the gaps actually occupy width; deleting them blindly merges everything into Themanfinished, which is worse.

Both are fixable in part. Ligatures that cannot end an English word (fi, fl, ffi) can be rejoined safely; ff and st can end words (off, first), so their tears are genuinely ambiguous and best left alone. Perfection is not on the menu — honest tooling tells you what it could not repair.

What survives, what doesn't

This is not an implementation shortfall unique to small tools — faithful restoration of columns and form fields is what desktop layout engines do, which is precisely why most online converters upload your file to a server. A browser-local converter trades those features for the guarantee that your document never leaves your machine. Decide which you need before you convert.

A 30-second checklist before you convert

1. Can you select the text? Open the PDF, try to select a sentence. If you can't, it's a scan — you need OCR, not a converter.
2. Is it Chinese or another CJK language? Unembedded CJK fonts are the classic silent-failure case. If the output comes back missing whole paragraphs of Chinese, the character maps were the problem — try a converter that bundles them.
3. Check both ends, not the middle. Skim the first page, the last page, and one page in the middle. Budget-gate bugs hide in the back half of long documents.
4. Ctrl+F for a word you can see. If flight exists on the page but not in the Word file's search, your words got torn — ligatures or letter-spacing.
5. Compare image counts roughly. A ten-page brochure should not produce a 60 MB Word file with three pictures in it.

The meta-lesson from 134 files: conversion failures are almost never loud. The converter that tells you "3 pages unreadable, 5 images undecodable, CJK character maps loaded" is worth more than the one that claims 100% success and hands you a quiet disaster. Demand the numbers.