The best open-source HTML to PDF libraries in 2026

The best open-source HTML to PDF libraries in 2026 are Puppeteer (JavaScript, headless Chrome), WeasyPrint (Python, print CSS), Gotenberg (a Docker service any language can call), dompdf (PHP), and OpenHTMLtoPDF (Java). Avoid wkhtmltopdf and its wrappers: the project has been archived since 2023 and carries unpatched security vulnerabilities.

Every option above is genuinely free and genuinely good at something. The catch is that they belong to different engine families with very different ideas of what "renders your HTML" means, and most comparison articles either flatten that distinction or, worse, are written by a vendor steering you toward a paid product. At least one currently-ranking roundup still markets wkhtmltopdf as supporting "modern CSS," which stopped being true the better part of a decade ago.

This comparison checks the things listicles skip: live maintenance status (all figures pulled July 27, 2026), license type, and which engine family each library belongs to, because that, more than anything, predicts whether your document will come out right.

Key TakeawaysPick by engine family first: browser-based libraries (Puppeteer, Playwright, Gotenberg) render exactly like Chrome; layout-engine libraries (WeasyPrint) implement print CSS without JavaScript; parser-based libraries (dompdf, OpenHTMLtoPDF) support a subset of CSS and are lightest to run.All five top picks are actively maintained: WeasyPrint v69 ships 8.4M PyPI downloads a week, dompdf 6.6M monthly on Packagist, Gotenberg and Puppeteer push commits weekly.wkhtmltopdf is not on the list: archived January 2023, unpatched 9.8-severity SSRF (CVE-2022-35583), frozen 2016-era WebKit. Its wrappers inherit all three problems.Licenses matter in commercial products: dompdf and OpenHTMLtoPDF are LGPL; iText is excluded here because its free tier is AGPL, which most commercial teams can't ship.Free means free to run, not free to operate: browser-based fidelity costs you Chromium in production. Budget for that or plan the API exit ramp.

How to choose an open-source HTML to PDF library

Three engine families cover the whole field:

Browser-based (Puppeteer, Playwright, Gotenberg): a real headless Chromium loads your page, runs your JavaScript, and prints it. Fidelity is perfect by definition: it is the browser. Cost: a browser process in production, with the memory and ops that implies.

Layout-engine (WeasyPrint): a purpose-built renderer implements HTML and CSS for print, including paged-media features browsers handle poorly (margin boxes, named pages). No JavaScript execution at all.

Parser-based (dompdf, OpenHTMLtoPDF): pure-language libraries that parse markup and draw a PDF. Lightest to deploy (no binaries), narrowest CSS support: think CSS 2.1 plus selected extras, no flexbox or grid in most cases, no JavaScript.

Match the family to your documents: JS-rendered dashboards need a browser; designed print documents suit WeasyPrint; simple server-templated invoices run happily on dompdf.

The best open-source HTML to PDF libraries at a glance

1. Puppeteer, headless Chrome for Node.js; the fidelity default.
2. WeasyPrint, Python's print-CSS specialist.
3. Gotenberg, Chromium behind a Docker API; language-agnostic.
4. dompdf, PHP's standard, embedded in half the ecosystem.
5. OpenHTMLtoPDF, pure-Java rendering, community-maintained.
6. Playwright, Puppeteer's sibling; use it if you already test with it.
7. PDFKit / pdfmake, programmatic PDFs when there's no HTML to convert.

1. Puppeteer

Puppeteer is the default answer for a reason: page.pdf() gives you exactly what Chrome would print, ten lines of Node.js in. Flexbox, grid, webfonts, client-side rendering, print CSS: all of it behaves, because a real browser is doing the work.

The operational bill arrives later. Chromium processes leak memory under sustained load, want pooling and recycling, and don't fit serverless size limits without trimmed builds. Our Node.js HTML-to-PDF guide covers the full setup, the npm packages to avoid, and the production realities.

Best for: Node.js teams, JS-rendered content, anyone who needs browser-perfect output and can run a browser.

2. WeasyPrint

WeasyPrint is the most interesting library on this list, because it isn't a browser and doesn't want to be. It implements CSS for paged media properly: @page rules, margin boxes, page counters, footnote-adjacent layouts that browsers fumble. Version 69 shipped this year; 8.4 million PyPI downloads a week says Python trusts it.

The boundary is JavaScript: there is none. Render your data server-side into HTML first, or WeasyPrint isn't your tool. CSS coverage, while excellent for print, also isn't Chrome; check its documentation for specifics. Our WeasyPrint guide walks the details.

Best for: Python teams producing designed print documents (reports, statements, books) from server-rendered HTML.

3. Gotenberg

Gotenberg solves a packaging problem: it wraps headless Chromium (plus LibreOffice for office formats) in a Docker container with an HTTP API. Any language POSTs HTML and gets a PDF; nobody links a browser into their app. 12,700 GitHub stars and steady releases make it the standard self-hosted conversion service.

You still operate it: it's your container, your scaling, your Chromium updates, and PDF bursts share resources with whatever else the host runs. That line, self-hosting the service versus calling a hosted one, is exactly what our Gotenberg alternatives comparison maps.

Best for: polyglot stacks and Docker-native teams who want browser fidelity without embedding a browser per service.

4. dompdf

dompdf is PHP's institution: 6.6 million monthly Packagist installs, the engine behind Laravel's most-used PDF packages. Pure PHP, no binaries, runs on shared hosting: deployment doesn't get easier.

It's parser-based, so temper expectations: CSS 2.1-era layout, limited flexbox, no grid, no JavaScript. Beautiful for invoice-shaped documents, wrong for anything designed in modern CSS. LGPL licensing is fine for use, worth a read before modification. When templates outgrow it, the escape paths are in our dompdf alternatives comparison.

Best for: PHP/Laravel apps generating simple, template-driven documents.

5. OpenHTMLtoPDF

OpenHTMLtoPDF is Java's pure-JVM renderer: XHTML plus CSS 2.1 (with some extensions) drawn straight to PDF, no browser involved. One maintenance nuance to know: the original danfickle repository has been effectively unmaintained since around 2022 (last release 2021), and active development continues in a community fork under the openhtmltopdf organization (commits as recent as this week). Pin your dependency to the maintained line.

Strict-parsing is its personality: it wants well-formed markup and rewards it with deterministic output. Same family limits as dompdf: no JS, no modern layout modules.

Best for: Java shops rendering controlled, well-formed templates without JVM-external dependencies.

6. Playwright, PDFKit, and pdfmake, briefly

Playwright renders PDFs with the same Chromium as Puppeteer (its page.pdf() is Chromium-only). If it's already in your test stack, reuse it rather than adding Puppeteer.

PDFKit and pdfmake aren't HTML converters at all: they build PDFs from drawing commands and document definitions. When your "document" is data with no HTML heritage, they're lighter than any converter; when you have HTML, they mean rebuilding it by hand.

Avoid in 2026: wkhtmltopdf and its wrappers

wkhtmltopdf powered a decade of PDF generation, which is why wrappers for it still exist in every language, and why it still appears in comparison articles. The facts as they stand: repository archived January 2023, organization archived 2024, last release 2020, rendering engine frozen at roughly 2016 WebKit, and an unpatched 9.8-severity SSRF vulnerability (CVE-2022-35583) that makes it unsafe for any untrusted HTML.

Every wrapper (PHP snappy, Python pdfkit, Node wrappers, .NET DinkToPdf) inherits all of it. Migration paths by language and use case are in our wkhtmltopdf alternatives guide.

Library vs SDK vs API: which do you need?

The terms blur in search results, so here's the practical split. An open-source library (everything above) runs inside your process or infrastructure: free, self-operated. A commercial SDK (iText, IronPDF, Aspose and friends) is the same deployment model with a license fee attached, usually buying support and proprietary engines; note that iText's free edition is AGPL, which is why it isn't in this list. An API moves rendering off your infrastructure entirely: per-document pricing instead of per-developer licensing, and the browser stops being your operational problem.

The honest sequencing for most teams: start with the right library from this page. If rendering becomes a recurring maintenance line (browser ops, fidelity bugs, scaling), that's the signal to compare hosted options; our best HTML to PDF APIs roundup does that with verified pricing. Transformy sits in that category: the same headless Chrome fidelity as the browser-based libraries here, minus the browser on your payroll, free for 100 documents a month.

FAQ

What is the best free HTML to PDF library?

Puppeteer for Node.js and full browser fidelity, WeasyPrint for Python print documents, dompdf for PHP simplicity, Gotenberg when multiple languages need one self-hosted converter. All are free, actively maintained, and permissively or LGPL licensed.

What's the best open-source option without running a headless browser?

WeasyPrint (Python) for print-grade CSS, or dompdf (PHP) and OpenHTMLtoPDF (Java) for lighter template rendering. All three run without Chromium; none executes JavaScript, so client-rendered content is out of scope.

Is there an open-source HTML to PDF library with JavaScript support?

Only the browser-based family: Puppeteer, Playwright, or Gotenberg. Executing JavaScript requires a browser engine, so any tool promising JS support without one is either wrapping a browser or overpromising.

Is wkhtmltopdf still safe to use?

Not for untrusted input, and not advisable for anything new: the project is archived with unpatched CVEs and a frozen 2016-era engine. Existing installs should migrate to a browser-based library or a hosted Chrome API.

Conclusion

The 2026 shortlist, by situation:

• Node.js → Puppeteer (or Playwright if it's already installed).
• Python, print documents → WeasyPrint.
• PHP, simple templates → dompdf.
• Java, no external binaries → OpenHTMLtoPDF (the maintained fork).
• Many languages, one converter → Gotenberg in Docker.
• Anything wkhtmltopdf → migrate.

Every open-source HTML to PDF library on this list is free to adopt today. Run your hardest real template through your pick before standardizing on it, and if the operating cost of browser-grade rendering ever outgrows a $99 line item, you'll already know where the exit ramp is.