Visualforce PDF Formatting Problems: A Symptom-by-Symptom Reference

Your Visualforce page looks right in the browser. You add renderAs="pdf" and the output is wrong in a specific, maddening way: a font ignores bold, the logo comes out at full original size, a base64 image is simply absent, or the content overlaps the header from page two onward.

Almost every one of these has a documented cause. This is a symptom-by-symptom reference: what you are seeing, the limit that produces it, and whether there is a real fix or only a patch.

If your specific problem is that stylesheets and layout rules are being ignored, that has its own deeper write-up in why your Visualforce PDF CSS isn't working. This article covers the rest: fonts, images, page mechanics, and size ceilings.

The one root cause

Visualforce does not use a browser to make the PDF. It uses a bundled rendering service that, per Salesforce's own PDF rendering considerations, supports CSS up to version 2.1 and emits PDF 1.4. That is a standard from before flexbox, before grid, before most of what you write today.

One thing did change recently, and it is worth knowing which way it cuts. In Spring '26, Salesforce updated the Apex Blob.toPdf() method to use this same Visualforce PDF rendering service rather than an older legacy engine, a release update scheduled for enforcement in Summer '26. That brings better fonts and proper multibyte character support to Apex-generated PDFs, and it lets you produce a PDF without a Visualforce page at all. What it does not do is modernize the renderer. Everything below applies to Blob.toPdf() output too.

Symptom: a font ignores bold or italic

You set font-weight: bold and nothing happens, while background-color on the same element works fine.

Cause. The rendering service supports only the fonts available to it, and web fonts are not supported at all. Critically, Arial Unicode MS is the only font supported for multibyte characters such as Japanese or accented characters. If your document contains those characters, you are pushed onto the one font that renders them, and that font is exactly the one that does not honor bold. It is not a CSS bug. It is a direct collision between two documented constraints.

Fix. If you do not need multibyte characters, switch to a supported font and you get your bold back. If you do need them, there is no fix within Visualforce, only visual compromise.

Symptom: images are the wrong size or missing entirely

Two distinct failures get reported as one.

Wrong size. max-width and max-height on an image are ignored, so the logo renders at its original dimensions. The patch is to set explicit width/height attributes or to physically resize the source image.

Missing entirely. The documentation is explicit: data URI scheme images are not supported. So a base64-inlined image that displays perfectly in the browser will not appear in the PDF. WebP images and SVG markup are also unsupported, as are multipage TIFF files. There is no CSS workaround for any of these; the format simply is not rendered.

Fix. Serve images as static resources in a supported raster format (PNG or JPEG) at their intended size, referenced by URL rather than inlined.

Symptom: content overlaps the header on page two

Page one looks fine. From page two, the body text runs underneath the header.

Cause. Header and footer regions do not reserve space the way people expect, so content flows into them on subsequent pages.

Fix. There is only a patch: trial-and-error margin and padding until it looks right. It is fragile by construction, because the next field that wraps to an extra line changes the flow and you are tuning it again. This is the symptom that most reliably tells a team it has outgrown renderAs="pdf".

Symptom: text runs past the page margin

A long value, typically an ID, a URL, or a concatenated string with no spaces, extends beyond the right margin instead of wrapping.

Cause. Long unbreakable lines are a documented limitation. The renderer has nowhere to break the line and does not force one.

Fix. Introduce break opportunities in the data or the markup before rendering. This is a data-shaping fix, not a styling one.

Symptom: it worked in test and fails on a big record

Silent failure or an error on records with many child rows or several images.

Cause. Documented ceilings, and they are easy to hit with a long line-item table: the response must be under 15 MB before rendering, total image size across the document is capped at 30 MB, and the generated PDF cannot exceed 60 MB. Separately, invalid HTML markup can cause rendering to fail outright, which is why a stray unclosed tag in a rich text field can take down a document that has worked for months.

Fix. Paginate or limit the data, and sanitize any rich text you merge in. Note that rich text area formatting may not render as authored regardless.

Symptom: JavaScript-driven content is blank

Anything a script was supposed to draw is missing.

Cause. PDF rendering does not support JavaScript-rendered content. The renderer processes the markup as delivered. This is not a bug and will not change.

Fix. Compute the values server-side and render them into the markup.

Why the workarounds do not stick

Look at the list above and the pattern is clear. Rewriting your layout in stripped-down legacy CSS means maintaining a second stylesheet whose only job is to appease an aging renderer. Attaching images as static resources adds plumbing you own forever. Padding hacks for header overlap break on the next content change. Each is a patch on the same root cause, and none of them makes the engine newer.

The deeper cost is that these fixes are invisible to the next person. A future maintainer sees an oddly specific font choice, a hardcoded image width, and a magic top margin, with nothing explaining that all three are workarounds for a rendering service.

The durable fix: stop authoring against the legacy engine

The lasting answer is to stop hand-writing markup for a renderer you do not control. In ZeroExport, you design the document in a native WYSIWYG builder inside Salesforce and the document is defined structurally rather than as a page you style by trial and error. That changes the failure modes this article is about:

You design visually, so there is no "correct in the browser, broken in the file" gap to debug and no shadow stylesheet to maintain.
Layout is structure-aware. When a field is missing the layout adapts rather than leaving the gaps that plague hand-styled pages, and a section carrying a condition disappears along with its header.
Logic stays declarative. Conditional sections, repeating tables, and aggregates live in the template model instead of rendered= expressions scattered through markup.
Missing data surfaces before generation. Fields a template requires are marked on the template, and each record shows a readiness status naming the specific fields that are missing or blocked by field-level security, so a blank section is caught on the record rather than in the finished file.
Generation is consistent. The same template and the same record produce the same document, from a button, a Flow, or an Agentforce action.

One honest note: pixel-exact control over where every page breaks, and rendering very large documents at high volume, are platform-level concerns worth evaluating directly for any tool including this one. This article is about the everyday formatting failures of renderAs="pdf", which a native structure-aware builder sidesteps by design.

When Visualforce PDF is still okay

One simple, internal, rarely-changing document where the legacy constraints do not bother you? renderAs="pdf" is free and already there. Since Spring '26, a single server-side document with no UI is also a reasonable fit for Blob.toPdf(). You have outgrown both when formatting fidelity matters, when non-developers need to change the layout, or when you are patching the same header overlap for the third time.

FAQ

Why does font-weight bold not work in my Visualforce PDF?

Usually because your document contains multibyte characters, and Arial Unicode MS is the only font the rendering service supports for those. That font does not honor bold, so the styling is dropped. If you do not need multibyte characters, switching to another supported font restores bold.

Why is my image not showing in a Visualforce PDF?

The most common cause is that the image is inlined as a base64 data URI, which the rendering service explicitly does not support. WebP, SVG markup, and multipage TIFF are also unsupported. Serve images as static resources in PNG or JPEG format instead.

Why is my logo rendering at full size in a Visualforce PDF?

CSS max-width and max-height are ignored on images by the PDF renderer. Set explicit width and height attributes on the image, or resize the source file to its intended dimensions.

Why does my Visualforce PDF content overlap the header on later pages?

Header regions do not reserve space for subsequent pages the way you would expect, so body content flows underneath. The only available fix is manual margin and padding tuning, which breaks again whenever the content reflows.

Does the Spring '26 Blob.toPdf() update fix Visualforce PDF formatting?

No. It moves Blob.toPdf() onto the same Visualforce PDF rendering service, which improves fonts and multibyte character support and removes the need for a Visualforce page. The renderer itself is unchanged, so the CSS 2.1 ceiling, the image format restrictions, and the page mechanics described here still apply.

What are the size limits on a Visualforce PDF?

Salesforce documents three: the response must be under 15 MB before rendering, total image size across the document is capped at 30 MB, and the generated PDF cannot exceed 60 MB. Long line-item tables are the usual way teams hit these.