What actually breaks when a Word file becomes a PDF — our test results

Most advice about Word-to-PDF conversion is written from the outside: general tips about what tends to go wrong. We built a converter, then spent a long time feeding real documents through it to find out what breaks in practice.

Some of it matched expectations. Two results didn't, and one of them we had wrong for weeks.

This is the testing log rather than a how-to. If you want the checklist for preparing a document before you convert it, that's in our guide on converting Word to PDF without losing formatting.

Hindi text converted to invisible boxes

A Devanagari document came out looking empty. Not garbled. Blank rectangles where the text should be.

The odd part: the text was still there. Copy it out of the PDF and it pasted back correctly. The characters had been embedded; they simply had no glyphs to render with, because mPDF's default font has no Devanagari coverage.

Passing a default font option to the renderer did nothing. It took a while to work out why: PHPWord's HTML writer hardcodes body{font-family:'Arial'}, which overrode it every time.

Detecting Devanagari in the source file and setting the font explicitly fixed it, though the ordering turned out to matter more than the fix itself. PHPWord's Word2007 reader re-applies the source document's own default font while loading, silently undoing anything set beforehand. The font has to be set after the document loads, not before.

This is the kind of failure worth knowing about generally: text that converts correctly but renders invisibly looks identical to text that was dropped. If a converted PDF looks empty, try selecting the text before assuming the conversion failed.

Arabic worked with no special handling

We assumed right-to-left text would need a similar fix, and said so in an earlier version of our guide.

It didn't. Arabic converted and rendered correctly straight away, with correct glyph shaping, correct direction, and no intervention. We'd flagged it as a likely problem based on the Devanagari result, and testing showed the assumption was wrong.

We mention this because the guess was published before it was checked, which is exactly the thing this site tries not to do.

Bullets and numbers disappeared entirely

Lists converted as plain paragraphs. No bullets, no numbers, indentation gone.

PHPWord's DOCX reader is the cause: it discards list formatting when reading a document back. The numbering data is present in the file, stored in the DOCX's own numbering XML, but the reader doesn't carry it through.

Our fix reads that numbering XML directly and writes the correct bullet or number into the text as literal characters before PHPWord sees the file at all.

One limitation is still open, and we'd rather name it. Nested lists built from separate named styles ("List Bullet" followed by "List Bullet 2") get the correct bullet at both levels but not distinct indentation between them. The content is right, the visual nesting isn't.

What held up without any trouble

Not everything broke. From the same testing round:

• A realistic resume with mixed formatting converted cleanly
• Clickable hyperlinks stayed clickable in the output
• A 60-page document with explicit page breaks kept its pagination
• An oversized 4000×3000 pixel image converted without failing or blowing up the file

That last one mattered because large embedded images are a common cause of conversion failures elsewhere.

The three things that change most often

Across everything we ran, problems clustered into three areas, and the pattern holds regardless of which converter you use:

Fonts. A PDF has to embed or substitute every font. If the converter lacks the font your document uses, it picks something else, and the substitute almost never has identical metrics. Text reflows, line counts shift, and a one-page document becomes two.

Tables. AutoFit column widths are the single most common cause of table breakage across every source we checked while researching this. AutoFit is a layout instruction that gets resolved differently by different renderers. Fixed widths are not.

Fields. Page numbers, tables of contents and cross-references are calculated values. If they were last calculated before your final edits, the PDF freezes whatever they said at that moment. Refreshing them first (Ctrl+A, then F9) avoids it.

Why this is the one tool here that uploads your file

Everything above explains why Word to PDF is the only tool on this site that needs a server.

DOCX is an enormous format with decades of accumulated edge cases, and interpreting it reliably in a browser isn't realistic today. That conversion runs server-side, and the file is deleted immediately after you download the result. We say so on the tool page itself.

Every other tool here runs entirely in your browser — merging, splitting, extracting pages, removing pages, reordering, rotating, page numbers, watermarks, cropping, metadata, page size checks and images to PDF. Those operations rearrange a PDF's existing structure rather than interpreting a foreign format, so there's nothing a server does that your browser can't.

We've written separately about where the browser-only approach hits its limits, including the features we decided not to ship because of them.

If your conversion came out wrong

Check in this order, because it's roughly the order of likelihood:

1. Select the text in the PDF. If it selects but doesn't display, it's a font coverage problem, not a lost conversion.
2. Compare page counts. A change usually means font substitution reflowed the text.
3. Look at tables before anything else — they fail more often than body text.
4. Check page numbers and any table of contents against the real content.

Our pre-conversion checklist covers how to avoid most of this before you convert, and the page size checker will tell you if the output ended up on a different paper size than you expected.