Why Do Fonts Change in My PDF? Embedding, Subsetting, Substitution

PDF exists to solve exactly one problem: a document that looks identical no matter who opens it. So when you send a PDF and the recipient reports that the headings are in some other typeface, the layout has shifted and a line now runs onto a second page, it feels like the format has failed at its only job.

It has not. Something specific went wrong at export, and there are four candidates.

How PDF Is Supposed to Work

A PDF does not reference fonts by name and hope for the best. It embeds them — the actual glyph outlines are copied into the file. The reader draws the text using the shapes carried inside the document, not using anything installed on the computer displaying it.

That is why a PDF created on a designer’s machine with four licensed typefaces opens correctly on a machine that has none of them. The fonts travelled with the file.

Every failure below is a case where that embedding did not happen, or happened incompletely.

1. The Font Was Not Embedded

The most common cause. Many exporters offer an option to skip embedding — sometimes to reduce file size, sometimes because of a licence restriction, sometimes as a default nobody changed.

With no embedded font, the reader has to improvise. It looks at the font name recorded in the file, searches the local system, fails to find it, and substitutes something it judges similar. The result is your document set in a typeface you never chose, with every line a slightly different width.

The fix is at export time: find the setting, usually called “embed fonts”, and turn it on. Once a PDF has been created without embedded fonts, the original shapes are simply not in the file and cannot be recovered from it.

2. The Font Was Subsetted, and Then the Text Was Edited

Embedding an entire font is wasteful — a full CJK typeface can be several megabytes, and a two-page letter uses perhaps eighty distinct characters. So exporters subset: they embed only the glyphs the document actually uses.

This is almost always the right behaviour, and it causes no trouble until somebody edits the PDF. Type a character the subset does not contain — an accented letter, a currency symbol, a Chinese character that was not in the original text — and there is no glyph to draw. The editor either substitutes a different font for that one character or shows a box.

This is why edited PDFs so often have one word in the wrong typeface. The fix is to edit the source document and export again, rather than editing the PDF.

3. The Standard 14 Fonts

PDF defines fourteen typefaces that readers are expected to provide themselves — variants of Helvetica, Times, Courier, plus Symbol and ZapfDingbats. A PDF may reference these without embedding anything, and historically that was normal practice.

The trouble is that “provide Helvetica” means different things on different systems. One reader supplies real Helvetica, another supplies Arial as a stand-in, a third supplies something else again. The metrics differ slightly, so the text reflows and the line breaks move.

If a document’s appearance matters, embed even these. The size cost is small and the ambiguity disappears.

4. The Document Was Converted, Not Exported

There is a real difference between a program exporting directly to PDF and a document being passed through a conversion step — a web service, an email gateway, an office suite opening a file it did not create.

Each conversion is an opportunity for a font to be lost. An office suite opening a Word file whose fonts are not installed will substitute them on screen, and then faithfully embed the substitutes. The PDF is internally consistent and wrong.

This is also the usual explanation for a PDF that looks correct to you and wrong to the recipient when you both used “the same” conversion tool: your machine had the fonts, theirs did not.

Diagnosing It

Before fixing anything, find out what the file actually contains. A PDF records which fonts it uses and whether each one is embedded, and inspecting that answers the question immediately:

• Font listed, marked embedded → the file is fine; the problem is elsewhere, probably the reader.
• Font listed, not embedded → cause 1 or 3. Re-export with embedding on.
• Font listed as a subset (names often carry a six-letter prefix like ABCDEF+) → cause 2. Edit the source, not the PDF.
• A font you never used appears → cause 4. Something substituted before the PDF was made.

Preventing It

• Turn on font embedding in the exporter, once, and leave it on.
• Export straight to PDF from the program that created the document, rather than converting a converted file.
• Keep the source document. A PDF is an output, not a working format.
• Check the result on a machine that does not have your fonts installed — that is the only test that proves embedding worked.
• For documents that must be archival, export to PDF/A, which requires embedding and refuses to produce a file without it.

That last point is worth knowing even if archiving is not your concern. PDF/A exists precisely because “the fonts were not embedded” is the single most common way a PDF stops being a faithful record of what it was supposed to show.