wkhtmltopdf alternative for Java

openhtmltopdf and flying-saucer render a CSS subset; wkhtmltopdf-java shells the dead binary. The first pair lays out offline but never runs JavaScript; the wrapper inherits the frozen engine wholesale.

Install

Add com.microsoft.playwright:playwright to the build, then run Playwright's install step once to download the browsers it drives.

What you keep: wrapper options become Pdf options

The wrapper options survive the trip. Page size becomes setFormat("A4"), orientation becomes setLandscape(true), margins become setMargin(), and setPrintBackground(true) keeps backgrounds.

What actually changes

The JVM wrappers exec'd the binary, and openhtmltopdf took a third road: laying out a well-formed XHTML subset in Java, which is why templates needed normalizing before they could print. Playwright for Java prints the page as the browser shows it, so the XHTML normalization step and the binary-on-PATH both leave the build, and fonts stop being a fontconfig exercise.

Before and after on a typical openhtmltopdf build:

Before, openhtmltopdf laying out a hand-prepared XHTML subset:

try (OutputStream out = new FileOutputStream("out.pdf")) {
    PdfRendererBuilder builder = new PdfRendererBuilder();
    builder.useFastMode();
    builder.withHtmlContent(xhtml, baseUri);
    builder.toStream(out);
    builder.run();
}

After, Playwright for Java printing with Chromium:

try (Playwright playwright = Playwright.create()) {
    Browser browser = playwright.chromium().launch();
    Page page = browser.newPage();
    page.navigate("https://example.com/report",
        new Page.NavigateOptions().setWaitUntil(WaitUntilState.NETWORKIDLE));
    page.pdf(new Page.PdfOptions().setPath(Paths.get("out.pdf"))
        .setFormat("A4").setPrintBackground(true));
}

setWaitUntil(WaitUntilState.NETWORKIDLE) waits for the page to finish before printing, and setPrintBackground(true) keeps background colors and images. The page lays out exactly as a browser shows it, so the XHTML normalization step disappears.

Verify before you cut over

Run your most fragile template through the after snippet above before you retire the old path, and compare page count, fonts, backgrounds, and page breaks against the current output. The smart-shrink compensations account for most of the delta; the rest are genuine engine differences to review.

OpenHTMLtoPDF or browser?

openhtmltopdf stays correct for XHTML-authored print documents: deterministic layout, no browser process, solid paged-media CSS. It never runs JavaScript and only accepts well-formed input, so anything client-rendered must use Chromium.

Method

Checked 2026-09-11 against the openhtmltopdf user guide and the current Playwright for Java PDF documentation.

More languages: the Python migration guide, the PHP migration guide, the C# migration guide, the Go migration guide. The wkhtmltopdf alternatives hub holds the full flag table and the honest before-and-after notes.

Going deeper: the open-source comparison prices the self-hosted routes against hosted ones, the formatting guide covers what each engine class preserves, and the webcapture product page states the hosted route plainly.