Visualforce PDF vs a Document Generation Tool: How to Decide

Most comparisons on this site are against something you would pay for. This one is against the option you already have, that costs nothing, and that is sitting in your org right now.

renderAs="pdf" deserves to be taken seriously. Plenty of production documents run on it and should keep running on it. This post is the decision framework: what it genuinely costs, when it is the right call, and what changes when it is not.

If you want the technical explanation of why the formatting breaks — the rendering engine, the CSS ceiling, the font and image failures — that is covered in why Visualforce PDF formatting breaks and, for CSS specifically, why your CSS is not applying. This post assumes you already know it breaks and are deciding what to do about it.

A note on scope. We build ZeroExport, so we are biased about the conclusion. The cost analysis holds whatever you replace Visualforce with, including replacing it with nothing.

What Visualforce PDF actually costs

It is free to license. It is not free to own.

A rendering engine that stopped moving. renderAs="pdf" renders through a bundled engine that understands roughly CSS 2.1 and HTML 4. No flexbox, no grid, and the Lightning Design System does not render. The modern replacement renderer was piloted and then cancelled, so this is the engine you get, permanently.

A second stylesheet nobody wants. The practical consequence is a legacy-CSS shadow stylesheet whose only job is to satisfy that engine, maintained forever alongside the CSS that works everywhere else.

Failures that do not look like failures. font-weight: bold silently doing nothing with the one font that renders your special characters. Images ignoring max-width and arriving at full original size. Base64 images that display in the browser and vanish in the PDF. Nothing errors. The document just comes out wrong.

Trial-and-error layout. Content overlapping the header on page two gets fixed with padding, and the padding breaks the next time a field wraps to a new line.

Apex you now own. Grouping and subtotals in a Visualforce page mean logic in the page and its controller, with test coverage, deployments, and a person who understands it. That person eventually leaves.

None of this appears on an invoice. It appears in the third afternoon spent on header spacing.

Side by side

	Visualforce `renderAs="pdf"`	ZeroExport
License cost	Free	Paid, flat annual per org
Rendering engine	Legacy, roughly CSS 2.1 / HTML 4	Modern rendering pipeline
Modern CSS	Silently ignored	Renders as authored
Grouping and subtotals	Apex and markup you maintain	Declarative
Missing field	Blank gap, or a runtime error	Layout reflows, with a build-time warning
Who can change a layout	A developer	An admin
Ongoing artifacts	VF page, controller, tests, legacy CSS	A template

When Visualforce PDF is the right answer

Do not replace it if:

It is internal. An ops team receiving a slightly ugly PDF is not a business problem.
It is simple and stable. A flat list of fields and one total, unchanged for two years.
It already works. A page nobody has touched in eighteen months that produces the correct document is a solved problem. Leave it alone.
Volume and stakes are both low. A handful of internal summaries a week does not justify a purchase.

Free and working beats paid and better. We would rather say that than sell you something.

That said, checking costs nothing. ZeroExport has a free tier — three active templates, free forever, no credit card, with full document generation inside your org. If you are not sure whether your Visualforce page is as constrained as it feels, rebuild that one document and put the two PDFs side by side. Nothing gets switched off to run the comparison, and if the answer is "the VF page is fine," you have lost an afternoon and settled the question.

When it has quietly stopped being free

The picture changes when:

It is customer-facing and formatting fidelity is part of how you look.
It changes often, so every change is a developer, a deployment, and a regression risk.
The layout is structural — grouped subtotals, nested products, conditional sections — so the complexity lives in Apex rather than in a template.
You have fixed the same header overlap more than twice. That is not a bug, it is a category error about what the engine can do.
Something wrong has reached a customer and nothing warned you first.
Only one person can safely touch it, and business users queue behind them for a logo change.

The short version: when a layout change requires a deployment, you are paying for Visualforce PDF in the currency that is actually scarce.

What replaces it

The durable fix is to stop asking a 2010-era engine to render a modern document.

Author in a real template. Lay the document out once, with CSS that actually renders, and delete the legacy shadow stylesheet.

Keep logic declarative. Conditional sections, grouping, and repeating tables belong in a template model rather than in rendered= expressions scattered through markup and controller code.

Get warned before you ship. A template that references a field the query does not return should tell you so, with a location, rather than producing a silently broken PDF in production.

Let admins own layout. A logo size or a new subtotal should not consume developer time or a release window.

To be straight about the trade: this costs money, and there are Visualforce behaviors it does not replace. We make no claim on pixel-exact page-break control, so if you have hand-tuned page-break-inside rules that took weeks to get right, test before you commit. Raw rendering performance at very high volume is not our headline either.

And you do not have to do it all at once. There is no cutover here. Most teams move the loudest document first — the customer-facing one that changes every month — and leave the stable internal pages running on Visualforce indefinitely. A first wave of three documents fits inside the free tier, so the decision to keep going is made with evidence rather than with a forecast. The phased migration playbook covers sequencing the rest.

If you are deciding about a new build rather than an existing Visualforce page, the broader version of this question is covered in build vs buy.

FAQ

Is Visualforce PDF deprecated?

No, and that is the point. It is not going away, but the modern renderer piloted to replace it was cancelled, so the current behavior should be treated as permanent rather than as something a future release will fix.

Can I fix the CSS problems without replacing anything?

Partly. Rewriting in stripped-down legacy CSS does work. You are then maintaining a second stylesheet whose only purpose is to satisfy a legacy engine, which is a real cost even though it never appears as a line item.

Do I have to remove my existing Visualforce pages?

No. Most teams move the customer-facing, frequently-changing documents first and leave the stable internal ones exactly where they are.

Will my custom fonts work?

Standard web fonts behave as expected in a modern rendering pipeline, which is the specific thing the legacy engine cannot do. Custom and web fonts silently failing is one of the most common Visualforce PDF complaints.

Is ZeroExport native to Salesforce?

Yes. It is a managed package running entirely inside Salesforce, so replacing a Visualforce page does not mean sending document data to an external rendering service.