Best HTML to PDF Libraries for Java
Compare Java HTML-to-PDF libraries by markup, CSS, JavaScript, Java version, licensing, and PDF needs, then choose with a representative test set.
There is no universal best HTML-to-PDF library for Java. For controlled, well-formed XHTML templates and CSS 2.1-oriented layouts, start with OpenHTMLtoPDF or Flying Saucer’s pure-Java PDF artifact. If your HTML depends on JavaScript or modern browser behavior, evaluate PDFreactor or Flying Saucer’s Chrome-backed artifact. If your team already uses iText Core, evaluate pdfHTML. Confirm the license, Java baseline, pagination, fonts, and output requirements against your own documents before choosing.
This guide compares the documented rendering models and tradeoffs of four options. The sources describe capabilities and constraints; they are not independent rendering tests or performance benchmarks.
1. Comparison at a glance
| Library | Good starting point | Important checks | License and runtime notes |
|---|---|---|---|
| OpenHTMLtoPDF | Templates you control, authored as well-formed XHTML/XML with a CSS 2.1-oriented layout. | It supports a reasonable subset of XHTML and some HTML5. It does not run JavaScript or implement flexbox and grid. Do not expect modern browser behavior. | The project states LGPL 2.1 or later. Review the exact version and all dependency licenses. |
| iText pdfHTML | Teams already using iText Core or needing its HTML/XML-and-CSS conversion add-on. | It is not described as a browser engine. Validate the HTML elements, CSS, pagination, and output profiles you require. Release 6.3.3, dated 2026-07-08, added :is(), :where(), and :not() support and addressed CSS Grid pagination and list-rendering issues. |
iText Core is offered under AGPL or commercial licensing. Review compatibility and add-on requirements. |
| Flying Saucer | Pure-Java rendering for well-formed XML/XHTML and CSS 2.1 documents, or its separate Chrome-backed artifact for modern HTML5/CSS3. | Select the artifact deliberately: flying-saucer-pdf uses OpenPDF; flying-saucer-chrome-pdf delegates to chrome-headless-shell. The README marks flying-saucer-pdf-openpdf as replaced and no longer supported. |
The project states LGPL 2.1 or later. Its listed Java floor changes by release line: Java 11+ from 9.5.0, Java 17+ from 9.6.0, and Java 21+ from 10.0.0. Verify the selected artifact and dependencies. |
| PDFreactor | Commercial-category evaluation when HTML5 parsing or JavaScript processing matters. | Version 12.7.1 documents a built-in HTML5 parser and JavaScript processing for HTML conversions. JavaScript processing is for HTML, not XML; this does not establish full browser parity. | Confirm current Java support, license, deployment terms, and rendering behavior with the vendor and your own documents. |
Primary references: OpenHTMLtoPDF README and changelog, iText product catalog, pdfHTML 6.3.3 release notes, Flying Saucer README, and the PDFreactor manual.
2. Choose by rendering model
Choose an XHTML/CSS renderer when you control the input
OpenHTMLtoPDF and Flying Saucer’s pure-Java PDF artifact suit documents designed for their supported markup and CSS model. Treat the HTML as a document template, not as an arbitrary web page: produce well-formed XHTML, keep CSS within the renderer’s supported subset, and test page breaks and assets. OpenHTMLtoPDF specifically advises crafting documents for its engine; its README suggests avoiding floats near page breaks and using table layouts where appropriate.
Choose JavaScript-capable processing when scripts build the document
If the page requires JavaScript to populate content or relies on browser-oriented HTML/CSS, put PDFreactor and Flying Saucer’s Chrome-backed artifact on the shortlist. Check what each product supports for the exact HTML input, scripts, external resources, and deployment environment. “JavaScript processing” or “Chrome-backed” alone does not prove that every browser page will render identically.
Choose pdfHTML when iText is already part of your stack
pdfHTML is iText’s HTML-to-PDF add-on for iText Core. Confirm add-on and Core versions, licensing, CSS needs, pagination, and any PDF conformance targets. Avoid starting a new integration with legacy XML Worker: iText identifies XML Worker with iText 5, which is end-of-life, and identifies pdfHTML as the HTML-to-PDF tool for iText Core.
3. A practical selection checklist
- Fix the input contract. Is the input controlled, well-formed XHTML, generated HTML, or arbitrary third-party web content? Test malformed markup tolerance if your source is not under your control.
- List required CSS and layout behavior. Include the selectors and layout features your templates actually use, plus headers, footers, columns, tables, and page-break rules. Check support in the specific release.
- Decide whether JavaScript must execute. If scripts produce content or alter layout, exclude renderers that do not run scripts. OpenHTMLtoPDF says it does not run JavaScript.
- Inventory external assets. Check fonts, images, stylesheets, authentication, redirects, and network restrictions. Confirm how the renderer resolves each asset and what happens when it cannot load.
- Check the Java baseline and deployment model. Compare your JDK to the precise release and artifact. A Chrome-backed option also has a browser runtime to deploy and operate.
- Set PDF requirements. Specify page size, margins, page breaks, metadata, accessibility, PDF/A or PDF/UA needs, and language direction before comparing output.
- Review licenses and support. Check the library and transitive dependencies against your distribution model. For commercial products, verify current license and deployment terms directly.
- Render a representative corpus. Compare real documents and inspect every page, including long tables, large images, unusual fonts, right-to-left text, and edge-case content.
4. Build a representative evaluation set
Feature lists are a shortlist, not evidence that your documents will paginate correctly. Prepare a small, version-controlled set of representative inputs and expected outputs before committing to a renderer.
- A short document and a long document that crosses many page boundaries.
- Tables that span pages, wide tables, and rows that should not split.
- Long words, URLs, and paragraphs; lists; nested blocks; and explicit page breaks.
- Local and remote images, SVG if needed, custom fonts, and missing-asset cases.
- Required scripts, forms or generated content, and the actual CSS selectors used in production.
- Accented characters, non-Latin scripts, RTL text, and bidirectional text if relevant.
- The PDF properties you need: page size, orientation, margins, metadata, accessibility, PDF/A or PDF/UA.
For each candidate, keep the same HTML, CSS, assets, fonts, Java version, and runtime configuration. Inspect visual output page by page; automate image comparison only as a supplement because antialiasing and font rendering can differ. Record failed assets, clipped or split content, page count, memory behavior, and render time on your own workload. The dossier contains no comparative benchmark, so there is no defensible universal speed ranking.
5. Common rendering and deployment problems
| Symptom | Likely cause | What to check |
|---|---|---|
| Modern layout collapses or differs from a browser | The renderer supports a narrower CSS/layout model than the page expects. | Check the exact CSS support. Simplify or adapt the template, or evaluate a browser-backed or HTML5-capable option. |
| Content that JavaScript adds is missing | The chosen engine does not execute JavaScript, or scripts are unsupported for that input mode. | Confirm the renderer’s documented behavior and HTML/XML mode. OpenHTMLtoPDF does not run scripts; PDFreactor documents processing for HTML, not XML. |
| Rows, floats, or sections split badly | Pagination rules and renderer layout behavior differ from browser expectations. | Test the specific layout with long content. For OpenHTMLtoPDF, follow the project’s guidance to avoid floats near page breaks and consider table layouts. |
| Images or styles are absent | Asset URLs may resolve differently in the conversion environment, or resources may be unavailable. | Check base paths, network access, redirects, authentication, and whether every referenced asset is reachable in the runtime. |
| Characters render as boxes or fallback glyphs | The required font is not available or embedded as expected. | Package and configure the needed fonts, then validate all scripts and glyphs. OpenHTMLtoPDF’s README reports no OpenType font support; verify whether that limitation applies to your requirements and version. |
| Right-to-left or bidirectional text is incorrect | Language direction support may be limited and varies by engine. | Test real RTL examples early. OpenHTMLtoPDF reports limited RTL/bidirectional support; confirm the current version’s behavior. |
| Build fails on the target JDK | The selected release line or a dependency requires a newer Java baseline. | Check the exact artifact’s Java requirement and the resolved dependency tree. Flying Saucer’s minimum varies across release lines. |
| Deployment fails after selecting a Chrome-backed artifact | The expected browser runtime is unavailable or not configured for the deployment environment. | Account for chrome-headless-shell in packaging and operations; test in the same container or host environment used in production. |
6. Performance, reliability, and cost
There is no source-backed benchmark that ranks these libraries. Measure with your own document corpus, concurrency, fonts, external assets, and runtime. Track render latency, memory use, output size, page count, and failure rate as load changes. Keep test inputs stable so a renderer upgrade can be compared against the previous release.
Reliability depends on more than conversion code: external resources can fail, templates can produce pathological page layouts, and a browser runtime adds another deployable component. Make asset availability predictable, bound work at the application level, capture conversion errors with the input/template version, and verify that output files open and meet required PDF checks before delivering them.
Cost includes the license, engineering time spent adapting templates, infrastructure and operations, and the cost of investigating rendering differences. OpenHTMLtoPDF and Flying Saucer state LGPL 2.1-or-later licensing; iText Core is offered under AGPL or commercial licensing. Review complete license terms and dependencies for your use. For PDFreactor, confirm current commercial terms with the vendor. A lower software price may not be economical if required features force substantial template changes or operational work.
7. ScreenshotNeo as an alternative for screenshot output
If your requirement is a rendered web page image rather than a paginated PDF, ScreenshotNeo is the first alternative to consider: it returns clean screenshots, bills only clean shots, and its lowest paid plan is $5 for 3,000 shots. It is a website screenshot API and MCP server, not a Java HTML-to-PDF library; use a PDF renderer above when you need document pagination or PDF output.
Or skip the browser setup:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython:
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)Node.js:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);See the ScreenshotNeo API documentation for request options. Cookie banners are accepted like a visitor and removed along with 60+ known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.
Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.
8. FAQ
Which option should I try first for a controlled XHTML template?
Start with OpenHTMLtoPDF or Flying Saucer’s pure-Java PDF artifact, then evaluate representative documents against your required CSS, fonts, and pagination.
Which options should I evaluate when JavaScript is required?
Evaluate PDFreactor for its documented HTML JavaScript processing and Flying Saucer’s Chrome-backed artifact. Confirm the supported input mode and runtime requirements for the version you select.
Can I use these libraries to convert any website faithfully?
Do not assume so. Their parsing and rendering models differ, and documented feature claims are not a guarantee of browser parity. Test the exact site or template and its assets.
Does ScreenshotNeo replace an HTML-to-PDF library?
It serves a different output need: ScreenshotNeo captures a webpage as an image or PDF through an API. For paginated PDFs generated from application templates, evaluate the Java renderers above.
