Why a PDF Looks Different on Someone Else's Computer
You send a document. The reply comes back: the layout is broken, a heading has wrapped onto two lines, a table has burst out of its column. On your screen it is perfect.
This is not supposed to happen. Fixed appearance is the entire premise of the format — the P stands for Portable, and portable here means the page survives the journey. Mostly it does. When it does not, there is a specific reason, and it is almost always the same one.
The short answer: the fonts are not in the file
A PDF is meant to carry everything it needs. Text is stored as character codes plus the font data required to draw them, so a machine that has never seen your typeface can still render the page exactly as you designed it.
That only works if the font actually travelled with the document. When it did not, the reader has to find something else — and “something else” is different on every computer.
The result is not merely a different-looking typeface. It is worse than that, and understanding why explains every symptom in this guide.
Substitution moves your text, it does not just restyle it
Every font has metrics: how wide each character is, how far the next one sits, how tall the line needs to be. Substituting a font substitutes its metrics too.
A replacement whose characters are 5% wider makes every line 5% longer. A line that fitted becomes a line that wraps. A heading that sat on one line takes two, pushing everything below it down, and on a tightly laid-out page that cascades into overlapping blocks, text escaping its box, and a table column landing on top of its neighbour.
So the symptom people report — “the layout is broken” — is accurate. The layout genuinely is broken, because layout was computed with one set of measurements and is being drawn with another.
The standard fonts nobody embeds
Here is the part that surprises people, and it explains why this happens to documents that look entirely ordinary.
PDF defines a set of base fonts — Helvetica, Times, Courier, Symbol, and a dingbat face — that every reader is expected to provide. Because they are assumed present, most software deliberately does not embed them. It saves space and it is entirely legal.
But “Helvetica” is not a file that ships with every operating system. Each reader supplies whatever it considers a reasonable stand-in, and those differ.
This site is a working example of the problem. For its own PDF viewer to render documents that reference those base fonts, it has to ship a set of substitute typefaces — Foxit Serif, Foxit Fixed, Foxit Symbol, Foxit Dingbats, and Liberation Sans — served alongside the site so that a document asking for Helvetica gets something. You can see them in the site’s third-party licence page.
That is the whole issue in one artefact. A document using Helvetica does not contain Helvetica; it contains a request, and every renderer answers that request with a different font.
If your document was produced with default settings in older software, there is a good chance it is asking rather than carrying.
How to check, in ten seconds
Every serious PDF reader exposes this, usually under File → Properties → Fonts, sometimes called Document Properties.
You get a list of every font the document uses, each labelled. What you want to see beside every entry is Embedded or Embedded Subset. What tells you the answer is a font listed with neither label, or listed as a base font with a substitute named alongside it.
One list, one glance, and you know whether this guide applies to you.
The subset trap
“Embedded Subset” deserves a note, because it introduces a second, sneakier failure.
To save space, software usually embeds only the glyphs the document actually uses. A report that never uses the letter Ω does not carry it. That is efficient and almost always fine.
It stops being fine when someone edits the document later. Type a character that was not in the original subset — an accented letter, a currency symbol, a dash of a different length — and there is no glyph for it. Depending on the software you get a blank, a box, or a substituted character in an obviously different face.
This is why documents sometimes degrade progressively as they pass through several hands, each edit adding a character the embedded subset never anticipated.
The other causes, in order of likelihood
Fonts account for most of it. Four other things produce the same complaint.
Different readers genuinely render differently. A browser’s built-in viewer, a desktop reader, a phone’s preview pane, and an e-reader are four separate implementations. They agree on nearly everything and disagree at the edges — anti-aliasing, hairline widths, transparency. If a document looks wrong in one and right in another, this is likely, and browser PDF tools vs desktop software covers the wider trade-offs.
Form fields and annotations are drawn by the reader. Like the printing case, these are objects layered above the page rather than content on it, and each reader draws them in its own style. A form that looks neat in one reader can look crude in another. The same applies to comments and highlights — and it is the same mechanism behind why a filled form prints blank.
Transparency and blend modes. Soft shadows, overlapping translucent shapes, and unusual blending are the features most likely to be approximated differently, or dropped, by older renderers.
Colour. The same values can look markedly different on two displays with different profiles and calibration. If the complaint is “the colours are off” rather than “the layout is broken”, this is usually it, and it is a property of the screens rather than the file.
Dark mode. Several readers now invert or dim document colours to match a dark interface. A recipient with that setting on is genuinely not seeing your page as you drew it, and they may not know the setting exists.
Fixing it properly
The real fix is at export, in whatever produced the document — not in the finished PDF.
Embed all fonts. Almost every export dialog offers this, often buried under an Advanced or Options button, sometimes phrased as “embed fonts” or “do not use system fonts”. It makes the file slightly larger and it removes this entire category of problem.
Do not rely on the base fonts. If you can choose, choose a typeface your software will embed rather than one it will assume.
Check the Fonts tab before sending anything whose layout matters. It takes ten seconds and it is the only reliable confirmation.
For documents that must render identically years from now — contracts, records, anything archived — the format designed for this is PDF/A, standardised as ISO 19005 — and what PDF/A is and whether you need it explains what conforming to it costs. Its central requirement is precisely the one above: everything the document needs must be inside the document, fonts included. The PDF Association publishes an accessible introduction to what the profile guarantees.
The last resort, and what it costs
If you cannot re-export — the source is gone, the software is gone, someone else made it — there is one way to guarantee the page looks the same everywhere: stop it being text at all.
Rendering each page to an image freezes its appearance exactly as you see it now. No font can be substituted, because no font is referenced. Compress PDF does this, since re-encoding pages as images is what compression here means.
Be clear about the price, because it is steep:
- The text stops being text. Search, selection, and copying all stop working — why can’t I copy text from a PDF.
- Screen readers get nothing.
- The file usually gets bigger, since photographs of characters cost far more than characters.
- It cannot be undone.
This is the right trade in exactly one situation: appearance matters more than everything else, and you have no way to fix the source. A signature page, a certificate, a layout-critical single sheet. It is the wrong trade for a document anyone needs to search or read with assistive technology.
If you do take this route, run OCR afterwards to restore a searchable text layer — that ordering matters, and it is covered in why is my PDF so large.
Diagnosing it quickly
- Ask what is wrong, precisely. “Layout broken” points at fonts. “Colours look off” points at displays. “Comments look odd” points at annotations.
- Open Properties → Fonts. Anything not embedded is your answer.
- Open it in a second reader yourself. If it breaks for you too, the file is at fault, not their setup.
- Ask which reader they used. A browser preview failing where a desktop reader succeeds is a rendering difference, not a broken document.
- Ask whether dark mode is on, if the complaint is about colour or contrast.
Step 3 is the one people skip, and it is the one that splits “my file is wrong” from “their software is unusual” — which are completely different problems.
Why the format usually keeps its promise
None of this makes PDF unreliable. The structures that make fixed appearance possible — embedded font programs, resource dictionaries, page content streams — are specified in detail in ISO 32000-2, and they work. A PDF with its fonts embedded really does render the same on a phone, a laptop, and a print shop’s workstation.
The failures cluster in one place, and it is a consistent place: anything the document expects to find on the far end rather than carrying with it. Fonts it assumes are installed. Fields it expects the reader to draw. Colours it expects a display to interpret.
Carry everything, and the promise holds.