HTML to PDF Spring Boot: Convert a Thymeleaf Template to a Real PDF

Every Spring Boot PDF tutorial starts the same way, because the first step is genuinely trivial: you already have a template engine, so you render the template to a string outside the usual HTTP response cycle and hand the string to a PDF library. Thymeleaf is completely decoupled from whatever renders the PDF, which is why you can swap the second half without touching the template.

@Service
public class InvoicePdfService {

    private final TemplateEngine templateEngine;

    public String renderHtml(Invoice invoice) {
        Context context = new Context();
        context.setVariable("invoice", invoice);
        return templateEngine.process("invoices/invoice", context);
    }
}

That HTML string is the handoff point, and everything interesting happens after it. The engine you pass it to decides three things you cannot change later without a rewrite: how much CSS survives, whether JavaScript runs at all, and what the license obliges you to do. Most teams pick the library first and discover those constraints three sprints in, when a designer sends a template built with flexbox.

Flying Saucer is the long-standing JVM answer, and it is still actively maintained: version 10 shipped in December 2025, though recent releases require Java 21 or newer. OpenHTMLtoPDF grew out of it and adds SVG support and accessible, tagged PDF output for WCAG and PDF/UA work. The original OpenHTMLtoPDF repository went quiet around 2022, but a community fork under the io.github.openhtmltopdf coordinates picked it up, moved to PDFBox 3 and has kept shipping releases through 2026.

Both are excellent at what they do and cost nothing. The constraint to plan around is CSS. They implement roughly CSS 2.1 with pieces of CSS 3, and they expect well-formed XHTML, so a template that leans on flexbox, CSS grid, or modern color functions will not lay out the way it does in a browser. Neither has a JavaScript engine, so a Chart.js graph or anything drawn client side renders as an empty box. For a table-based invoice with careful, conservative CSS, none of that matters and you get a fast, dependency-light render inside your own JVM.

iText comes up in nearly every Spring Boot PDF thread, usually without the license attached, so it is worth being direct. Since version 5.0.0 iText has been distributed under the AGPL v3, alongside a paid commercial license. AGPL is a strong copyleft license: if you use it in software you distribute or expose over a network, the obligation extends to your own source. That is why iText sells commercial licenses, and it is exactly the case most SaaS products fall into. Note also that iText 8 reaches end of life in October 2026, so a version decision is due for teams already on it.

None of that makes iText a bad tool. Its html2pdf module handles considerably more CSS than Flying Saucer, and for print-heavy documents it is genuinely strong. It just is not free for a commercial closed-source product, and a fair comparison should say so before your legal review does. If the reason you were reaching for iText was CSS fidelity rather than PDF manipulation, a browser gives you more fidelity than any HTML-parsing library and sidesteps the license question completely.

When the template uses modern CSS, or draws part of the page with JavaScript, or simply has to match what users see in Chrome, let a real browser do the layout. Nothing about your Thymeleaf setup changes. You render the template to a string as usual, then POST it, or point the API at a live route in your service and let it load the page, run the scripts and wait for the charts.

String html = invoicePdfService.renderHtml(invoice);

MultiValueMap<String, String> form = new LinkedMultiValueMap<>();
form.add("html", html);
form.add("format", "Letter");
form.add("archive", "true");

RenderResult result = WebClient.create()
        .post()
        .uri("https://api.sitepdf.com/v1/render")
        .header("Authorization", "Bearer " + apiKey)
        .body(BodyInserters.fromFormData(form))
        .retrieve()
        .bodyToMono(RenderResult.class)
        .block();

Because a current browser lays it out, your CSS grid, web fonts, background colors and JavaScript charts all render the way they do on screen, and the text stays real and searchable rather than becoming an image. There is no rendering engine in your JAR, no native library on the host, and no browser process competing with your service for heap. The same call works from a @Scheduled job or a batch step. Our HTML to PDF in Java guide covers the plain-Java library options in more depth, and the PDF generator API page lists every parameter, including margins, page size and the wait signal for charts.

An invoice, a statement or a compliance report leaves your service and nothing verifiable stays behind. Add archive=true to the render call and Sitepdf also stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id later, so you can show what a given document said on a given date. For regulated JVM shops that provenance is often the reason to render server side at all. The website archiving page explains how the record works, and if you are weighing running headless Chromium in your own cluster instead, the Gotenberg alternative page walks that trade off honestly. Renders are transient by default; leave archiving off and we return the PDF and store nothing.