The Document That Changed on the Way
You design a document, export it as a PDF, and it looks exactly right. You send it to a colleague, they open it, and something's off — the headings are in a different typeface, the spacing looks cramped, a table has shifted, or a heading now spills onto two lines. You didn't change anything. So why does the same PDF look different on their screen?
The answer almost always comes down to one thing: fonts. Specifically, whether the fonts your document uses actually travel *inside* the PDF, or whether the PDF is quietly relying on the other person's computer to supply them.
This is one of the few ways a PDF — a format built specifically to look identical everywhere — can still betray you. Understanding it takes five minutes and saves a lot of "but it looked fine on my machine."
How Fonts Work Inside a PDF
A PDF can handle fonts in three fundamentally different ways, and which one your file uses determines whether it survives the trip to another device.
Embedded fonts. The complete font — the actual data describing every letter's shape — is packaged inside the PDF file itself. When someone opens it, their PDF reader uses the font carried in the document, not whatever is installed on their computer. This is the gold standard: the document looks the same everywhere because it brings its own typography with it. The cost is a larger file, since font data adds weight (a point we touch on in why some PDFs are so large).
Subsetted fonts. A smart middle ground. Instead of embedding the entire font — which might contain thousands of characters across many languages — the PDF embeds only the specific glyphs the document actually uses. If your document only contains the characters in "Quarterly Report 2026," only those glyphs get embedded. The text still displays perfectly on any device, but the file stays much smaller. Most well-made PDFs use subsetting.
Non-embedded (referenced) fonts. The PDF doesn't carry the font at all. It just records the name — "this text is in Calibri" — and trusts that the device opening it has Calibri installed. If it does, great. If it doesn't, the reader substitutes a different font that it guesses is close enough. That substitution is where your layout falls apart.
| Approach | Font travels in the file? | File size | Looks right on other devices? |
|---|---|---|---|
| Embedded (full) | Yes, entire font | Largest | Always |
| Subsetted | Yes, only glyphs used | Small | Always |
| Non-embedded (referenced) | No, name only | Smallest | Only if the device has the font |
Why Substitution Wrecks the Layout
When a PDF reader can't find a referenced font, it doesn't give up — it swaps in a replacement. And because no two fonts have identical letter shapes and widths, the replacement rarely fits the same space.
Every font has its own metrics: how wide each character is, how much space sits between letters, how tall the line runs. Swap Calibri for a fallback like Arial or a generic serif, and each letter occupies slightly different width. Multiply that across a paragraph and lines break in new places. Multiply it across a page and text reflows, tables misalign, and carefully positioned elements drift. A heading that fit on one line now wraps to two. A form field label overlaps its box.
The content is all still there and still correct — but the *presentation*, the thing a PDF is supposed to guarantee, is broken. This is especially common with:
- Microsoft Office default fonts (Calibri, Cambria) opened on machines without them, such as Macs or Linux systems
- Custom or brand fonts that live only on the designer's computer
- Free or downloaded fonts that the recipient doesn't have installed
- Non-Latin scripts (Arabic, Chinese, Cyrillic) where a missing font can turn text into boxes or question marks
Why It Looks Fine on Your Machine (and Nowhere Else)
Here's the trap that makes this so easy to miss: on your own computer, the font *is* installed. So even a PDF with no embedded fonts opens perfectly for you — your reader finds the font locally and everything lines up. You have no way of knowing anything is wrong, because from where you're sitting, nothing is.
The problem only appears on a device that lacks the font. That's why "it looked fine when I made it" is so common with font issues: the author is the one person guaranteed *not* to see the bug.
How to Make Sure Your PDF Survives
The fix is straightforward once you know the cause: embed your fonts (or subset them) when you create the PDF.
Check your export settings. Most tools that create PDFs — word processors, design software, "print to PDF" dialogs — have a font embedding option, though it isn't always on by default. In design tools it may live under "Export" or "PDF preset" settings; in Office it's often "Embed fonts in the file." Turning this on is the single most effective fix.
Prefer widely available or embeddable fonts. Some fonts carry licensing flags that forbid embedding. If a font can't be embedded, either the tool warns you or it silently falls back to referencing — so if perfect fidelity matters, choose fonts you know are embeddable.
Verify what's embedded. You can check a finished PDF's font situation in its document properties. In Adobe Acrobat, File → Properties → Fonts lists every font and marks whether it's "Embedded" or "Embedded Subset." Any font *without* one of those labels is being referenced and is at risk of substitution elsewhere.
When in doubt, rasterize the risky parts. For a cover page or a heavily designed element where layout is non-negotiable, converting it to an image guarantees it can never reflow — at the cost of selectable text and larger size. This is the same trade-off behind scanned, image-based PDFs: perfect visual fidelity, no live text.
Why the Format Allows This at All
If PDFs are supposed to look identical everywhere, why is non-embedding even an option? Because embedding every font in every document would make files needlessly large, and in the early days of the format, file size mattered enormously. Referencing common system fonts was a reasonable optimization when everyone was on similar systems with the same handful of fonts installed.
Today, with wildly varied devices and endless custom fonts, that optimization is a liability — which is why modern best practice is to embed (or subset) by default. It's also a reminder that a PDF's "looks the same everywhere" promise is only as good as what you put in the file. The format *can* guarantee fidelity; it just needs the fonts to be there to do it. It's the same theme as why PDFs resist editing — the format's behavior makes sense once you know what it's actually storing.
The Bottom Line
When a PDF looks different on someone else's device, missing fonts are almost always the reason. If the fonts aren't embedded, the reader substitutes replacements with different letter widths, and the layout shifts. The fix is to embed or subset your fonts at export time, favor embeddable fonts, and verify in the document's font properties before sending. Do that, and the PDF's core promise — that it looks the same for everyone — finally holds true.