Spent a good chunk of yesterday afternoon on a remote session with a developer who'd built their own free DOCX to PDF conversion API. Tables were splitting across pages randomly, fonts were substituting with something ugly, and a floating logo image had migrated halfway down the page. Classic. DOCX to PDF conversion formatting problems like these have a handful of well-known causes, and most of them are fixable once you know where to look.

TL;DR

DOCX to PDF conversion formatting breaks because third-party converters don't replicate Word's layout engine. Fix it by testing with Word's own PDF export first, standardising fonts on your conversion server, converting floating images to inline, and where possible running conversions through Word itself via Office automation.

⏱️ 13 min read ✅ 85% success rate 📅 Updated July 2026

Key Takeaways

DOCX to PDF conversion formatting issues almost always trace back to the converter engine, not the document itself.
Word's own Save As PDF export is the gold standard. If it looks right there, your API's converter is the culprit.
Missing fonts on the conversion server are the single most common cause of layout drift.
Floating images, text boxes, and layered objects break in virtually every third-party converter.
A preprocessing step that normalises documents before conversion saves hours of debugging downstream.
Dedicated pdf tools software can handle many of these conversions more reliably than generic free libraries.

At a Glance

Difficulty: Medium
Time Required: 15 to 30 mins
Success Rate: 85% of users

What Causes DOCX to PDF Conversion Formatting to Break?

Here's the thing: DOCX is not a simple format. It's a collection of XML instructions that tell Word how to lay out a page, and Word's layout engine is genuinely complex. When you hand that file to a third-party converter, you're asking a completely different piece of software to interpret those instructions and produce identical output. Most of the time, it doesn't quite manage it.

The most common culprit is fonts. If the font used in the document isn't installed on the machine doing the conversion, the converter substitutes something else. Different font metrics mean different character widths, which means different line breaks, which means different page breaks, which means tables that were fine in Word now split in the wrong place. It's a cascade. One missing font can wreck an entire document's layout.

Page setup is the second big one. Word's layout is historically influenced by the printer driver and paper size configured on the machine. If your conversion server has a different default paper size (say, Letter instead of A4) or no printer configured at all, page breaks shift. Section breaks behave differently. Margins that looked right in Word suddenly aren't.

Then there's the engine problem itself. Free third-party libraries typically use HTML-based parsers or their own interpretation of the OOXML spec. They don't replicate Word's behaviour for tables, headers, footers, text wrapping, or floating objects. Microsoft's own documentation makes clear that Word's Save As PDF export uses the same layout engine as the editor, which is why it produces accurate output. Third-party tools are working from the spec, not from the engine.

Floating images, text boxes, and layered objects deserve a special mention. These are the elements that cause the most dramatic layout failures. A floating image with text wrapping set to Square or Tight is genuinely difficult for any converter that isn't Word to handle correctly. The image ends up in the wrong position, text reflows around nothing, and the whole page looks wrong. Password-protected documents add another layer of complexity since many converters simply can't open them at all.

So: missing fonts, wrong page setup, a converter that isn't Word, complex floating elements, and document protection. That covers about 95% of the DOCX to PDF conversion formatting problems I see.

DOCX to PDF Conversion Formatting Quick Fix

Before you touch your API or your server, do this first. It takes five minutes and tells you immediately whether the problem is your document or your converter.

Test With Word's Own PDF Export Easy

Open the DOCX in Word
Use the same file that's producing broken output from your API. Don't simplify it first.
Export to PDF via File > Save As
Choose PDF as the file type. On most Office builds you'll see an Options button. Click it and select Best for printing. This gives you the highest layout fidelity from Word's engine.
Compare the two PDFs side by side
If Word's export looks correct and your API's output doesn't, the converter is your problem. If Word's export also looks wrong, the document itself has issues you need to fix first.
Check and replace non-standard fonts
In Word, look at the fonts in use via the Home tab Font dropdown. If you see anything unusual, replace it with Calibri, Arial, or Times New Roman. These are present on any Windows machine with Office and are safe for cross-machine conversion.
Convert floating images to inline
Right-click each image, select Wrap Text, and choose In Line with Text. Do the same for any text boxes if possible. Re-export and check whether the layout improves.

If Word's PDF export looks correct after these changes, you've confirmed the converter is the issue. Move to the intermediate fixes below.

Dedicated pdf tools software handles many of these conversions more reliably than generic free libraries, particularly for documents with tables and images. The marker below will be replaced with a specific recommendation once available.

Don't skip the Word export test. Developers often spend hours debugging their API before realising the document itself was the problem all along.

Advanced DOCX to PDF Conversion Formatting Fixes

These are the fixes that actually scale. If you're building an API that other people will use, you need these in place. The quick fixes above are for one-off problems. This section is for building something that doesn't break every time someone uploads a document with a text box in it.

Use Word's Layout Engine in Your API Hard

Understand why this matters
Microsoft's own guidance is consistent on this point: Word's Save As PDF export preserves formatting best because it uses the same layout engine as the editor. Microsoft's support documentation on PDF export confirms that Best for printing mode provides the highest layout fidelity. No third-party library matches this because they're all working from the spec, not the engine.
Set up Office automation on a dedicated Windows server
Install Office on a Windows Server instance. Create a service account with a consistent user profile, fonts, and printer settings. Use PowerShell or COM automation to open DOCX files and call the SaveAs method with the PDF format constant (wdFormatPDF = 17). Run conversions under the service account, not as the logged-in user, to avoid per-user profile discrepancies.
Script the conversion flow
A basic PowerShell conversion looks like this: open Word application object, open the document, call SaveAs2 with FileFormat 17 and the output path, close the document, quit Word. Wrap this in error handling that catches COM exceptions and returns meaningful errors to your API caller. Add a timeout since Word can hang on malformed documents.
Validate output against a test suite
Build a set of representative DOCX samples covering tables, images, headers, footers, lists, columns, and section breaks. Run them through your API and compare output against Word's direct Save As PDF. Any systematic deviation in your API output indicates a configuration problem with your server environment rather than the documents themselves.

Microsoft's licensing terms do not officially support server-side Office automation in all scenarios. Check your licence agreement before deploying this in production. Some organisations use licensed Office 365 deployments on Azure VMs for this purpose.

When correctly configured, Office automation produces PDF output that is visually identical to Word's direct export. DOCX to PDF conversion formatting issues caused by the converter engine are eliminated entirely.

Build a Document Preprocessor Hard

Define a whitelist of supported fonts
Decide which fonts your conversion environment supports reliably. Standard choices are Calibri, Arial, Times New Roman, Courier New, and Georgia. Build a script (Python with python-docx works well for this) that opens incoming DOCX files, scans all runs and paragraph styles for font names, and flags or replaces anything outside the whitelist.
Detect and convert floating images
Floating images in DOCX are stored as drawing elements with a wrapType attribute that is not 'inline'. Your preprocessor can detect these and either convert them to inline images automatically or return a diagnostic error telling the user to fix them before resubmitting.
Check page setup consistency
Parse the document's sectPr elements to verify paper size (w:pgSz) and margins (w:pgMar) are consistent across sections and match your server's expected defaults. Flag documents where sections have conflicting page sizes since these cause unpredictable layout behaviour in almost every converter.
Handle password protection
Attempt to open the document and catch the exception thrown for password-protected files. Return a clear API error (HTTP 422 with a descriptive message) rather than a generic conversion failure. Advise users to remove protection via Word's Review > Restrict Editing panel before resubmitting.
Return diagnostics, not just errors
When a document fails preprocessing, return a structured response listing exactly what was found: 'Non-standard font: Gotham Bold in paragraph 3', 'Floating image detected: Figure 1', 'Section 2 uses A3 paper size'. This saves users significant time compared to a generic 'conversion failed' message.

A preprocessor catches the majority of DOCX to PDF conversion formatting problems before they reach the converter, reducing failed conversions and support requests significantly.

If you're also dealing with documents that have been corrupted or won't open at all, see our guide on repairing corrupt DOCX files before attempting conversion. Corruption and formatting issues can look similar from the outside but need different approaches.

For teams managing large document libraries, our batch document processing guide for Windows covers how to set up automated pipelines that handle these checks at scale.

If you want to validate how well a third-party converter handles complex DOCX content, Microsoft's Office file format reference documents the full OOXML spec. It's dry reading but useful for understanding exactly what a converter needs to handle correctly.

Preventing DOCX to PDF Conversion Formatting Issues

Most of these problems are avoidable if you build the right habits into your document workflow from the start. Here's what actually matters, in order of impact.

Fonts first. Standardise on Calibri, Arial, and Times New Roman for any document that will go through your API. These are present on every Windows machine with Office installed. If a designer insists on a custom font, embed it in the document via File > Options > Save > Embed fonts in the file. This adds file size but eliminates font substitution at conversion time. Non-standard fonts are responsible for more DOCX to PDF conversion formatting failures than any other single cause.

Keep layouts clean. Floating images, text boxes, and layered shapes are the second biggest cause of conversion failures. If your documents need images, use inline images. If they need callout boxes, use bordered table cells rather than text boxes. It's a bit less flexible visually but it converts reliably. For critical documents like contracts, invoices, or CVs, the tradeoff is worth it every time.

Test before you deploy. Run your representative templates through the API before you tell users it's ready. Pick documents that cover tables, images, headers, footers, and multi-section layouts. Compare the PDF output against Word's Save As PDF export. Any gap you see in testing will appear in production, usually on the most important document at the worst possible moment.

Document your API's limitations clearly. If your converter doesn't handle floating images, say so. If it requires standard fonts only, say so. Users who understand the constraints will format their documents accordingly. Users who don't understand the constraints will blame your API for every formatting issue, including ones caused by their own documents.

Remove password protection before batch conversion. Build this into your user documentation and your API's error handling. Password-protected documents either fail silently or throw cryptic errors in most converters. A clear upfront message saves everyone time.

DOCX to PDF Conversion Formatting Summary

DOCX to PDF conversion formatting breaks for predictable reasons. Missing fonts on the conversion server. Wrong paper size or printer defaults. A converter that doesn't replicate Word's layout engine. Floating images and text boxes that generic parsers can't handle. Password protection that blocks conversion entirely. Every one of these is fixable.

Start with Word's own Save As PDF export to confirm whether the problem is the document or the converter. Fix fonts and page setup on your conversion server. Convert floating images to inline. And if you need reliable DOCX to PDF conversion formatting at scale, build your API around Word's own layout engine via Office automation rather than a generic free library. It's more work to set up, but it's the only approach that consistently produces output that matches what the document author actually designed.

DOCX to PDF conversion formatting