The document is wrong
SVG images are missing or wrong in the PDF
An SVG logo is absent, renders at the wrong size, or arrives entirely black when it should be coloured.
What is actually happening
There are three different problems wearing one symptom. An SVG referenced through an img tag cannot use an external stylesheet, so any styling that lives outside the file is lost. An SVG without width and height attributes has no intrinsic size for the layout to work from. And fill rules that rely on currentColor resolve against a colour the document never sets.
Confirming it is this and not something that looks like it
Inline the SVG directly into the markup instead of referencing it. If it renders correctly inlined, the reference was the problem rather than the file.
The fix
Inline SVGs into the document markup. They are text, they are small, and inlining removes the external reference, the sizing ambiguity and the styling boundary in one move. Set explicit width and height attributes on the root svg element.
<!-- Not this: the stylesheet inside cannot be reached, and there is no
intrinsic size to lay out against. -->
<img src="/static/logo.svg" alt="">
<!-- This: the shapes are in the document, sized, with colour resolved. -->
<svg width="120" height="32" viewBox="0 0 120 32"
xmlns="http://www.w3.org/2000/svg" aria-label="Logo" role="img">
<path d="M4 28 L16 4 L28 28 Z" fill="#1d1812"/>
</svg>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.
- currentColor fills where the ancestor colour is not set in the document stylesheet
- SVG referencing a font by family name that is not embedded
- clipPath or mask with an id that collides with another inlined SVG on the same page
- A viewBox missing entirely, which makes the graphic unscalable
Frequently asked
Does this happen with every rendering engine?
The behaviour behind it is not specific to one tool. There are three different problems wearing one symptom. 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.
Background colours and images are missing from the PDF
Browsers drop backgrounds when printing, because a page with every background painted would empty a toner cartridge, and most render APIs inherit that default.
Images do not appear in the PDF
The image src is a path rather than a URL.
Content rendered by JavaScript is missing from the PDF
The snapshot was taken before the script finished.
The generated PDF is blank
Almost always one of three things: the content is rendered by JavaScript that had not run when the snapshot was taken, the body has no height because everything inside it is absolutely positioned or floated, or the markup you sent was empty because the template call returned before the data arrived..
The PDF ignores my CSS
The stylesheet is linked rather than embedded, and the link points somewhere the renderer cannot reach: a bundler-generated path, a digested asset filename, or a URL behind your application's authentication.
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.