Why PDF fonts look wrong on another computer
2026-09-19 · 6 min read
You sent a pixel-perfect PDF and it arrived with the wrong typeface, odd spacing and a table that no longer lines up. Almost always, one thing explains it: whether the fonts travelled inside the file.
A PDF can carry its fonts, or just name them
When you look at text in a PDF, you are looking at glyphs, the drawn shapes of letters. A PDF can store those shapes in one of two ways. It can embed the font, tucking the actual glyph outlines inside the file so they travel with it. Or it can merely reference the font, recording little more than its name and metrics and trusting that whatever program opens the file will already have that font installed.
On the machine where the PDF was made, the difference is invisible: the font is installed, so referenced or embedded, it renders the same. The gap only opens when the file lands somewhere else (a colleague's laptop, a print shop, a phone, a server generating a preview) where that font may simply not exist.
What substitution actually does to a page
When a viewer is asked for a font it does not have, it does not give up; it substitutes. It picks the closest available face and carries on. That sounds harmless, and for a single word it often is. Across a whole document it rarely stays harmless, because no two fonts share the same measurements.
Every glyph has a width, and every font sets those widths differently. Swap the intended font for a substitute and each character now occupies a slightly different amount of space. The effects cascade:
- Spacing drifts. Letters and words sit tighter or looser than intended, and kerning that looked deliberate turns ragged.
- Line breaks move. A line that just fit now overflows, pushing a word to the next line and shunting every line after it.
- Layout breaks. Text that was tuned to a column can spill past it; a heading wraps where it should not; the last line of a paragraph orphans onto a fresh page.
- Tables and forms misalign. Columns pinned to text widths shift out of true, and labels drift away from the boxes they belonged to.
The content is intact (every character is still there), but thetypesetting, the thing that made the document look finished, is gone.
Why fonts get left out in the first place
Embedding is the safe default, so why does anyone ship a PDF without its fonts? A few reasons, none of them malicious:
- To save size. Fonts add weight, and some export settings (especially older or “web” presets) leave them out to keep files small. It is a false economy when layout matters.
- Licensing restrictions. Not every font permits embedding. Some carry flags that forbid it, so a well-behaved exporter will decline to embed them and reference them instead.
- The “standard 14” assumption. Early PDF defined a core set of fonts (variants of Helvetica, Times, Courier, plus Symbol and ZapfDingbats) that every reader was expected to provide. Files built around those assume the reader supplies them, and if the reader substitutes something merely similar, the result still shifts.
| Aspect | Embedded fonts | Referenced (not embedded) |
|---|---|---|
| File size | Larger, glyph data is included | Smaller, only names and metrics stored |
| Portability | Renders the same on any device | Depends on the reader having the font |
| Layout risk | None from fonts, spacing is fixed | High, substitution reflows the page |
| Best for | Anything you send, print, or archive | Internal drafts where size is the only concern |
How to tell whether a PDF embedded its fonts
Most desktop PDF readers expose this. Open the document's properties or document dialog and look for a fonts list; each font is usually annotated with Embedded, Embedded Subset, or nothing at all. “Embedded Subset” means only the glyphs the document actually uses were included: a common, sensible optimisation. A font listed with no such note is one the file is trusting the reader to supply, which is your warning sign.
The faster informal test: open the PDF on a different device, ideally a plainer one, and compare. If the typeface, spacing or line breaks change, a font was not embedded.
How to prevent it
The fix is to make sure the fonts travel with the file:
- Embed (and subset) when you export. Whatever program creates the PDF (word processor, design app, print dialog) has an option to embed fonts, and often to subset them so only the glyphs in use are carried. Turn it on. Subsetting keeps the safety of embedding while limiting the size cost.
- Convert through a renderer that embeds. If you are starting from a Word document, our Word-to-PDF converter renders the document on a server to a fixed layout and embeds the fonts it uses, so the result is self-contained rather than dependent on the recipient's system. This tool uses LibreOffice on our server. Your file is sent over HTTPS and processed using temporary server files in a separate job directory; cleanup is attempted when processing ends, but immediate or secure deletion cannot be guaranteed. The Word-to-PDF guide walks through it. Note that for unusual custom fonts the converter may substitute the closest available face, so check the result if your document relies on a distinctive typeface.
- Choose fonts that allow embedding. If a font refuses to embed for licensing reasons, swapping to one that permits it is often the only reliable cure.
A quick caution on tools that don't solve this: lossless cleanup such as our Optimize PDF rebuilds a file's internal structure without touching its content, so it will not add fonts that were never embedded. It is the export step, not a later pass, that has to get embedding right.