Fonts Changed After PDF Conversion: Causes and Fixes

PDF files handle fonts in one of two ways: embedding or referencing. An embedded font means the actual font data — the outlines of every character — is stored inside the PDF file. A referenced font means the PDF only stores the font name and expects the viewer's operating system to provide the matching font file. Embedded fonts always look identical regardless of which device opens the PDF. Referenced fonts look different on every device, depending on what's installed. When you convert a Word document to PDF on your own machine using Microsoft Word's built-in export, fonts are almost always embedded correctly because Word has access to the fonts you used. The problem begins when you send the document to a conversion service, or when someone else opens your Word file on a machine that doesn't have your fonts installed. HTML-to-PDF conversion is even more prone to font problems. Web fonts loaded via Google Fonts or self-hosted WOFF files are fetched over the network at render time. If the conversion tool renders the HTML in a sandboxed environment without internet access, Google Fonts URLs return nothing, and the browser falls back to the system's generic serif or sans-serif font — which is usually Times New Roman or Arial. Custom brand fonts are the highest-risk scenario. If your organization uses a licensed typeface that isn't installed on the server performing the conversion, the converter has no choice but to substitute it. The substitute is typically chosen based on font metrics — the converter looks for a font with similar character widths so line breaks don't shift too dramatically, but the visual result is completely different.

The most reliable way to preserve fonts in Word-to-PDF conversion is to embed the fonts directly in the Word file before conversion. When fonts are embedded in the source document, any converter that reads the file can extract the font data and embed it in the resulting PDF, regardless of what's installed on the conversion system. Microsoft Word supports font embedding natively. You can enable it in the Save Options dialog, which ensures the font data travels with the document everywhere it goes. When you then export to PDF, Word's PDF exporter sees the embedded fonts and includes them in the output. For online conversion tools, the key test is whether the tool preserves embedded fonts from the source document. LazyPDF's Word to PDF conversion uses LibreOffice, which respects embedded font data in DOCX files and passes it through to the PDF output. If your Word file has fonts embedded and the conversion output still shows substitution, the problem is that the fonts were not actually embedded in the Word file — they were only referenced.

1. 1Step 1 — Embed fonts in your Word file before converting: In Microsoft Word, go to File → Options → Save. Check 'Embed fonts in the file' and also check 'Do not embed common system fonts' to keep file size reasonable. Save the document, then convert to PDF.
2. 2Step 2 — Use Word's native PDF export, not a PDF printer: Go to File → Export → Create PDF/XPS. This uses Word's built-in PDF generator which has direct access to all loaded fonts and embeds them correctly. Using 'Print to PDF' via a virtual printer driver often does not embed fonts reliably.
3. 3Step 3 — Verify font embedding in the output PDF: Open the resulting PDF in Adobe Acrobat Reader, go to File → Properties → Fonts tab. Every font should show 'Embedded Subset' or 'Embedded' next to its name. If any font shows no embedding note, that font is referenced and may substitute on other systems.
4. 4Step 4 — For persistent substitution, convert problem text to outlines: If a specific font cannot be embedded (licensing restrictions on some commercial fonts prohibit embedding), select all text using that font in your source application and convert it to vector outlines (curves) before exporting. Outlined text has no font dependency — it's stored as shapes and looks identical everywhere.

HTML-to-PDF conversion has a unique font challenge: web fonts loaded from external URLs. When you design a webpage using Google Fonts, the fonts are fetched at render time from Google's CDN. This works perfectly in a browser because browsers have unrestricted internet access. Conversion tools that render HTML in a headless browser environment may or may not have access to external URLs, depending on how the tool is configured. The most reliable solution for HTML-to-PDF font preservation is to serve fonts locally within your HTML rather than loading them from a CDN. Instead of a Google Fonts link tag, embed the font data as a base64 data URI directly in the CSS. This makes the font completely self-contained — no network requests required during conversion. Alternatively, if you have the font files, you can use @font-face rules that reference local font files alongside the HTML. When the HTML and font files are in the same directory structure during conversion, the tool can load them without any network access. For system fonts (Arial, Helvetica, Georgia, etc.), the problem is different: these fonts are typically available on conversion servers. The issue is usually that CSS is not being applied correctly — perhaps due to missing stylesheets, CORS errors on external CSS files, or the conversion tool using a different viewport size that triggers different responsive CSS rules. Always test your HTML-to-PDF conversion with inline CSS rather than external stylesheets to rule out stylesheet loading as the cause.

Not every visual difference after PDF conversion is a font substitution problem. Before assuming fonts have changed, rule out these other common causes that produce similar-looking symptoms. Line spacing differences can make the same font look like a different font because different spacing alters the texture of text blocks dramatically. This is usually caused by a line-height CSS property not translating correctly to the PDF page model, or by Word's paragraph spacing settings conflicting with the PDF generator's spacing calculations. Kerning and ligature differences are common when converting between applications that handle OpenType features differently. Your original design might use OpenType ligatures (combined character shapes like 'fi' and 'fl') that the PDF converter doesn't support. The individual characters are technically the same font, but the ligatures are missing, making the text look slightly different. Missing glyph issues — where characters appear as boxes, squares, or question marks — are a sign of a different problem: the font is present but the specific character (often a special symbol, diacritic, or Unicode character outside the font's supported range) is not included in the font subset. The fix is to either use a font with full glyph coverage or switch to Unicode-complete alternatives like Noto fonts for multilingual content. True font substitution — where an entirely different typeface is used — is most obvious in headings and large text where the letterforms are clearly different. Confirm substitution by checking the Fonts tab in Acrobat's document properties.