I am working on a WPF application where I need to implement a document generation and printing feature.
My Goal: I have dynamically generated HTML content (with CSS). I need to:
Convert this HTML content into a PDF document.
Ensure the output is strictly formatted to fit an A4 sheet (handling page breaks, margins, etc.).
Send this generated PDF directly to a printer.
My Question: What is the most reliable, industry-standard approach to achieve this in a modern WPF application?
I am looking for recommendations on the best libraries or built-in approaches to use. Specifically, I’d love to know:
Which libraries are best suited for this (e.g.,
WebView2,PuppeteerSharp,wkhtmltopdf,iText7,QuestPDF)?Are there any caveats I should watch out for regarding CSS support and A4 pagination?
How can I handle the printing part smoothly (e.g., silent printing vs. showing the Windows print dialog)?
Margaret LewisPosted Apr 30, 2026, 7:00 AM
Here are direct answers to your questions without extra framing.
1) Which libraries are best?
Best overall (recommended)
PuppeteerSharp or Playwright for .NET
These use a real Chromium engine, so they render HTML/CSS exactly like a browser. This is the most reliable and widely adopted approach today for HTML ? PDF.
Good alternative (simpler, commercial)
IronPDF
Easier setup, still Chromium-based, but paid.
Situational options
QuestPDF
Excellent if you are willing to build documents in C# instead of rendering HTML. Not suitable if your source is already HTML.
iText7 (pdfHTML)
Works for simpler HTML, but limited CSS support compared to browsers.
Not recommended for new work
wkhtmltopdf (and wrappers like DinkToPdf)
Outdated rendering engine, poor support for modern CSS (flexbox, grid), and no longer actively maintained.
2) Caveats (CSS support, A4 pagination)
CSS support
Chromium-based tools (PuppeteerSharp / Playwright / IronPDF):
Full support for modern CSS (flexbox, grid, media queries, print styles)
Best fidelity with real browser output
Non-browser engines:
Often fail with flexbox, grid, advanced layouts
Require workarounds or simplified HTML
A4 pagination
Regardless of library, correct pagination depends on your CSS.
Key rules:
Important points:
Use
@pageto define A4 size and marginsUse
break-before,break-after,break-insideAvoid relying on pixel-perfect layout without print CSS
Test with real content (long tables, images, etc.)
Common pitfalls
Content overflowing due to missing margins
Tables splitting awkwardly across pages
Fonts not embedding correctly
Differences between screen CSS and print CSS
3) Printing (silent vs dialog)
Show print dialog (simplest)
Open the PDF with default viewer and trigger print:
This depends on the system’s default PDF viewer and shows UI.
Silent printing (recommended for production)
Option A: Use a PDF rendering library
PDFium (via PdfiumViewer or similar)
Load PDF and send directly to a printer:
Option B: Use WebView2
Load the PDF and call:
Can be configured to suppress UI in some cases, but less predictable than PDFium.
Bottom line
Use PuppeteerSharp or Playwright for HTML ? PDF.
Control layout using proper print CSS (
@page, page breaks).Use PDFium-based printing for reliable silent printing.
This combination is currently the most robust and production-proven approach for WPF applications.
williamswelshPosted Jul 14, 2026, 5:53 AM
If preserving the original HTML layout is important, the conversion engine matters more than the output format itself. CSS support, embedded fonts, images, page breaks, and JavaScript-rendered content can all affect the final PDF. For simple HTML, many libraries work well, but for complex or responsive pages, it's worth testing a few options to see which produces the most accurate results. Also, if you're converting multiple HTML files, choosing a solution that supports batch processing can save a lot of time.
Cynthia SathuragiriPosted Apr 28, 2026, 4:37 PM
I’ve worked on something similar, and the most reliable approach today is to use a Chromium-based tool like PuppeteerSharp (or Playwright).
Basically, instead of trying to convert HTML using older libraries, you let a real browser engine render it and generate the PDF. That way you get proper support for modern CSS and accurate layout.
For A4 formatting, just use print CSS like:
and add page breaks where needed with
page-break-before.The overall flow is pretty straightforward:
HTML ? generate PDF (PuppeteerSharp) ? send to printer.
For printing, the quick option is using the default PDF viewer with a print command. If you need more control (silent printing, selecting printer, etc.), then using the Windows PrintQueue APIs is a better option.
I’d avoid wkhtmltopdf (outdated), iText for HTML (limited CSS support), and QuestPDF since it doesn’t support HTML at all.
In short, using PuppeteerSharp with proper print CSS is the cleanest and most reliable solution right now.
Deepika SawantPosted Apr 28, 2026, 2:49 PM
WebView2 ? Export to PDF ? PdfiumViewer ? Print silently or via dialog. This balances modern CSS support, native integration, and smooth printing workflows.
Use WebView2 or PuppeteerSharp for HTML ? PDF conversion (best CSS fidelity).
Apply CSS print styles for A4 formatting.
Use CSS print styles (
@page { size: A4; margin: 20mm; }).Control page breaks with
page-break-before,page-break-after, orbreak-inside.Test with complex layouts—tables, images, headers/footers.
PuppeteerSharp and WebView2 handle CSS print rules best; wkhtmltopdf is more limited.
Use PdfiumViewer or WPF’s
PrintDialogfor printing.Silent Printing:
Use
System.PrintingorPrintDocumentin WPF to send PDFs directly to a printer.Requires a PDF rendering backend (e.g., Adobe Reader COM automation, or libraries like PdfiumViewer).
Windows Print Dialog:
Use
PrintDialogin WPF for user-controlled printing.More user-friendly, but not silent.
Best Practice:
Generate PDF ? Load into a lightweight viewer (PdfiumViewer or Syncfusion PDF Viewer) ? Print via WPF print APIs.
This avoids relying on external apps like Adobe Reader.
For enterprise-grade compliance (PDF/A, accessibility), consider iText7.