Why Word to PDF Changes Your Formatting (and How to Stop It)

You converted a Word document to PDF and something moved. A font looks different, a paragraph fell onto a new page, an image shifted a few centimeters to the left, or the margins are suddenly wrong even though you never touched them. None of this is random, and it's not a bug in your copy of Word. Each of these has a specific, fixable cause, and most of them trace back to just three things: which export method you used, whether your fonts are embedded, and what paper size and printer your system currently has configured.

TL;DR: Word-to-PDF formatting breaks for a handful of specific, fixable reasons: unembedded fonts get substituted, Save As PDF and Print to PDF are structurally different export paths, and regional paper-size defaults can silently override your margins. Embedding fonts and using Save As PDF instead of a print driver fixes most cases before they happen.

Before digging into why any of this happens, run through three checks. Most Word-to-PDF formatting problems trace back to one of them, so start here rather than reopening the document and guessing.

Did you use Save As PDF/Export, or did you print to a PDF driver? These are not interchangeable, and the difference explains a lot of what follows.

What's your paper size set to right now? Open Layout > Size in Word before you export, not after. A silent switch from A4 to Letter (or the reverse) is one of the most common causes of shifted margins.

Are the fonts you used actually installed, or embedded, on the machine that will open the PDF? If a font isn't embedded and isn't installed on the reader's device, it gets swapped for something else, and that swap cascades into everything else on the page.

If one of those three doesn't check out, you've likely found your cause. The rest of this article explains why each one matters and how to prevent it going forward.

They are not, and treating them as interchangeable is where a lot of Word-to-PDF confusion starts. Word's built-in Save As PDF (or Export) uses a dedicated converter, while printing to a PDF driver routes the document through your operating system's print pipeline instead. The two produce visually similar output but structurally different files.

The practical difference shows up in what survives the conversion. One-button PDF creation tools are built to preserve document structure, bookmarks, converted hyperlinks, and cross-reference and footnote links, because they read the document's internal structure directly (Adobe Blog, 2006). A print driver, by contrast, only reproduces what would physically print. It has no concept of a hyperlink or a bookmark, only ink positions on a page, so interactive elements flatten down to their visual appearance alone.

That Adobe post is from 2006, and I couldn't find a more recent Adobe-authored source making the same point directly, but the mechanism it describes still matches how print drivers work today: a printer doesn't know what a hyperlink is, it only knows where ink goes. Several secondary sources covering PDF tools, including UPDF, Tungsten, and Office Watch, describe the same Save-As-versus-Print-to-PDF distinction consistently. I'm presenting this as reliable secondary-source consensus, not as a confirmed Microsoft-authored technical explanation, because no primary Microsoft source describing the internal difference between the two pipelines turned up in my research.

Given the pipeline difference, default to Save As PDF whenever it's available, and use a print driver only when you genuinely need to route the document through a physical or virtual printer for another reason.

Font substitution happens when a font used in your document isn't embedded in the exported file and also isn't installed on the machine opening it. Whether a font can be embedded at all is set by the font vendor, not by Word: fonts carry a license flag of Non-embeddable, Preview/Print, Editable, or Installable, and only the last two allow embedding (Microsoft Support).

Here's the underlying mechanism, stated plainly: formatting changes during Word to PDF conversion come from font substitution and the layout reflow it causes. If a font is not embedded in the output file, the converter replaces it with a metrically different one, which shifts line breaks and pushes content onto new pages. Embedding the fonts at export prevents this. The processing location makes no difference here: whether conversion happens on a server or in your browser, an unembedded font behaves exactly the same way.

That last point is worth sitting with. Where a converter runs has no bearing on whether a font substitutes. This isn't the kind of problem client-side processing solves, and I'd rather say that plainly than let a tool-promotion paragraph later in this article imply otherwise.

To embed fonts before exporting, go to File > Options > Save, check "Embed fonts in the file," and choose "Embed only the characters used" to keep the file size down. Be aware that embedding, especially of full character sets, can significantly increase file size depending on which font you've selected (Microsoft Support). One more small note for the format-curious: the current PDF core specification is ISO 32000-2:2020, the first version developed entirely under ISO rather than by Adobe alone (Mapsoft, 2020), and its archival sibling PDF/A goes further by mandating embedded fonts outright.

Font substitution is one of several causes covered here, not the whole story. The full breakdown of font substitution and PDF font embedding, including what to do about it once it's already happened, is a separate, deeper topic I've covered on its own.

A substituted font almost never has the exact same character width or line height as the one you designed the document around. That difference changes where each line wraps, and wrapped lines cascade into where pages break. This isn't a second, unrelated bug, it's a direct consequence of the font substitution covered above.

This connection is consistently reported across multiple community discussions on Adobe Community and Microsoft Q&A, rather than tracing to one single named study. Someone reports their document "looks fine" until page four, where a paragraph that used to fit suddenly spills onto a new page. Once you know font substitution is happening, that symptom stops being mysterious.

Most troubleshooting articles list "font problems" and "page break problems" as separate bullet points, as if they're unrelated. Treating them as one cause with two visible symptoms is a more accurate model, and it means fixing the font issue (embedding fonts before export) usually fixes the page-break issue too, without a separate step.

Word's default paper size is tied to the regional settings that were active when your default printer was originally configured, and it doesn't retroactively update just because you later changed your region or language settings. That's why a document authored on A4 can silently export at Letter size, shrinking your margins in the process.

I want to be specific about where this claim comes from. It's consistently reported across multiple Microsoft Q&A community discussion threads, including a thread on Word changing all printers to Letter even though regional settings are A4 and a second thread on Word still changing from A4 to Letter when printing, not from an official Microsoft support article. I'm not attributing this to Microsoft documentation, because there isn't one that describes the mechanism directly, only a pattern that a lot of users have independently run into and confirmed with each other.

The practical fix is to check Layout > Size in Word before you export, not just the margins afterward. If your paper size has silently switched, your margins will look wrong even though nothing in the margin settings themselves changed. This matters more than it sounds like it should if you're sending documents to a reader in a different region: a US recipient on Letter and a European recipient on A4 can both open the same PDF and see genuinely different page proportions if the export happened on the wrong default.

Yes, and this is the cause almost nobody checks. Word's layout calculations can reference whatever printer is currently set as your system default, even when you're exporting straight to PDF and never printing a physical page.

No competitor article on this topic surfaces this, and it's the strongest single finding in my research for this piece. In one well-documented Microsoft Q&A thread, a user's Word-to-PDF font and formatting problem was resolved by changing the default printer away from a dot-matrix driver, in an answer that collected more than 20 helpful votes, the most of any response in that thread (Microsoft Q&A). The same user separately noted that testing the file on a different laptop produced correct output, narrowing the cause to something specific to their original machine rather than the document itself.

If you've checked your fonts and your paper size and something still looks wrong, and especially if it's inconsistent between machines, open your system's printer settings and check what's actually configured as default. An old, unusual, or virtual printer driver can distort a layout calculation before a PDF is ever produced.

Images and text boxes anchored to a paragraph move with that paragraph. When font substitution or a paper-size change shifts where a paragraph sits on the page, anything anchored to it shifts along with it, which is why a photo that sat neatly beside a paragraph can end up overlapping the next one.

The fix is to set object positioning explicitly rather than leaving it to move with the text. For a floating image or text box, right-click it, choose Wrap Text or Layout Options, and set the position to "Fix position on page" instead of letting it stay relative to the paragraph. For tables, set the table's position properties to "Relative to page" rather than "Relative to paragraph" if you need it to stay put regardless of text reflow above it.

Worth a brief note on image quality while you're here: Word's default picture resolution is 220 ppi according to Microsoft's support documentation on reducing picture file size, and Office 2016 and later offers a "High fidelity" option with minimal compression, already the default in PowerPoint but not in Word or Excel, per Microsoft's support article on changing the default picture resolution. This is a general on-save compression default in Word, not a rule specific to PDF export, but it does carry through into whatever gets exported, so it's worth checking if your images look softer in the PDF than they did in the original document. Set it under File > Options > Advanced > Image Size and Quality.

If you're building a PDF from a set of images rather than converting an existing Word document, the anchoring behavior described here doesn't apply the same way, and combining images into a single PDF is a more direct route.

Everything above points to the same short checklist. Run through these before you export, rather than fixing the PDF afterward, and most of what breaks a Word-to-PDF conversion won't happen in the first place.

Embed your fonts. File > Options > Save > check "Embed fonts in the file." Do this before exporting, not after.

Confirm your paper size matches your reader's region. Layout > Size, checked before export, not just margins checked after.

Use Save As PDF or Export, not a print driver, unless you have a specific reason to route through your print pipeline.

Fix floating object positions to "Fix position on page" for images and text boxes, and "Relative to page" for tables, so they don't shift when text above them reflows.

Check your default printer if something still looks wrong and you can't explain it through fonts or paper size, especially if the same file looks fine on a different machine.

Once your document is set up this way, you can convert Word to PDF in your browser without a server upload step in between. That doesn't change any of the mechanisms above; a browser-based converter still substitutes an unembedded font exactly like a server-based one would. What it changes is that the document itself never leaves your device to get there.

If you're working the other direction and need to convert a PDF back to an editable Word file, the same underlying causes apply in reverse, and it's a big enough topic that I've covered converting the other direction, PDF back to Word, on its own.

Most Word-to-PDF formatting problems come down to three things: which export method you used, whether your fonts are embedded, and what paper size and default printer your system currently has set. None of them are bugs in Word or in whatever converter you're using.

Embed your fonts before exporting, every time, not just when something already looks wrong.

Check Layout > Size before you export, not just your margins afterward.

Use Save As PDF or Export rather than a print driver when you have the choice.

If nothing above explains it, check your default printer next. It's the cause almost nobody thinks to look at.

Run through the checklist above before your next export, and check the result against the same five causes. If something still looks wrong, you've likely found which one is yours.