Convert a Word document to PDF and the result is usually right. Sometimes it is not, and the failures follow a predictable pattern that is worth understanding before it costs you a deadline.
Two different kinds of file
A .docx is a zip archive of XML. It describes content and intent: this is a Heading 1, this is a paragraph, this table has three columns, this image is anchored here. How that becomes a page is decided by Word at the moment it renders, using its own layout engine, the fonts installed on the machine, and the selected printer’s page metrics.
A PDF describes the finished page: this glyph at this coordinate, this image in this rectangle. Nothing is decided at open time.
Converting one to the other means running a layout engine to turn intent into geometry. Word’s engine is a large, proprietary, decades-old body of software. Any other converter is a different engine, and the two will not agree in every case.
This is why the same DOCX converted by Word, by LibreOffice and by a web tool produces three subtly different PDFs. None of them is broken.
What converts reliably
For the great majority of documents (reports, letters, résumés, essays, manuscripts) conversion is faithful:
- Paragraphs, headings and their hierarchy
- Bold, italic, underline, strikethrough
- Bulleted and numbered lists, including nesting
- Simple tables
- Inline images
- Hyperlinks
- Page breaks
- Basic alignment and indentation
If your document is text with structure, it will convert cleanly.
What does not survive intact
The failures cluster around Word features that are about positioning and have little to do with content.
Text boxes and floating objects. A text box is positioned absolutely on Word’s canvas. Its content is often stored outside the main document flow entirely, so a converter reading the flow may place it differently or, in some tools, miss it. This is the single most common source of “my layout broke”.
Multi-column layouts. Newsletter-style columns depend on Word’s column-balancing behaviour, which is engine-specific.
Headers and footers. They are often reproduced, but page numbering fields, section restarts and different-first-page settings are frequently lost.
Complex tables. Simple grids convert well. Merged cells spanning both rows and columns, nested tables, and tables that break across pages are where things go wrong.
SmartArt and charts. These are live objects rendered by Office, not static images. Outside Office there is often nothing to render.
Tracked changes and comments. These are usually dropped, which is generally what you want but occasionally is not.
Fields. Table of contents, cross-references, page counts and dates are computed by Word. A converter may capture the last computed value, or nothing.
Exotic fonts. A font you installed locally is not available to a converter running elsewhere, and substitution shifts the layout.
What this site does, specifically
FileFinery’s Word to PDF route uses mammoth.js, which takes a deliberate approach worth being explicit about.
Mammoth converts semantics and leaves layout alone. It maps Word’s styles onto clean HTML
(Heading 1 becomes <h1>, a list becomes <ul>, bold becomes <strong>), and that HTML is
then laid out and rendered to PDF in your browser.
The consequence is a clear trade. You get a clean, well-structured, consistently typeset document with selectable text and no trace of Word’s quirks. You do not get a pixel-for-pixel photocopy of what Word displayed. Custom fonts, text boxes, precise absolute positioning and column layouts are not reproduced, because Mammoth deliberately does not attempt to reproduce them.
For a report, a letter, an essay or a manuscript this is the better outcome. For a designed flyer with text boxes and columns it is not, and for that document you should use Word’s own export.
We state this up front because a converter that quietly mangles a designed document is worse than one that tells you in advance which kind it is.
When to use Word’s own export instead
If the document has any of the following, export from Word (File → Save As → PDF, or File → Export → Create PDF):
- Text boxes or floating positioned elements
- Multi-column layouts
- SmartArt or charts
- Complex merged-cell tables
- Custom fonts that must be preserved exactly
- Anything designed rather than written
Word’s export uses Word’s own layout engine, so it is exact by definition. It is the right tool for its own hard cases.
Use a browser-based converter when you do not have Word, when the document is prose, or when you specifically do not want the file leaving your machine.
How to prepare a document so it converts cleanly
Use real styles. Apply Heading 1 and Heading 2 instead of manually bolding and enlarging text. Styles are semantic and survive conversion, while manual formatting is inconsistently interpreted. This also improves accessibility and gives you a working table of contents.
Use the list buttons and skip manual bullets and tabs.
Insert images inline and avoid floating them with text wrapping. “In line with text” is the setting that converts predictably.
Avoid text boxes for anything that is actually content.
Stick to common fonts (Calibri, Arial, Times New Roman, Georgia) or accept substitution.
Use page breaks, not rows of empty paragraphs, to start a new page.
Keep tables simple. If you need a complex table, consider whether it should be an image.
Formats we cannot convert, and why
- Legacy .doc is the pre-2007 binary format, structurally unrelated to .docx. Open it in Word or LibreOffice and save as .docx first.
- .pages is Apple’s format. Export as .docx from Pages.
- .odt is OpenDocument. Save as .docx from LibreOffice.
- .xlsx and .pptx are spreadsheets and presentations, whose layout models do not map onto a document page.
The checklist
- Prose document? Convert here for clean structure with nothing uploaded.
- Designed document? Export from Word.
- Use real styles instead of manual formatting.
- Inline your images.
- Check the result before it matters: page one and the last page.
- Keep the .docx. The PDF is only an output.
Convert at Word to PDF, or read what PDF actually is for why the translation is harder than it looks.