PDF Fonts Look Wrong After Converting? Here's the Fix

If your PDF's fonts look wrong after converting, that's a different problem from a PDF that won't open at all. If the file opens fine but the text inside it looks like the wrong typeface, shows blank boxes, or renders symbols and checkboxes as random characters, the cause is almost always something happening to the fonts themselves, not damage to the file. That's true whether you converted Word to PDF, PDF to Word, Excel or PowerPoint to PDF, or a PDF to the archival PDF/A format.

TL;DR: a font that looks substituted, boxed, or garbled after converting almost always comes down to embedding. The font wasn't embedded in the file, was only partially embedded, or isn't installed on the machine displaying it. Converting to PDF/A can force the exact substitution you were trying to avoid, because PDF/A makes embedding mandatory with no exceptions. The diagnostic table further down narrows down which of these is yours.

This is also one of the more persistently reported PDF complaints there is. A single Adobe Community thread on font changes during Word-to-PDF conversion has run since March 2017 and passed 318,000 views, which tells you how common the complaint is, not what's causing it in any specific case (Adobe Community).

Answer three questions before troubleshooting further, because they narrow down which cause below is actually yours. Is the font a different typeface but still readable, or actual boxes and garbage where letters should be? Does it look wrong on every machine, or only some? And did the problem start at conversion generally, or specifically when you converted to PDF/A?

A different but readable typeface means substitution: the PDF is showing you an actual letter, just not the one you designed the page around. Boxes or garbled characters mean something more specific, either a missing glyph in whatever font is being used, or a symbol font whose character codes are being read by the wrong text font entirely.

If the same file looks correct on your computer and wrong on someone else's, that's viewer-side substitution, covered next. If it looked fine until you specifically ran it through a PDF/A converter, skip ahead: that's a distinct, mandatory-embedding cause covered further down, and it's usually the fastest one to confirm.

A font gets replaced with a different typeface when it isn't embedded inside the PDF and also isn't installed on the machine opening the file. The viewer has no copy of the original font to draw from, so it substitutes whatever it has available, and that substitute rarely shares the same character widths as the font you actually used.

Whether a font can be embedded at all isn't up to the software doing the converting. It's a license flag the font's own vendor sets: Non-embeddable, Preview/Print, Editable, or Installable, and only the last two actually permit embedding. I covered where those flags come from and how to check them in the general causes of Word-to-PDF formatting problems, so I won't repeat that here.

When embedding is allowed, most conversion tools embed a subset of the font, only the characters actually used in the document, rather than the whole thing. You can spot a subset-embedded font in a font inspector or in Acrobat's Properties > Fonts panel: its name carries a six-letter prefix and a plus sign, something like ABCDEF+Calibri, and mixing files that contain different subsets of the same font can cause missing or swapped characters when those files get merged.

Embedding itself wasn't always an option either: before Acrobat 4.x, the standard fonts, including Symbol and ZapfDingbats, couldn't be embedded at all, and full embedding has been considered good practice since (Prepressure.com).

That subsetting is also why editing text in a PDF, adding a sentence in a font that was only partially embedded, can trigger the exact substitution you were trying to avoid: the character you just typed may not exist in the subset that actually got embedded.

An empty box in place of a character, informally called tofu, shows up when the font actually being used, embedded or not, simply has no glyph defined for that character. This is a missing-character problem, distinct from substitution above, which still shows you a letter, just the wrong one.

It shows up most with accented letters outside a font's covered character set, uncommon symbols, or a symbol font that's missing entirely, so the viewer has nothing to draw the character from at all. It's a narrower font, not a missing font, so the fix is usually to use a font that actually covers those characters, or to embed the specific font that was used to type them in the first place.

Worth keeping straight: substitution changes which typeface you're looking at. Tofu means there's no glyph there at all, from any typeface, for that specific character.

Fonts used for CJK and other complex scripts don't map characters the same simple way Latin fonts do. They use a CID-keyed addressing model instead, and getting that wrong produces a specific, different failure than plain substitution: a document that renders correctly in one viewer and garbled in another, from the exact same file. CID-keyed fonts must be both embedded and subset correctly to render reliably (Datalogics Knowledge Base, 2024).

A real bug report from Mozilla's pdf.js project shows exactly how this breaks. A font's embedded data was declared as CIDFontType2, the TrueType-based CID format, but the actual data inside it was OpenType and CFF instead.

pdf.js prioritized the CFF charset over the declared mapping, and the result rendered correctly in Chrome's own PDF renderer while showing garbled glyphs in pdf.js and Adobe Reader, all from the identical file (Mozilla pdf.js, GitHub Issue 18062, opened May 2024).

The lesson isn't that any one viewer is broken. A CID font's internal declaration and its actual content have to agree, and when a conversion tool gets that wrong, the failure is inconsistent by nature: correct in one app, garbled in the next, with nothing visibly different about the file until you open it somewhere else.

Symbol fonts like Wingdings break differently again, and it's worth understanding why. They work by mapping ordinary character codes, the letter a, the number 3, to a picture instead of a letter.

If that font gets substituted for a different one, the viewer still has a character code to render, so it draws whatever letter or number that code maps to in the substitute font. That's why a bullet or checkbox can turn into a random letter instead of just disappearing: the code was never missing, only the font mapping it to a symbol was.

Every Office application has its own font-embedding setting, and they don't all default the same way, so a fix that works in Word doesn't automatically carry over to a PowerPoint deck or an Excel export.

PowerPoint has its own font-embedding setting, separate from Word's, and Office applications in this family generally distinguish between embedding only the characters used versus embedding the full character set, though I haven't confirmed that's PowerPoint's exact current behavior.

I'm not going to give you an exact current menu path here, because Microsoft's interface shifts between versions and I haven't independently verified it against a live support page for this article. Check your version's Options or Preferences area for a save-related font setting, and look for an explicit embed-fonts checkbox before exporting.

Excel font-substitution issues get reported too, generally tracing back to the same embedding mechanism rather than anything Excel-specific. The fix is the same one regardless of which Office app you started in: confirm the fonts are actually embedded before you export to PDF.

PDF/A requires every font used in a document to be embedded, with no exceptions, even for the fourteen standard PostScript fonts, Times, Helvetica, and the like, that an ordinary PDF can reference by name without embedding at all. Every version of the standard, PDF/A-1 through PDF/A-4, prohibits external font references outright (Wikipedia, citing ISO 19005).

That's why a PDF/A conversion can produce exactly the substitution problem you were trying to avoid. If the original font's license flag doesn't permit embedding, the converter has no legal way to include it, and either substitutes a different font or produces a file that technically isn't PDF/A-conformant despite claiming to be. It's the same license-flag mechanism from earlier; PDF/A just removes the option of skipping embedding the way an ordinary PDF export can.

If you need an archival-format file and want to know whether this is going to bite you, converting a PDF to the archival PDF/A format is worth doing early rather than as a last step, so you can catch a forced substitution before the file is the one you're actually relying on for long-term storage.

Match what you're actually seeing against the table below to jump straight to the fix, instead of working back through every cause above one at a time. Find your symptom in the left column, the likely cause in the middle, and the fix on the same row.

One row worth flagging on its own: ligature loss, where fi, fl, and ff render as gaps, is something Adobe Community contributors consistently attribute to incomplete embedding or a source font that never had ligature glyphs to begin with, not something Adobe's own documentation states directly (Adobe Community).

Embed your fonts before you export, not after, and then verify the result instead of assuming it worked. A font problem you catch before sending a file is a two-minute fix in the source document; the same problem discovered by whoever you sent it to is a much worse conversation.

For a Word, PowerPoint, or Excel file heading to PDF, checking that the fonts are actually embedded before you export is the single highest-leverage step, regardless of which app produced the original file. Once that's done, you can convert Word to PDF in your browser without a server upload step in between. The file is processed on your device, so a contract or ID document with embedded fonts never has to leave it to get converted.

The same logic runs in reverse. If you're converting a PDF back into editable Word and the fonts look wrong once you're inside it, the cause is usually whatever was or wasn't embedded in the source PDF. I've covered converting a PDF back to Word without losing formatting as its own, deeper topic.

If the problem isn't a missing embed at all but a genuinely damaged file, a corrupted font table inside a PDF that used to display correctly, that's a different fix. A tool built to repair a PDF with a damaged font table can recover a file like that, though it can't add a font that was never included in the first place.

There's one more fix worth knowing about, even though it isn't something a browser-based converter does. Professional print and design software offers a way to make a font problem disappear for good: converting the text to outlines. Adobe Illustrator and InDesign call this Create Outlines, CorelDRAW calls it Convert to Curves, and Acrobat Pro buries a version of the same thing inside its Preflight fixups, listed as Convert fonts to outlines.

Outlining turns each character into vector artwork, line and curve shapes that happen to look like letters, instead of a reference to a font file. Once that's done there's no font left to substitute, no license flag to worry about, and no embedding decision to get wrong, because the page no longer contains a font at all, just shapes.

It's also destructive and effectively irreversible: the text is no longer text, only shapes that resemble letters. Longtime Adobe engineer Dov Isaacs laid out the real costs in an Adobe Community thread on the subject: loss of a font's built-in hinting, which often shows up as overly bold printed output, larger file sizes, and slower performance at the print RIP stage. His own advice was blunt: avoid print vendors who require outlined text, rather than treat outlining as routine.

I'd add the obvious consequence Isaacs doesn't spell out there: once the text is outlines, there's no font reference left, only vector shapes, which is why the result can't be searched, selected, or read by a screen reader. That's my own conclusion from how outlining works, not a claim from that thread.

It's the same underlying failure the W3C describes for scanned document pages treated as text, in its accessibility guidance on PDF techniques: without real characters behind what you see, there's nothing for a search, a copy command, or assistive technology to reach.

This isn't something you'd do from a browser-based converter, and JoyPDF doesn't offer it among its conversion tools. It's what a professional print vendor or designer may already be doing when a font problem has to disappear permanently and nobody needs the file to stay editable afterward. For anything you're actually sending someone to read, search, or edit, it's the wrong fix, and embedding the real font is still the right one.

Everything above comes down to one question: does the font exist somewhere the PDF can reach it, embedded in the file or installed on whatever machine opens it, or doesn't it? Substitution, boxes, garbled symbols, and a PDF/A conversion that suddenly looks different all trace back to that same question.

Check whether you're seeing a different typeface or empty boxes before you start troubleshooting. They're different problems with different fixes.

Embed your fonts before you export, not after. It's the fix behind almost everything in this article.

If the problem started specifically when you converted to PDF/A, that's mandatory embedding forcing a substitution the original file didn't have, not a new bug.

The six-letter-plus-sign tag on a font's name in a font inspector, something like ABCDEF+Calibri, tells you it's subset-embedded. That's a real diagnostic you can check yourself in about ten seconds.

If you've got a document open right now with a font that looks wrong, go back to the source file, embed the fonts properly, and reconvert it before you send it anywhere else. Catching it there is faster than explaining it later.