Why the same PDF can look different on someone else's screen

The short answer

A PDF looks different on another computer when it depends on something that machine supplies differently — most often a font that was not embedded, so the viewer substitutes another. Colour management, overprint handling, form fields without stored appearances and differences between viewers account for most of the rest. A fully self-contained PDF renders the same everywhere.

The format can carry everything needed to draw each page. Trouble starts where a file leaves a gap for the viewer to fill.

Fonts: embedded, subset or missing

Each piece of text in a PDF names a font. The file can either carry that font's glyph outlines inside it — embedded — or carry only the name and its character widths, trusting the viewer to find a matching font on the system.

An embedded font draws identically on every machine because the outlines travel with the file. A subset font is embedded too, but contains only the characters the document uses, which keeps files small and is entirely normal. A font that is not embedded is a request: the viewer looks for it locally, and if it is missing, picks a substitute. Good viewers stretch the substitute to the original widths so line breaks stay put, but the letterforms change, and a heavy display face can come out looking like plain body text.

The traditional exceptions are the fourteen base fonts — Times, Helvetica, Courier, Symbol and Zapf Dingbats in their variants — which older software left unembedded on the assumption every viewer had them. Most viewers do have close equivalents, which is why those files usually look nearly right rather than exactly right.

Missing glyphs and wrong characters

A substitute font may not contain every character. Accented letters, mathematical symbols, non-Latin scripts and icon fonts are the usual victims, and the result is empty boxes, blanks or the wrong symbol. Bullet points that turn into letters or digits are a classic sign that a symbol font was substituted.

Embedded fonts can fail in a related way. If a subset was made incorrectly or the font's internal tables are damaged, one viewer may cope while another stops drawing the text. That is closer to corruption than to a missing font, and it is where a viewer's tolerance becomes the visible difference.

Colour, overprint and transparency

Print-oriented PDFs often describe colour in CMYK with an attached colour profile. Converting that to the RGB of a screen involves choices, and viewers make them differently: some apply the profile, some approximate, some ignore it. The same red can look correct in one application and dull in another, before the monitor's own calibration enters the picture.

Overprint is the more surprising case. In print production an object can be set to overprint, meaning it is printed on top of the inks below instead of knocking them out. Many screen viewers do not simulate it by default, so a file can look fine on screen and print differently, or show unexpected colour on a viewer that does. Desktop readers often have an overprint preview setting; if it is off on one machine and on at another, the two people are genuinely seeing different renderings of the same file.

Transparency, blend modes and soft masks are another place lighter viewers cut corners, and they show up as hard edges, odd shadows or a faint box around an image that should have blended in.

Viewer and content differences

A handful of other causes come up often enough to check.

• Form fields without appearances. A filled field can store its value without a drawn appearance, leaving each viewer to generate one. Some do it differently and some not at all, so values show on one machine and vanish on another. Flattening bakes the values into the page.
• Optional layers. Layered content can default to visible or hidden, and viewers differ in how they honour the setting, especially when printing.
• Page boxes. A page carries a full-size MediaBox and a CropBox for what should be displayed. Viewers and printers do not all use the same box, which shows up as margins that differ between machines.
• Hairlines. Lines with zero or tiny width are drawn as thin as the device allows, so they look different at different zoom levels and on different screens.
• Damaged structure. A file with a broken internal index is reconstructed by each viewer's own recovery logic, and two viewers can rebuild it differently.

How to check, and how to fix it

To check embedding, open the document properties in a desktop reader and look at the fonts list: each font should say embedded or embedded subset. Anything without that note depends on the viewing machine. On the command line, the poppler utility pdffonts prints the same information with an emb column.

The real fix is at the source. Re-export with font embedding enabled, or use a PDF/A export, which requires every font to be embedded and forbids several of the features above. If the source is gone, the robust fallback is rasterising: PDF to PNG renders each page in your browser and freezes the result as pixels, so there are no fonts or colour decisions left for another machine to make. It is also a quick second opinion — if the PNG looks right and your desktop reader does not, the reader is the variable.

For files that open differently or partially in different viewers, Repair PDF rebuilds the internal structure with a tolerant parser and re-saves it, so every viewer reads the same repaired structure instead of improvising its own. For form values that disappear, Flatten PDF writes them into the page so no viewer has to draw them.

Frequently asked questions