Text and fonts
Line breaks in the PDF differ from the browser preview
The layout is nearly right, and words wrap in different places, which pushes everything down a line and occasionally spills onto an extra page.
What is actually happening
The font is not the same. If the intended font failed to load in the render, the fallback has different character widths, and different widths mean different wrap points. A one-line difference at the top of a long document compounds all the way down.
Confirming it is this and not something that looks like it
Compare a distinctive word's width in both. If they differ, the font differs, whatever the shapes look like at a glance.
The fix
Fix the font loading. This symptom is the font problem wearing different clothes, and chasing it as a layout problem will not work. Embed the font and set font-display: block so the render waits rather than paginating with the fallback.
If that was not it
These produce the same symptom often enough to be worth ruling out before assuming the fix above did not work.
- A synthesised bold or italic, which has different metrics from the real weight
- font-display: swap, which lays out with the fallback first
- hyphens: auto, which needs a lang attribute to know which dictionary to use
- Different text rendering settings between the preview and the render
Frequently asked
Does this happen with every rendering engine?
The behaviour behind it is not specific to one tool. The font is not the same. Anything rendering HTML to a paged medium has to make the same decision, so the fix travels with you if you change how the render happens.
Will this show up as an error in my logs?
No, and that is what makes it expensive. A document that renders wrong is still a successful render as far as every log line is concerned. It is found by someone opening the file, which is usually the customer.
Related failures
Problems people arrive at from the same starting point, or mistake for this one.
Custom fonts fall back to a default in the PDF
The font file was not fetched.
Emoji do not render in the PDF
Emoji need a dedicated font, and colour emoji need one in a colour font format.
Text in the PDF cannot be selected or searched
The text is not text.
Chinese, Japanese or Korean characters show as boxes
The font in use has no glyphs for those characters, and no font on the render machine does either.
Arabic or Hebrew text renders backwards or disconnected
Two separate problems.
CSS for paged documents, and what actually works
Which parts of the paged media specification a browser-based render implements.
Everything that goes wrong, by category
The full list, grouped by where in the pipeline it breaks.
Paste your markup and see the rendered document, without signing up.