iText pdfHTML in Practice: Invoice Totals, CSS and Signing

An invoice template with three line items and a script that adds them up came out of iText pdfHTML with a total of 0.00. That 4 November 2026 run on Java 17 opens this look at pdfHTML 6.3.4 and iText Core 9.8.0, on Maven Central since 30 September 2026. CSS rules that never reach the page, a signing setup that stops on a missing module, advisories on older releases and lines that only receive security patches follow, with every output taken from that day's runs.

We work at Iron Software, and the end of this article covers our library, IronPDF.

Scripts Never Execute During Conversion

According to iText's knowledge base, JavaScript is not evaluated by pdfHTML, and the HTML feature FAQ lists the <script> tag as unsupported. The invoice below leaves its total row at 0.00 and expects a script to fill it in.

import com.itextpdf.html2pdf.HtmlConverter;

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;

public class ScriptedInvoice {
    public static void main(String[] args) throws IOException {
        // The table has three line items, and the script is meant to add them up into the total row.
        String html = "<html><body><h1>Invoice INV-2026-0418</h1><table id='items'>"
                + "<tr><td>Paper</td><td class='amt'>120.50</td></tr>"
                + "<tr><td>Toner</td><td class='amt'>89.99</td></tr>"
                + "<tr><td>Binders</td><td class='amt'>42.00</td></tr>"
                + "<tr><td>Total</td><td id='total'>0.00</td></tr></table>"
                + "<script>var sum = 0;"
                + "document.querySelectorAll('.amt').forEach(function (c) { sum += parseFloat(c.textContent); });"
                + "document.getElementById('total').textContent = sum.toFixed(2);</script>"
                + "</body></html>";

        try (OutputStream out = new FileOutputStream("scripted-invoice.pdf")) {
            HtmlConverter.convertToPdf(html, out);
        }
    }
}

scripted-invoice.pdf is a single page of 1,345 bytes, and its total row reads 0.00, where the script would have written 252.49. A canvas chart drawn by a script fares the same way, and in a second run the canvas area held no drawing at all, not even its border. Templates that compute totals, format dates or draw charts with JavaScript are the ones affected. iText's documented workaround is to load the page in headless Chrome through Selenium WebDriver and a chromedriver binary, then hand the evaluated HTML to pdfHTML.

CSS That Chrome Draws and pdfHTML Skips

The FAQ, written against pdfHTML 6.3.3, has a long list of CSS marked unsupported. It includes box-shadow, text-shadow, filter, mix-blend-mode, writing-mode, z-index, text-decoration-style, and pseudo-elements such as ::marker, ::first-line and ::first-letter. Flexbox and grid are marked supported. The snippet below uses three of the unsupported rules.

import com.itextpdf.html2pdf.HtmlConverter;

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;

public class DecoratedInvoice {
    public static void main(String[] args) throws IOException {
        // A drop cap, a wavy underline and vertical text, three rules the pdfHTML FAQ marks as unsupported.
        String html = "<html><head><style>"
                + "p.note::first-letter { font-size: 32pt; color: #c0392b; }"
                + "h1 { text-decoration: underline; text-decoration-style: wavy; }"
                + ".stamp { writing-mode: vertical-rl; background: #f1c40f; padding: 6px; }"
                + "</style></head><body>"
                + "<h1>Invoice INV-2026-0418</h1>"
                + "<p class='note'>Payment is due within 30 days.</p>"
                + "<div class='stamp'>PAID</div>"
                + "</body></html>";

        try (OutputStream out = new FileOutputStream("decorated-invoice.pdf")) {
            HtmlConverter.convertToPdf(html, out);
        }
    }
}

In decorated-invoice.pdf (1,364 bytes) the note's first letter is the same 12-point black as the rest of the line, the heading's underline is a straight line, and PAID runs horizontally across a full-width yellow band. Release 6.3.4, which postdates the FAQ, brought initial vertical-rl and vertical-lr handling that applies only with text-orientation set to upright, and once that property was added, a further run stacked the four letters of PAID one above the other. A related run with text-shadow, box-shadow and filter: grayscale(100%) gave the same result, with no shadow under the text or the card and the card still in its original blue. Teams that reuse stylesheets from a web front end lose these effects with no exception, and the FAQ lists no substitutes.

Signing Stops Without a Bouncy Castle Adapter

html2pdf 6.3.4 brings in kernel, layout, forms, svg, pdfa and pdfua, but not sign, so signing starts with a second dependency. The class below signs the invoice with a PAdES Baseline B signature from a self-signed PKCS#12 key.

import com.itextpdf.kernel.pdf.PdfReader;
import com.itextpdf.signatures.PdfPadesSigner;
import com.itextpdf.signatures.SignerProperties;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.Certificate;

public class SignInvoice {
    public static void main(String[] args) throws Exception {
        char[] password = "changeit".toCharArray();
        KeyStore keyStore = KeyStore.getInstance("PKCS12");
        try (InputStream in = new FileInputStream("keys/signer.p12")) {
            keyStore.load(in, password);
        }
        PrivateKey key = (PrivateKey) keyStore.getKey("signer", password);
        Certificate[] chain = keyStore.getCertificateChain("signer");

        // PAdES Baseline B, the level that needs no timestamp authority.
        try (OutputStream out = new FileOutputStream("invoice-signed.pdf")) {
            new PdfPadesSigner(new PdfReader("invoice.pdf"), out)
                    .signWithBaselineBProfile(new SignerProperties().setFieldName("Approval"), chain, key);
        }
    }
}

With html2pdf and sign alone on the classpath, the class compiled and then threw an UnsupportedOperationException from signWithBaselineBProfile, whose message asks for one of the two Bouncy Castle adapter artifacts before any cryptographic call can run. The failed run also left an empty invoice-signed.pdf of 0 bytes. iText's installation guide confirms that one of the two adapters is required and that both together are not supported. With bouncy-castle-adapter 9.8.0 added, the run wrote a 48,052-byte file carrying one ETSI.CAdES.detached signature. Every iText 8.x or 9.x project that signs PDFs in Java needs sign plus an adapter, and the block below adds the standard one.

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>sign</artifactId>
    <version>9.8.0</version>
</dependency>
<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>bouncy-castle-adapter</artifactId>
    <version>9.8.0</version>
</dependency>

Advisories on iText and the Bouncy Castle It Pins

NVD has eight entries that name iText, the newest published on 26 November 2023, and all of them concern older releases. OSV returns none for html2pdf 6.3.4, kernel 9.8.0 or sign 9.8.0, though its iText records sit on itext7-core, itextpdf, itext-rups and the older com.lowagie:itext, so a query on kernel returns none for 7.1.17 either.

• CVE-2021-43113, CVSS 3.1 score 9.8 (NIST): Command injection through a CompareTool file name passed to Ghostscript, fixed in 7.1.17 and 5.5.13.3 according to GitHub's advisory.
• CVE-2017-9096, CVSS 3.0 score 8.8 (NIST): XML external entities in iText's XML parsers, fixed in 5.5.12 and 7.0.3.
• CVE-2017-20151, CVSS 3.1 score 9.8 (NIST): An XML external entity in iText RUPS, the PDF inspection tool, which VulDB scores at 5.5.
• CVE-2022-24196 and CVE-2022-24197, CVSS 3.1 score 6.5 each (NIST): Denial of service from crafted PDFs in 7.1.17, addressed in 7.1.18 and 7.2.2 according to iText's CVE page.
• CVE-2023-6299, CVSS 3.1 score 6.5 (NIST): NVD describes a memory leak in 8.0.1 fixed in 8.0.2, and VulDB scores it at 4.3, but iText's CVE page says that report is wrong and that 7.2.4 and 7.1.16 were the versions affected.
• CVE-2022-24198 and CVE-2023-6298, CVSS 3.1 score 6.5 each (NIST): Filed against 7.1.17 and 8.0.2, and NVD marks both as disputed.

The Bouncy Castle jars carry more, reaching 7.x builds from 7.1.10 on through kernel and 8.x and 9.x builds through the signing adapter. Each iText release pins a Bouncy Castle version, 1.75 for 7.2.6, 1.78 for 8.0.5, 1.83 for 9.6.0 and 1.84 for 9.7.0 and 9.7.1. CVE-2026-5588, a weak-algorithm issue in bcpkix that the 9.7.0 notes cite for the move to 1.84, covers most Bouncy Castle releases between 1.67 and 1.84, and NVD has not scored it yet. CVE.org holds 28 records on the bcprov and bcpkix 1.84 pair that 9.7.x pins. OSV shows two of them, CVE-2026-8763 (a name-constraints bypass, 9.1 from NIST) and CVE-2026-13506 (lazy ASN.1 parsing that resets a depth guard, 7.5 from NIST), which reach every Bouncy Castle release before 1.85. The 9.8.0 release moves to Bouncy Castle 1.86, which neither OSV nor CVE.org lists a record against, so upgrading is iText's remedy. That tree still carries jackson-databind 2.22.3 through commons, inside CVE-2026-110879 (9.8 from HeroDevs, cleared by 2.22.4), a record the OSV package query misses.

End of Life for iText 7.1, 7.2 and 8.0

Published on 8 July 2026, the iText Core 9.7.0 notes record 7.1 reaching end of life in April 2025, with 7.2 following that October and 8.0 in October 2026. Once a line reaches that point it moves into maintenance and gets security patches and nothing else. Maven Central's last 7.x build is 7.2.6, released 9 January 2024, and its last 8.x build is 8.0.5, released 18 July 2024, while iText 5's 5.5.13.6 arrived on 22 July 2026 as a security release that took the 9.7.0 fix for single-layered decompression bombs. Features such as WebP images and footnotes, added in 9.7.0 alongside a default 100 times growth limit on streams, only ship in 9.x. iText releases Core and pdfHTML under the AGPLv3 and also offers a commercial license. Codebases still on 7.x or 8.x have a migration to plan, and the table below sets the four lines side by side.

iText release lines with the newest build of each on Maven Central, its status in iText's notes and the Bouncy Castle version its POM pins.

Line	Newest on Maven Central	Status in iText's notes	Bouncy Castle pinned
5.x	itextpdf 5.5.13.6, 22 Jul 2026	Maintenance, security releases only	1.84, optional
7.x	kernel 7.2.6, 9 Jan 2024	End of life, 7.2 since October 2025	1.75
8.x	kernel 8.0.5, 18 Jul 2024	End of life from October 2026	1.78
9.x	kernel 9.8.0, 30 Sep 2026	Current line	1.86

For invoice templates that rely on scripts or on CSS that Chrome draws, IronPDF for Java is a commercial option that renders HTML on a Chromium engine. We ran an invoice with a script-computed total on 2026.11.3 and it printed Total due 662.24, and a separate statement drew a canvas bar and printed its script's balance. The decorated invoice above came out with its 32-point red first letter, a wavy underline and a vertical PAID, and a related page kept its text and box shadows and turned its blue card grey. A WaitFor render delay on ChromePdfRenderOptions sets how long a page's scripts get before the capture.

It comes from Maven Central as com.ironsoftware:ironpdf, with engine binaries that the docs say download on the first run or arrive through a platform artifact, and Central lists eleven releases published in 2026, up to 2026.11.3 on 3 November. Signing with a .pfx or .p12 certificate goes through getSignature().SignPdfWithSignature on the same PdfDocument, and IronPDF's signing example lists no separate signing module. Our run with the same self-signed key returned true from VerifyPdfSignatures with none added, on a detached PKCS#7 signature (adbe.pkcs7.detached). A free trial runs for 30 days.

What the pdfHTML Runs Showed

pdfHTML 6.3.4 skips page scripts and a long list of CSS effects, signing needs sign plus a Bouncy Castle adapter, the Bouncy Castle records on iText's pinned versions clear only at 9.8.0, and Jackson 2.22.3 in that tree still wants 2.22.4. For HTML that depends on a browser, IronPDF for Java renders it in Chromium instead, with script and CSS media settings on ChromePdfRenderOptions.

iText and pdfHTML are trademarks of their respective owners, we have no affiliation with iText or Apryse, and the details above come from NVD, CVE.org, the GitHub Advisory Database through OSV, iText's knowledge base and release notes, and the Maven Central record.

Drafted with AI. Code run and claims checked by the Iron Software DevRel team against iText Core 9.8.0, pdfHTML 6.3.4 and com.ironsoftware:ironpdf 2026.11.3 on 4 November 2026.