Why Does My PDF Look Different on Another Computer?
Short answer
The fonts were not embedded. A PDF without embedded fonts tells the viewer "render this in Calibri" and a machine without Calibri substitutes something else, which shifts every line. Re-export with embed all fonts ticked — in Word that is the Standard or ISO 19005 compliant option, in the Mac print dialog it happens by default.
On this page
A PDF is supposed to be the format where this does not happen. That is the entire premise: a fixed page description that renders the same on every machine, which is why contracts and forms are distributed as PDFs rather than as Word files.
When it does not hold, the cause is almost always the same. The file is referencing fonts rather than carrying them, and the machine opening it does not have the ones you used.
What “embedded” actually means
A PDF can store a font in two ways.
Referenced — the file says “this text is Calibri, 11pt” and leaves the viewer to find Calibri. If the viewer has it, the page is correct. If not, the viewer picks a substitute and the page is approximately correct, which is worse than it sounds.
Embedded — the actual font data travels inside the PDF. Any viewer anywhere renders the page with the real typeface, whether or not it is installed. Usually this is a subset: only the characters the document uses are stored, which keeps the size overhead small.
Substitution is where the damage happens. The substitute has different character widths, so every line is fractionally wider or narrower than intended. Over a paragraph that moves the line breaks. Over a page it moves the page breaks. Over a document it turns a neat three-page report into four pages with an orphaned heading, and a table into a mess.
Check your file before blaming anything else
Open the PDF and look at its font list.
- Acrobat Reader: File → Properties → Fonts tab.
- macOS Preview: Tools → Show Inspector, then the font-related tab.
- Chrome and Edge: no font inspector. Open it in a viewer that has one.
Each entry shows the font name and, beside it, either Embedded,
Embedded Subset or nothing at all. Anything without an embedding note is a
font the file expects to find on the reader’s machine.
If every font says Embedded Subset and the document still renders differently, the cause is not fonts, and the section further down covers the other possibilities.
Fixing the export
Microsoft Word (Windows)
Word’s PDF export has two modes and the distinction is badly labelled.
File → Save As → PDF, then click Options. Tick PDF/A compliant (labelled ISO 19005-1 compliant in some versions). PDF/A is an archival standard that requires font embedding, so ticking it forces the behaviour you want.
Also check Optimize for: Standard (publishing online and printing) rather than Minimum size. The minimum-size setting is where font and image data get dropped.
There is a separate setting that bites people: File → Options → Save →
Embed fonts in the file. That one applies to the .docx, not the PDF, but if
the document is passing through other hands before export it is worth having on.
Microsoft Word (macOS) and the Mac print dialog
Exporting through the macOS print dialog — Cmd+P → PDF → Save as PDF — embeds fonts as a matter of course, because the system renderer builds the PDF from the same font data it used to draw the page. On a Mac this route is generally more reliable than Word’s own export.
Google Docs
Docs embeds fonts on export and the fonts available are Google’s own web fonts,
so this case rarely goes wrong. Where it does go wrong is the reverse direction:
a .docx uploaded to Docs gets its fonts substituted at import, before you
ever export. The PDF then faithfully embeds the wrong typeface.
LibreOffice
File → Export as PDF → General tab, and ensure font embedding is enabled. LibreOffice embeds by default in current versions, but a document carrying settings from an old template can override it.
When the fonts are embedded and it still looks wrong
Three other causes, in rough order of likelihood.
Transparency and blend modes. Drop shadows, soft edges and partially transparent overlays are rendered differently by different engines. Older viewers flatten them in ways that produce visible boxes around images. Exporting to PDF/X or flattening transparency in the source removes the variable.
Colour management. The same CMYK values render differently depending on the colour profile the viewer assumes. Noticeable on anything heading for print, invisible on a text document.
Viewer rendering settings. Acrobat and Preview apply font smoothing and hinting differently, and some viewers enlarge thin lines so they remain visible at low zoom. If the difference is “slightly heavier text” rather than “different line breaks”, this is probably all it is, and there is nothing to fix.
Checking before you send
The test that matters is opening the file somewhere that definitely lacks your fonts.
The easiest version: upload it to Google Drive and preview it in the browser. Drive renders server-side with its own font set, so a file that survives that intact will survive most recipients. Opening it on a phone works similarly — phones have a small font library, so substitution shows up immediately.
If you cannot test, reduce the exposure. Documents built in Arial, Times New Roman, Calibri, Cambria, Helvetica or Georgia render acceptably almost everywhere even when substitution happens, because near-identical metric equivalents are installed on most systems.
The size trade-off
Embedding costs something, and on a document assembled from several sources it can cost more than expected. A dozen fully embedded font families add a few megabytes, which is the mechanism behind one of the three causes in why PDFs get large.
Subsetting is the compromise worth having: only the glyphs actually used are stored, so the overhead is tens of kilobytes rather than hundreds. Most modern exporters subset automatically. If a file has ballooned after you forced embedding, check whether the exporter embedded complete families instead.
What to expect
Re-exporting with embedding on fixes the overwhelming majority of these cases, and the file typically grows by a small fraction — not enough to matter for emailing.
The honest limit is fonts that forbid embedding. Some commercial typefaces carry an internal flag that blocks it, and no export setting overrides that. If an exporter silently leaves one font un-embedded while handling the rest, that flag is why, and the only fix is to substitute a different typeface deliberately rather than letting each reader’s machine choose one for you.