Why converting Word to PDF changes your layout, and how to get the same page every time
A Word document is not a description of a page. It is a description of content plus rules for laying it out — "this paragraph is 11-point Calibri with 1.15 spacing, keep with next, widow control on" — and the page you see is the result of an application applying those rules with the fonts and metrics it has available at that moment. A PDF, by contrast, is a description of a page: every glyph has a fixed position. Converting from one to the other means someone has to do the layout once, finally, and the result depends entirely on who does it and with what. That is the whole story of why the PDF does not look like your screen.
1. Font substitution: the biggest cause
When a document uses a font the converting machine does not have, the converter picks a replacement. Even a careful replacement has different widths: Calibri and Arial at the same point size differ by several per cent in average character width, so a line that fitted in Calibri wraps in Arial, the paragraph gains a line, the page gains a few lines, and by page five a heading has moved to the top of the next page. The text is identical; the geometry is not.
This is why a document converted on the author's machine usually matches the screen and one converted elsewhere often does not. Fonts bundled with Office (Calibri, Cambria, Aptos, Segoe) are not present on a Linux server, on most web-based converters or inside a browser, and get replaced. Fonts the author installed from a design library are not present on anyone else's machine either. The fix is to embed fonts in the source — Word: File → Options → Save → "Embed fonts in the file" — so the converter has them, or to convert on the machine that has them.
2. Different layout engines, different decisions
Even with identical fonts, two applications can lay out the same paragraph differently. Word's line breaking, hyphenation and justification differ subtly from LibreOffice's, which differ from Google Docs', which differ from a browser's. Table row heights, the exact spacing before and after headings, how a floating image pushes text, where a page break falls when "keep with next" and "widow/orphan control" conflict — each engine resolves these with its own rules. Across a long document the small differences accumulate into visible ones.
Word's own exporter (Save as PDF / Export) uses Word's layout engine and is therefore the only converter guaranteed to reproduce what Word showed you. LibreOffice opening a .docx re-lays it out with LibreOffice's engine; it is usually close, and for documents with complex tables or floating objects it is sometimes noticeably different. Browser-based converters, including ours, have a third engine again.
3. What our converter does, specifically
Being precise about this matters more than being flattering. Our Word-to-PDF tool reads the .docx with mammoth, a library that extracts the document's semantic content (headings, paragraphs, lists, tables, images, bold and italic) into clean HTML, deliberately discarding most direct formatting. That HTML is then laid out by your browser's rendering engine at a fixed A4 size, 11-point Arial-family text, and drawn into a PDF page by page. Everything runs on your device; the file is never uploaded.
The consequence is that the output is a faithful rendering of the content and a loose rendering of the design. Headings are headings, lists are lists, tables have their rows and cells, images are in place. But custom fonts become Arial, a document set in 10-point Garamond with tight margins will paginate differently, text boxes and floating shapes are flattened into the flow, and headers, footers and page numbers from the .docx are not reproduced. For a plain letter, a report, a CV without heavy design, an essay: the result is clean and readable and the text is selectable. For a brochure, a formatted contract with numbered clauses, or anything where the exact page break matters: use Word's own export.
4. Page size, margins and the printer driver
The third mechanism people rarely suspect: the target page. A document created on a US Letter default (8.5 × 11 in) converted by a tool that assumes A4 (210 × 297 mm) gets 18 mm more height and 6 mm less width. Text reflows; a page that was full is no longer full. "Print to PDF" through a printer driver is the classic offender, because it uses the driver's default paper, and so are converters with a fixed output size. Check the page size in the source before converting and make sure the converter honours it; if it does not, use one that does for anything where pagination matters.
Getting the same page every time
- Convert on the machine that has the fonts, with the application that made the document. Word → Export → PDF, or LibreOffice → Export as PDF for .odt originals. This is the only way to guarantee a match.
- Embed the fonts in the .docx if it will be converted elsewhere. Note that some commercial fonts have licences that forbid embedding, in which case Word embeds a substitute or nothing.
- Use "Save as PDF" rather than "Print to PDF". The exporter keeps text as text (selectable, searchable, small); the printer driver may rasterise or outline it and always uses the driver's paper size.
- Set page size and margins explicitly in the document. Defaults follow the locale of the machine the file was created on and change when it is opened elsewhere.
- Turn off "Update fields on open" for dates and table-of-contents fields if the converter re-evaluates them; a TOC that regenerates on a different engine can change its own length and shift everything after it.
- For a quick converter such as ours, accept the trade: content fidelity, not design fidelity, and check the first and last pages before sending.
The reverse direction is harder
Everything above is about producing a PDF from Word. Going the other way — PDF to Word — is a fundamentally different problem, because the PDF has already thrown away the rules and kept only the positions. A converter has to guess, from glyph coordinates, where the paragraphs were, which lines belong together, what was a table and what was merely aligned text. Our PDF-to-Word tool does this with pdf.js and reconstructs paragraphs; it works well on simple, text-heavy PDFs and progressively worse on designed ones. If you have the original .docx, it is always the better starting point than any PDF made from it.