Why does my PDF look different on different devices?

The three things that go wrong

1. Missing embedded fonts (≈75% of cases).The PDF references a font by name; the reader substitutes whatever it has. The substitute has different character widths, kerning pairs, and x- height, so lines wrap differently and the overall visual rhythm changes.
2. Colour-space ambiguity (≈15% of cases).The PDF uses DeviceRGB or DeviceCMYK without a profile; different readers interpret the raw values differently. Most visible on calibrated displays and when comparing screen-to-print.
3. Transparency edge cases (≈10% of cases).Complex transparency groups, blend modes, and soft-masking are inconsistently implemented across readers. Documents authored in InDesign or Illustrator are more likely to exercise these edge cases.

Other failure modes exist (OpenType variable fonts, very large pages, embedded JavaScript) but together account for <1% of real-world cases.

Step-by-step: produce a PDF that renders identically everywhere

The ScoutMyTool font embed-checker lives at scoutmytool.com/pdf/pdf-font-embedding-check. Runs client-side — no upload, no signup, no quota.

1. Run the font embed-check. Drop your PDF, get a list of every font and its embed status. Any "not embedded" entry is a rendering risk.
2. Re-export from the source with embedding on. Word: File → Save As → PDF → Options → tick "Embed fonts". InDesign / Illustrator: PDF preset → ensure "Embed all" is selected. LibreOffice: File → Export As PDF → tick "Archive (PDF/A)".
3. Verify in the PDF/A detector. If the file conforms to PDF/A-2b, it has embedded fonts AND device-independent colour AND transparency-flattened content — three rendering risks addressed at once.
4. For colour-critical work: convert to sRGB. In the source application, convert the document's colour profile to sRGB (or to a specific CMYK profile for print) before exporting. This pins colour interpretation regardless of the reader.
5. For transparency-heavy designs: flatten before export. InDesign: Print Production → Flatten Transparency. Illustrator: Object → Flatten Transparency. ScoutMyTool: Flatten PDF tool. After flattening, every reader handles the document identically.
6. Cross-reader spot-check. Open the final PDF in Acrobat, Preview (macOS), and Chrome's built-in viewer. Compare a typography-heavy page and an image-heavy page. If the three agree visually, the file is robust.
7. Document the chain. For high-stakes documents (publishing, legal filings, design proofs), keep a record of the export settings used — what source application, what PDF preset, what colour profile. Reproducibility matters when the same document needs to be re-exported in six months.

Why different readers render PDFs differently in the first place

The PDF specification (ISO 32000-1¹) is a large document — ~750 pages — with many areas where it permits some implementation flexibility. Three areas in particular:

• Font substitution policy is under-specified. The spec says "the reader should attempt to find a font with similar metrics" but does not define the algorithm; each reader has its own heuristic.
• Default colour space when a PDF uses DeviceRGB without an output intent is left to the reader. Most readers default to sRGB but the spec does not mandate that.
• Transparency group composition orderis mostly defined but with several optional behaviours for edge cases like isolated knockout groups.

The PDF/A and PDF/X standards (ISO 19005 and ISO 15930) deliberately remove all the flexibility — they require font embedding, device-independent colour, no transparency-edge-case behaviours². A file conforming to either is structurally guaranteed to render identically across conforming readers; that is exactly the point of those standards.

Related ScoutMyTool articles and tools

• Embedded fonts in PDF — why they matter
• PDF/A vs PDF — long-term archival
• How to print a PDF without losing formatting
• Flatten PDF — including transparency flattening
• Font Embedding Check tool
• PDF/A Version Detector tool
• Word to PDF — preserve fonts and images

Frequently asked questions

I thought PDFs render identically everywhere — why don't they?

Because "render identically everywhere" is a marketing claim about ideal PDFs, not a guarantee about every PDF. A correctly-built PDF — with embedded fonts, device-independent colour, and conforming PDF content streams — does render identically across readers. A PDF that skips any of those (most consumer-grade PDFs skip at least one) leaves rendering decisions to the reader, which means different readers will make different decisions. The single biggest culprit is missing embedded fonts; runner-up is colour-space ambiguity; bronze medal is reader-specific handling of transparency groups.

My PDF looks fine in Acrobat but weird in Chrome's built-in viewer. Why?

Different rendering engines. Acrobat uses Adobe's own PDF rasteriser. Chrome uses pdf.js — Mozilla's open-source PDF renderer (yes, Chrome ships Mozilla's library) — with some Google-specific patches. Preview on macOS uses Apple's CoreGraphics PDF stack. Each engine implements the PDF specification slightly differently around edge cases: complex transparency groups, OpenType variable fonts, very large pages, certain blend modes. Most documents render the same in all three; documents that exercise the edge cases can diverge.

My PDF looks fine on my Mac and corrupt on my Windows machine.

Almost certainly missing embedded fonts. Mac and Windows ship different system fonts, so a PDF that references "Garamond" by name finds the right font on Mac (or a close substitute) but a wildly different fallback on Windows. The fix is to embed the fonts: see the Embedded Fonts article. Verify with the Font Embedding Check tool — if any fonts show "not embedded", that is the cause.

Colours are slightly different between devices.

Colour-space ambiguity. A PDF can specify colours in several spaces: DeviceRGB (raw RGB values, interpreted differently per device), CalRGB (calibrated RGB), sRGB (the web-standard), or with an embedded ICC profile (most precise). DeviceRGB leaves interpretation up to the reader, which leads to drift on calibrated displays. The fix: convert colour to ICC-profiled sRGB or CMYK at the source application before exporting to PDF; or convert to PDF/A which mandates device-independent colour.

My PDF renders one way on screen and a different way when printed.

Two layers diverging. Screen renders use the display's colour profile (often uncalibrated sRGB or DCI-P3 on modern Macs); print uses the printer driver's colour conversion (often CMYK-from-RGB heuristics). The screen and the print will disagree to some degree on any PDF that does not pin down its colour space. For mission-critical print work, prepare a PDF/X file (the print-focused cousin of PDF/A) with embedded ICC profiles for both screen preview and print output — Adobe Acrobat&apos;s Output Preview shows the print rendering on screen.

Transparency renders differently on different readers.

PDF transparency (added in PDF 1.4) is one of the more complex areas of the specification, and not every reader implements every transparency blend mode and group nesting correctly. The safest answer for cross-reader fidelity is to flatten transparency before export — Acrobat&apos;s Print Production tools, InDesign's Flatten Transparency, and the ScoutMyTool flatten-PDF utility all do this. Flattened transparency renders as solid composited shapes that every reader handles identically.

How do I check whether my PDF will render reliably across readers?

Three checks. (a) Run the Font Embedding Check — every font must be embedded. (b) Run the PDF/A Version Detector — PDF/A-2b conformance is a strong proxy for "renders identically everywhere". (c) Open the PDF in three readers (Acrobat, Preview, Chrome built-in) and visually compare critical pages. If all three agree, the file is robust. Disagreements flag the edge cases that need attention; the most common is fonts, followed by transparency.