Why a PDF looks different on someone else’s screen

You send a PDF that fits on one page. It arrives on someone else's machine as two pages, with a heading that now wraps awkwardly and a table that has stopped lining up. PDF was supposed to be the format where this does not happen. Usually it is. The exception is fonts, and it is almost always fonts.

A PDF either embeds the font or names it and hopes

Every PDF faces the same question for every typeface it uses: ship the font, or ask for it. Embedding means the actual font file — the outlines of every glyph — is copied into the PDF and travels with it. That costs bytes, sometimes megabytes for a full CJK face, and it means the document is genuinely self-contained. Whoever opens it draws the text with the exact font you used, because the font is right there in the file.

The other option is to name it. The PDF writes down "this text is Helvetica" and includes nothing else, on the assumption that the reader's machine already has Helvetica or something close enough. When that assumption holds, the file is smaller and everything looks right. When it does not hold, the reader's viewer substitutes — it picks whatever it thinks is nearest and draws with that instead. Nobody is told. The document just quietly looks a bit different than you left it.

The standard-14 are the ones nobody embeds

Fourteen fonts are special, and they are the root of this whole problem. Helvetica, Times, Courier, Symbol and ZapfDingbats — with their bold, italic and bold-italic variants — are the standard-14, and the PDF specification assumes every reader in the world can produce them. Because that assumption is baked into the format, they are never embedded. Naming one is considered sufficient. The file just says "Helvetica" and moves on.

Except that a machine "having Helvetica" is a much softer fact than it sounds. Helvetica is a licensed commercial typeface that most Windows machines have never had; they have Arial, which was drawn to occupy the same space with different letterforms. Linux boxes typically have neither and reach for Nimbus Sans or Liberation Sans. Each viewer has its own idea of what to do, and there is no authority to appeal to. Your file did not specify a font. It specified a name and a hope.

Why substitution moves your line breaks

Substitution changes layout because glyph widths change. Every character in a font has its own advance width — how far the pen moves after drawing it — and no two fonts agree on all of them. Arial's letters are not exactly Helvetica's letters, however similar they look at a glance. Nimbus Sans is different again. So the substituted line is a fraction wider or narrower than the one you saw.

A fraction is enough. A line that fitted with two millimetres to spare now needs two millimetres more than it has, so the last word wraps to the next line. That line pushes the one below it. Twenty lines later the accumulated drift has shoved a heading onto a new page, and your one-page letter is two pages with a lonely signature block. The text is all intact and perfectly correct — it is just no longer where you put it. Tables and forms show it worst, because they were aligned by eye at specific coordinates and nothing keeps a substituted glyph inside its column.

BabaPDF makes exactly this kind of PDF

The honest thing to do here is admit that this site is a producer of the problem it is describing. Three tools here draw text into your document, and every one of them names a standard-14 font rather than embedding a font file.

• Text to PDF uses Helvetica — a standard-14 face, named and not embedded. Its output is precisely the class of PDF this article is about.
• Add Watermark draws with Helvetica-Bold, same deal.
• Add Page Numbers draws with Helvetica at 11 points, same deal.

That is verifiable rather than a matter of trust. Save a file from any of those three tools, open the raw PDF, and the font object reads /Subtype /Type1 with /BaseFont /Helvetica and nothing else — no /FontDescriptor, no /FontFile. Those last two are where an embedded font would live, and they are simply absent. The file names a face and hopes, exactly as described above.

In practice the consequences are mild, which is why this is a reasonable default rather than a bug. A page number in the corner does not care whether it renders in Helvetica or Arial, and neither does a diagonal watermark. Text to PDF matters slightly more, because it is laying out whole paragraphs and the wrap points will shift on a machine that substitutes. If you need a plain-text file to paginate identically everywhere, this is not the tool for it — take it through a word processor and export with fonts embedded. No competitor will tell you that about their own converter, and it costs nothing to say.

How to check what a PDF is carrying

Any PDF will tell you its fonts if you ask. In Acrobat or Reader, open File then Properties and look at the Fonts tab: every face is listed, and the ones that travelled with the file are marked "Embedded" or "Embedded Subset". Anything without that marker is a name and a hope. A subset, incidentally, is the sensible middle path — only the glyphs actually used get embedded, so you carry the seventy characters your document needs instead of a whole font.

The list is worth a glance before you send anything where layout matters. If it says Embedded Subset next to everything, your document will look the same for the person opening it. If it names Helvetica bare, you have just learned that their machine will improvise.

The nuclear option, and what it costs

Rasterising the page removes the question entirely. Flatten PDF in "everything to images" mode draws every page here, on your machine, with your fonts, and replaces the page with the resulting picture. There is no font left to substitute because there is no text left to draw — just pixels that already have the right shapes in them. Appearance becomes guaranteed, byte for byte, on every machine on earth.

And the text stops being text. It is no longer selectable, no longer searchable, no longer readable by a screen reader, and no longer sharp when someone zooms in or prints it large. That trade is not specific to fonts and is worth understanding on its own terms before you make it — the whole argument is in vector and raster in a PDF. The summary: certainty, bought with everything that made it a document rather than a photograph.

What to do instead, most of the time

Embed your fonts at the source, in whatever produced the document. Word, LibreOffice, InDesign, LaTeX and every browser's print-to-PDF can all embed, and most of them do it by default now — Word has a "Embed fonts in the file" checkbox under Save options, and export dialogs generally have an embedding setting worth two seconds of your attention. Embedding at export costs you some kilobytes and solves the problem permanently and properly, with the text still text at the other end.

And if the layout is fine but individual characters have turned into question marks, that is a different failure with a different cause — encoding, not substitution. That one is covered in why PDF text turns into question marks.

The short version

• A PDF either embeds a font file or names a font and hopes the reader has it.
• The standard-14 — Helvetica, Times, Courier and friends — are never embedded, by design.
• Substituted fonts have different glyph widths, so line breaks move and drift compounds down the page.
• The sender never sees the bug, because the sender has the font.
• Text to PDF, Add Watermark and Add Page Numbers here all name a standard-14 face rather than embedding one.
• Check any file: Acrobat, File then Properties, Fonts tab. Look for "Embedded Subset".
• Flattening to images guarantees appearance and costs you selectable text. Embedding at the source costs kilobytes and costs nothing else.