The Definitive Guide to HTML to PDF Conversion Tools in 2026

How Rendering Engines Define PDF Tool Capabilities

The single most important factor in choosing an HTML-to-PDF tool is its rendering engine. Every other capability, CSS support, JavaScript execution, rendering fidelity — flows from this architectural decision.

Chromium/Blink-based tools (Puppeteer, Playwright, IronPDF, Gotenberg, PDFCrowd, PDFShift, Headless Chrome CDP, Selenium) use Google's browser engine. They load a webpage identically to Chrome, support full CSS3 (Flexbox, Grid, variables, media queries), and execute all modern HTML code. The trade-off is resource consumption: \~85–200 MB RAM per conversion under concurrent load, Docker images of 1.5–2 GB, and 5–15 second cold starts in serverless environments.

Custom CSS-to-PDF engines (PrinceXML, PDFreactor, Antenna House, WeasyPrint, iText pdfHTML) parse HTML and CSS using purpose-built renderers. They excel at CSS Paged Media—running headers, footer sections, footnotes, and margin boxes, features web browsers fundamentally lack. PrinceXML pioneered this approach in 2003; its chairman Håkon Wium Lie co-created CSS itself. PDFreactor offers the best JavaScript support among custom engines (ECMAScript 2025 via GraalJS). Antenna House leads in internationalization (80+ languages, 30+ scripts) and raw performance via its native C/C++ engine.

Programmatic builders (PDFKit, pdfmake, jsPDF) construct PDF files from code rather than direct HTML input. They produce vector output with selectable text but require developers to define the layout programmatically—no HTML/CSS parsing whatsoever. Client-side screenshot tools (html2pdf.js) capture browser-rendered DOM as raster images, producing non-selectable, non-searchable documents with significant page size and quality limitations.

Complete Tool-by-Tool Comparison Matrix

The following table distills the most decision-relevant attributes for all 23 tools. Detailed analysis of each follows in subsequent sections.

IronPDF: Convert HTML Files to PDF with Ease with this Stand Out Library

IronPDF deserves extended analysis because it occupies a unique position: a Chromium-based rendering engine wrapped in a native .NET library with an unusually broad PDF toolkit. Where Puppeteer requires developers to install and bolt on separate libraries for encryption, digital signatures, or form manipulation, IronPDF bundles all of these into a single NuGet package.

The rendering architecture embeds a custom-optimized Chrome engine that stays warm for subsequent renders, eliminating the per-PDF process spawn that makes raw Puppeteer expensive at scale. IronPDF claims 5–20× faster performance than web-driver-based solutions for high-load scenarios. G2 reviews confirm "100+ page reports with pixel-perfect accuracy" and full CSS fidelity.

The API ergonomics are genuinely minimal for any HTML file. The core pattern is two lines of C#:

var pdf = new ChromePdfRenderer().RenderHtmlAsPdf("<h1>Hello</h1>");

pdf.SaveAs("output.pdf");

var pdf = new ChromePdfRenderer().RenderHtmlAsPdf("<h1>Hello</h1>");

pdf.SaveAs("output.pdf");

Dim pdf = (New ChromePdfRenderer()).RenderHtmlAsPdf("<h1>Hello</h1>")

pdf.SaveAs("output.pdf")

Configuration scales cleanly: RenderingOptions exposes CSS media type switching, JavaScript wait strategies, custom CSS injection, and responsive viewport control via PaperFit. The toolkit breadth is the primary differentiator. IronPDF supports merge, split, copy/delete files, AES-256 encryption, X.509 digital signatures, permanent redaction, HTML-based watermarking, page orientation PDF/A compliance, PDF/UA accessible output, and AcroForm creation from HTML

Web Automation Tools Share Chromium Strengths and Limits

Puppeteer, Playwright, Headless Chrome CDP, Selenium, and Gotenberg all ultimately invoke Chromium's Page.printToPDF CDP command. Their differences lie in abstraction level, language support, and operational ergonomics.

Puppeteer (Google, Apache 2.0) remains the most mature Node.js option at 31.1k GitHub stars. Its page.pdf() API exposes paper format, scale (0.1–2×), margins, header/footer HTML templates with injection classes (pageNumber, totalPages, date), background printing, page ranges, and experimental document outline generation. A Carriyo case study documented 10,000 PDFs/day on AWS Lambda. The page.createPDFStream() method handles large documents without memory crashes. Puppeteer averaged 7.84 seconds for 10 PDFs in benchmarks, roughly 3× faster than wkhtmltopdf for the same content.

Playwright (Microsoft, Apache 2.0) offers nearly identical PDF capabilities but adds official multi-language support (JavaScript, Python, Java, .NET) and built-in auto-waiting that reduces flakiness compared to Puppeteer's manual waitForSelector. Version 1.42+ added PDF outline/bookmark generation from heading structure. PDF generation is Chromium-only, it does not work with Playwright's Firefox or WebKit browsers. Benchmarks show Playwright averaging 4.513s versus Puppeteer's 4.784s for navigation-heavy workflows.

Gotenberg wraps Chromium (and LibreOffice for Office documents) in a Go-based Docker HTTP API under MIT license. It is the reference architecture for PDF-as-a-microservice: stateless, language-agnostic via multipart/form-data, and available as optimized images for Cloud Run and AWS Lambda. It uniquely adds PDF encryption (AES-256 via QPDF), PDF/A compliance (1a, 2b, 3b), merge/split operations, and PDF metadata editing, capabilities no other Chromium-based tool provides natively. Concurrency is limited to 6 parallel Chromium conversions per instance (configurable), with horizontal scaling via additional containers.

Headless Chrome CDP is the lowest-level option, zero library overhead, just Chrome binary and a CDP client in any language (Go, Python, Ruby, Elixir). The CLI mode (chrome --headless --print-to-pdf) is being deprecated in favor of the CDP API. The trade-off is managing Chrome process lifecycle, zombie processes, and implementing your own wait strategies manually.

Selenium + browser PDF is the weakest option for PDF generation. Its standard PrintsPage API has limited options; full header/footer templates require the CDP bridge (driver.execute_cdp_cmd("Page.printToPDF", {...})), which only works with Chromium and is itself temporary (transitioning to WebDriver BiDi). The selenium-print package documentation explicitly warns: "if your priority is performance, this is not the library for you."

None of these tools produce fillable PDF forms — Chromium's print-to-PDF flattens all form elements. None support PDF encryption, digital signatures, or redaction natively. For these features, post-processing with external libraries (pdf-lib, QPDF, iText) is required — or use Gotenberg, which integrates these tools.

Commercial CSS Engines Excel at Paginated PDF Document Publishing

PrinceXML, PDFreactor, and Antenna House command premium prices because they implement W3C CSS Paged Media specifications that web browsers simply do not. They handle page size settings, left margin boxes, footnotes, named pages, and automatic table-of-contents generation.

PrinceXML ($3,800/server one-time, $495/desktop) is the gold standard. Its custom engine, written in Mercury, has produced the highest-fidelity CSS Paged Media output since 2003. Prince supports Flexbox (since v12, 2018) and CSS Grid (since v16, \~2024, with cross-page fragmentation still maturing). JavaScript is limited to ES5 only — no arrow functions, Promises, or async/await. It supports PDF/A-1a/1b/3a/3b, PDF/UA-1, PDF/X-1a/3/4, RC4 encryption (40/128-bit), but does not support digital signatures (a long-standing omission). A free non-commercial license with watermark is available for development.

PDFreactor ($1,908/yr Pro subscription) is the most technically advanced. Its GraalJS integration provides ECMAScript 2025 support (requiring Java 20+), making it the only custom CSS engine with full modern JavaScript. It supports CSS Regions, CSS Shapes, baseline grids, and the broadest set of PDF/A variants (1a through 3u). Critically, it includes built-in digital signing — something Prince lacks. Deployment is via Java JAR, embedded Jetty web service, or Docker container. Enterprise customers include Dell Technologies and Deutsche Post (500,000+ staff).

Antenna House Formatter ($5,000/server perpetual for XSL-FO, $1,250/standalone for CSS) is unique as a dual XSL-FO and CSS engine. Its native C/C++ implementation delivers the fastest raw performance with the lowest memory footprint. It supports 80+ languages and 30+ scripts — unmatched for internationalization. However, it has no JavaScript support whatsoever, and CSS Grid is not supported. Its primary audience is XML-centric publishing workflows (DITA, DocBook) where XSL-FO provides more granular control than CSS.

Java Ecosystem Tools Range from Enterprise to Lightweight

iText pdfHTML is the most capable Java option, supporting Flexbox (com prehensive since 2025), CSS Grid (since 2024), CSS Paged Media headers/footers, and HTML-to-AcroForm conversion. Its critical constraint is licensing: AGPL v3 requires open-sourcing your entire application if you distribute it or offer it as a network service. Commercial licenses range from \~$10,000/year (small deployments) to $210,000+/year (enterprise), with an industry average of \~$45,000/year per Vendr data. iText executes no JavaScript, it's a static HTML/CSS parser only.

OpenHTMLtoPDF and Flying Saucer are the LGPL-licensed alternatives, freely usable in proprietary software. Both are limited to CSS 2.1 — no Flexbox, no Grid — and execute no JavaScript. OpenHTMLtoPDF's original repository (danfickle/openhtmltopdf, 2.1k stars) was abandoned in \~2022; an active community fork at io.github.openhtmltopdf (Maven Central, v1.1.31, September 2025) has migrated to PDFBox 3.x. Flying Saucer (2.2k stars) remains actively maintained by @asolntsev (v10.0.6, December 2025) but now requires Java 21+ for the latest version. Both tools require well-formed XHTML input, they cannot process arbitrary "wild" HTML.

⚠️ Source quality note: CSS support claims for OpenHTMLtoPDF and Flying Saucer come primarily from project READMEs and community reports. No comprehensive CSS support matrices or third-party validation exists for either tool. Performance claims are self-reported with no independent benchmarks.

Client-side JavaScript Tools Serve Narrow Use Cases Well

pdfmake (12.2k stars, 1.1M+ weekly npm downloads) is the strongest client-side option for structured documents. It uses a declarative JSON document definition — not HTML — with built-in automatic pagination, table header repetition across pages, dynamic headers/footers with page counts, and vector output (searchable, selectable text). It supports PDF/A (beta) and encryption. The learning curve is its declarative syntax, which requires re-expressing content that may already exist as HTML.

PDFKit (10.5k stars, 1.2M+ weekly downloads) provides low-level imperative control, a canvas-like API for precise positioning. Its streaming API makes it memory-efficient for large server-side documents. It supports AcroForm creation, PDF/UA accessibility, and RC4/AES encryption. However, it has no HTML/CSS parsing and no built-in table support (requiring plugins like pdfkit-table).

jsPDF (31.1k stars, \~2.5M weekly downloads) is the most popular by downloads. Its .html() method uses html2canvas to capture DOM as raster images, producing non-selectable, non-searchable PDFs with large file sizes. Its AcroForm plugin can create fillable form fields programmatically, but not from HTML form elements. The canvas size limit (\~16,384px height) causes blank pages for long documents.

html2pdf.js (4.8k stars) wraps jsPDF + html2canvas into the simplest possible API: html2pdf(element). The output is entirely raster images. The canvas size limit is its most critical flaw — documents exceeding \~16,384px render as completely blank pages (GitHub issue #19). It has 462 open issues, runs only in browsers (no Node.js), and produces non-accessible output.

Cloud APIs trade control for operational simplicity

DocRaptor ($15–$1,000+/mo) is the only API using PrinceXML, giving it unmatched CSS Paged Media support, automatic HTML-to-fillable-PDF conversion, and WCAG/Section 508 accessible output. It offers a 99.99% uptime SLA, SOC 2 and HIPAA compliance, 30 concurrent documents regardless of plan, and unlimited free watermarked test documents. The trade-off is Prince's ES5-only JavaScript limitation and cloud-only deployment.

Nutrient Document Engine (formerly PSPDFKit, rebranded 2024 after €100M from Insight Partners) is the most comprehensive platform — not just HTML-to-PDF but a full document processing SDK spanning Web, iOS, Android, .NET, and more. It offers SOC 2 Type II certification, WCAG 2.2 AA compliance, AI-powered redaction, and cryptographic digital signatures. Self-hosted Docker deployment is available. DWS cloud API pricing starts at $67/month (1,000 credits, with HTML-to-PDF costing 0.5 credits each). SDK licensing is opaque, requiring sales contact, with enterprise contracts reportedly reaching significant annual commitments.

PDFShift stands out for simplicity: 3-line integration, a generous free tier (50 conversions/month), 50 parallel conversions on all plans, privacy-first data handling (no storage of documents), and HIPAA BAA availability. Pricing runs $9–$99+/month. It lacks CSS Paged Media, fillable forms, and accessible PDF support.

PDFCrowd uses Chromium with credit-based pricing tied to output file size (1 credit = 0.5 MB output), making costs unpredictable for variable-size documents. Rate limits range from 15–360 conversions/minute by plan. It lacks accessible/tagged PDF support and has no public uptime SLA.

APITemplate.io ($19–$179/mo for PDF-only plans) focuses on template-driven generation with a WYSIWYG editor, Zapier/Make.com integrations, and regional API endpoints (US, EU, Singapore, Australia). It's optimized for repetitive document types (invoices, certificates, reports) rather than arbitrary HTML conversion.

wkhtmltopdf is a critical security risk that demands replacement

wkhtmltopdf was archived on GitHub in January 2023 and marked as no longer maintained by administrators in July 2024. Its last release (0.12.6, June 2020) uses a Qt WebKit engine from approximately 2012 with no security patches since archival. The most severe vulnerability, CVE-2022-35583 (CVSS 9.8 Critical), enables server-side request forgery: an attacker injecting an iframe into user-supplied HTML can access internal network resources, including AWS EC2 instance metadata at 169.254.169.254, potentially leading to complete infrastructure takeover. CVE-2020-21365 (CVSS 7.5) enables directory traversal to read local files.

The wkhtmltopdf maintainer's own status page warns: "Do not use wkhtmltopdf with any untrusted HTML." CiviCRM issued CIVI-PSA-2024-01 recommending immediate removal. Pantheon removed it from PHP Runtime Gen 2 in 2025. Despite this, wkhtmltopdf remains embedded in wrapper libraries across every major language ecosystem (Python's pdfkit, Ruby's wicked_pdf, PHP's KnpSnappy, .NET's DinkToPdf).

Migration paths: Puppeteer/Playwright for full JavaScript execution (closest functional equivalent), WeasyPrint for Python stacks not needing JS, Gotenberg for microservice architectures, or DocRaptor/PrinceXML for CSS Paged Media needs.

Performance benchmarks reveal stark resource trade-offs

Independent benchmarks from Kyotu Technology and hardkoded.com provide quantitative comparisons:

WeasyPrint Docker images are dramatically smaller at 200–400 MB, and the rendering engine has no Chromium dependency. However, WeasyPrint is known to be slow for complex documents — a 52-page PDF took \~100 seconds in one benchmark, and large tables (5,000+ rows) can consume 1.4+ GB RAM.

For serverless, the critical metric is cold start time. Chromium-based Lambda functions experience 5–15 second cold starts due to binary decompression. Using @sparticuz/chromium-min (\~50 MB compressed) with puppeteer-core fits within Lambda's 250 MB limit and reduces package size from \~41 MB to \~769 KB. Provisioned concurrency drops cold starts to \~400 ms but adds cost. Lambda memory should be at minimum 1,024 MB, ideally 1,600 MB for reliable Chromium PDF generation.

Security capabilities vary dramatically across tools

Only iText 7 and IronPDF provide the full security trifecta of encryption, digital signatures, and redaction. iText 7 Suite 9.5 is adding post-quantum resilient signature algorithms for future-proofing. Among cloud APIs, DocRaptor (SOC 2, HIPAA) and Nutrient (SOC 2 Type II, HIPAA, WCAG 2.2) lead in compliance certifications.

Deployment gotchas every team should anticipate

Fonts are the #1 cause of rendering differences between development and production. Minimal Docker images lack fonts entirely, producing tofu characters (□) for non-ASCII text. The solution is installing comprehensive font packages — the Noto font family covers virtually every writing system. For CJK support, fonts-noto-cjk is essential. Custom fonts should be copied to /usr/local/share/fonts/ with fc-cache -f -v run afterward.

Chromium sandboxing in Docker is the #2 deployment issue. Chromium requires Linux kernel namespaces that Docker containers often lack, producing Running as root without --no-sandbox is not supported errors. The security-correct solution is creating a non-root user (useradd -r pptruser); the expedient solution is --no-sandbox, which reduces security and should only be used for trusted content.

Memory accumulation is the silent killer in long-running Chromium processes. Memory increases with each conversion, eventually triggering OOM crashes. Critical mitigations include: increasing Docker shared memory (--shm-size=512M, as the 64 MB default causes crashes), using --disable-dev-shm-usage, restarting browser instances after N conversions (Gotenberg does this automatically after 100), and using dumb-init or Docker --init to reap zombie processes. A single 50,000-row HTML table can consume 10+ GB RAM in Chromium.

JavaScript timing causes incomplete PDFs when dynamic content hasn't finished loading. Use waitUntil: 'networkidle0' (waits for zero network connections for 500 ms) or page.waitForSelector('.data-loaded') for explicit element readiness. Gotenberg mitigates this by waiting for DomContent, Load, NetworkIdle, and LoadingFinished events by default, adding \~2 seconds baseline latency but ensuring completeness.

Which tool fits which use case

Invoices and statements: WeasyPrint (Python stacks — lightweight, excellent CSS Paged Media, no Chromium overhead), Gotenberg (language-agnostic microservice), or pdfmake (client-side structured documents). For .NET, IronPDF provides the most ergonomic API.

Reports and dashboards with charts: Puppeteer or Playwright — only full browser engines can execute D3.js, Chart.js, or Plotly natively. WeasyPrint cannot render JavaScript-generated charts. IronPDF's Chromium engine handles this within .NET applications without spawning external processes.

SPA rendering to PDF: Puppeteer or Playwright are the only realistic options. Modern frameworks (React, Angular, Vue) require full browser execution. The waitUntil configuration is critical for ensuring all asynchronous content has loaded.

Compliance and security (PDF/A, digital signing, encryption): iText 7 (most comprehensive but expensive), IronPDF (.NET, broad security features), or PDFreactor (Java, built-in signing). Chromium-based tools require external post-processing for any security features.

Serverless and containers: Gotenberg (purpose-built for containers, MIT license, Cloud Run/Lambda images), or puppeteer-core + @sparticuz/chromium-min for AWS Lambda (50 MB compressed, fits within limits).

Print-quality publishing: PrinceXML or DocRaptor (API) — nothing else approaches their CSS Paged Media fidelity for running headers, footnotes, cross-references, and professional typography.

Batch processing at scale: Gotenberg with horizontal scaling (multiple containers behind a load balancer), IronPDF with async batch processing (RenderHtmlAsPdfAsync + Parallel.ForEach), or WeasyPrint with Celery workers for Python environments.

Conclusion

The HTML-to-PDF ecosystem in 2026 has matured into clearly differentiated tiers. Chromium-based tools have won the rendering fidelity war — their output matches what users see in Chrome, and they handle modern JavaScript and CSS without compromise. But this fidelity comes at a resource cost that makes lightweight alternatives (WeasyPrint, pdfmake) compelling for constrained environments.

Three insights stand out from this analysis. First, the gap between Chromium tools and CSS Paged Media engines is narrowing but remains fundamental — if your documents need running headers, footnotes, or page-aware layouts, PrinceXML, PDFreactor, or WeasyPrint still outperform any browser-based approach. Second, security is an afterthought in most tools — only IronPDF and iText 7 provide encryption, signatures, and redaction in a single package, while the entire Chromium ecosystem produces unprotected PDFs by default. Third, the wkhtmltopdf migration is not optional — its CVSS 9.8 SSRF vulnerability is actively exploitable, and every organization still using it should treat replacement as a security incident, not a feature request.