You export a PDF, it looks perfect, you send it, and the recipient sees Times New Roman where your display face should be, with the line breaks in different places and a heading that now runs to three lines. The file is not corrupted. The font simply was not in it.
How fonts get into a PDF
A PDF can handle a typeface in one of three ways, and which one applies decides whether the file survives the journey.
| Method | What happens | Risk |
|---|---|---|
| Fully embedded | The complete font is inside the file | None — largest file |
| Subset embedded | Only the glyphs actually used are included | Breaks if the text is later edited |
| Referenced only | The file names the font and expects the reader to have it | Substitution on any machine without it |
Subsetting is the default in most export pipelines and is usually the right choice. The failure mode is specific: if someone edits the text afterwards and types a character that was not in the original subset — an accented letter, a currency symbol, a different dash — there is no glyph for it, and it renders as a blank or a box.
What substitution actually does to a layout
When a reader cannot find a referenced font, it substitutes a metrically similar one. “Similar” is doing a lot of work there: different advance widths mean every line breaks differently, which changes paragraph depth, which pushes content onto different pages. A one-page document becomes two; a carefully set table overflows its column.
This is why the problem so often appears as “my layout is broken” rather than “my font is wrong”. The font is the cause; the layout is the symptom.
Where it goes wrong most often
- Licensing restrictions. Some fonts are licensed in a way that forbids embedding. The exporter silently drops to referencing instead.
- Web fonts in HTML-to-PDF conversion. The converter renders the page before the font loads, or cannot reach the font server at all.
- Office documents opened elsewhere. A document built with a system font on one operating system, opened on another, substitutes before the PDF is ever made.
- Variable fonts. Support is uneven in older PDF tooling; the wrong weight or width instance gets baked in.
- Type 3 and bitmap fonts. Rare, legacy, and they print badly at any size other than the one they were made for.
Preventing it
Three rules cover most cases. Embed everything at export, accepting the larger file. Use fonts whose licence permits embedding — check before a project rather than at delivery. And check the result: any decent PDF reader will list the fonts in a document and state whether each is embedded and subsetted. That thirty-second check catches the problem while you can still fix it.
When the file must be frozen
For anything going to a printer, a legal filing or a client who must not be able to alter it, converting text to fixed graphical content removes the font question entirely. Running flatten PDF merges layers, form fields and annotations into the page itself, so nothing depends on the recipient’s system any more.
The trade-off is real: flattened text is no longer selectable or searchable, and it cannot be edited or corrected. Flatten the delivery copy, never the master.
When the file must last
For archiving, the relevant standard is PDF/A, which exists precisely because of this problem. It mandates full font embedding, forbids external dependencies and disallows features that might not be supported in future readers. A PDF/A file is by definition self-contained, which is the whole point when the document has to open correctly in twenty years.
It is required for many legal and institutional submissions for the same reason. If you are sending something to an archive, a court or a regulator, check whether they specify it — a rejected filing over a font setting is a bad way to lose a deadline.
The one-line version
Embed the fonts. Almost every PDF font problem in existence is an unembedded font meeting a machine that does not have it.