OpenPDF Migration Check: iText AGPL Gate

Finds every iText (AGPLv3) dependency in pom.xml and build.gradle with file and line, and gives the exact OpenPDF 3.0.5 or Apache PDFBox 3.0.8 line that replaces it. Runs entirely in your browser — nothing is uploaded.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.billing</groupId>
  <artifactId>invoice-service</artifactId>
  <version>2.4.1</version>

<dependencies>
    <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>kernel</artifactId>
      <version>${itext.version}</version>
    </dependency>
    <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>layout</artifactId>
      <version>${itext.version}</version>
    </dependency>
    <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>forms</artifactId>
      <version>${itext.version}</version>
    </dependency>
    <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>html2pdf</artifactId>
      <version>6.2.0</version>
    </dependency>
    
    <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>itextpdf</artifactId>
      <version>5.5.13</version>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      <version>3.5.6</version>
    </dependency>
  </dependencies>
</project>

as of

Free here: Maps every iText (AGPLv3) dependency in the open pom.xml or build.gradle to its line and the exact OpenPDF 3.0.5 or PDFBox 3.0.8 line that replaces it.. In the editor: Whole-workspace migration plan: every module and every iText artifact mapped to its replacement in a dated report, plus a CI gate that fails a build adding new com.itextpdf use. — that part asks for a licence key.

Same engine as the VS Code extension, byte for byte.

Updated 2026-09-30 · ReadyStack

Worked example

Real numbers from this tool, line by line.

Migrate from iText to OpenPDF: 6 findings in one pom.xml

6 findings in one pom.xml: that is what a Java invoice service on iText 9.2.0, with one legacy iText 5.5.13 module, shows when every iText line is mapped to OpenPDF or Apache PDFBox. If you are a Java team shipping closed-source software or a SaaS backend that renders PDFs, this is the list you need before the next release.

What iText says

iText's licensing page is short and plain: "iText 5 and all subsequent versions of iText are dual-licensed, and available under open source (AGPLv3) or commercial license agreements." Under the AGPLv3 option: "You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license." So a closed product or a web service on iText 7, 8 or 9 either publishes its source or holds a commercial licence. iText publishes no price on that page.

The two open replacements

Both are on Maven Central (checked 2026-09-30):

OpenPDF com.github.librepdf:openpdf:3.0.5, LGPL 2.1 / MPL 2.0, plus openpdf-html:3.0.5 for HTML to PDF
Apache PDFBox org.apache.pdfbox:pdfbox:3.0.8, Apache 2.0, plus preflight:3.0.8 for PDF/A checks

OpenPDF is the natural home for code that builds documents (Document, Paragraph, PdfPTable). PDFBox is the home for code that opens existing PDFs, fills AcroForms or signs.

One trap: OpenPDF 3 moved its classes from com.lowagie.text to org.openpdf.text. Many snippets online, and many chatbot answers, still import com.lowagie, which does not compile against 3.0.5.

The sample pom.xml, line by line

<itext.version>9.2.0</itext.version>
<artifactId>kernel</artifactId>    <!-- ${itext.version} -->
<artifactId>layout</artifactId>
<artifactId>forms</artifactId>
<artifactId>html2pdf</artifactId>  <!-- 6.2.0 -->
<artifactId>itextpdf</artifactId>  <!-- 5.5.13 -->

The check resolves ${itext.version} and reports:

itext.version 9.2.0: delete it once the last iText line is gone
kernel 9.2.0 → openpdf 3.0.5 to write, pdfbox 3.0.8 to read or edit
layout 9.2.0 → openpdf 3.0.5
forms 9.2.0 → pdfbox 3.0.8 (PDAcroForm)
html2pdf 6.2.0 → openpdf-html 3.0.5
itextpdf 5.5.13 → openpdf 3.0.5, imports com.itextpdf.text become org.openpdf.text

Each finding carries the ready-made <dependency> block, or implementation(...) for Gradle Kotlin DSL.

Gradle projects

The same 15 rules read build.gradle and build.gradle.kts: string coordinates, group:/name: maps, and version variables such as itextVersion. A Kotlin DSL file with the itext-core 9.8.0 bundle, sign and the Bouncy Castle adapter gives 3 findings: split the bundle by job, move signing to PDFBox, drop the adapter.

What it will not do

It is a dependency map, not legal advice. It reads the file in front of it, not the resolved tree, so run mvn dependency:tree to catch iText pulled in by another library.

Try it

Open your pom.xml in VS Code with the extension, or paste it into the web page. The whole map is free. A licence key adds the whole workspace as one dated migration plan and a CI gate that fails a build adding new com.itextpdf use.

15 seconds — what it actually does

Questions people ask

What does OpenPDF Migration Check do?

It reads a pom.xml, build.gradle or build.gradle.kts and lists every iText (com.itextpdf) dependency with its line number and the exact OpenPDF 3.0.5 or Apache PDFBox 3.0.8 line that replaces it. It has 15 rules. On the bundled sample pom.xml it reports 6 findings: kernel, layout, forms, html2pdf, itextpdf 5.5.13 and the itext.version property.

Who is the iText to OpenPDF check for?

Java teams that ship closed-source software or run a SaaS backend and generate PDFs with iText 5, 7, 8 or 9. iText states that iText 5 and all later versions are dual-licensed AGPLv3 or commercial, so those teams either publish their application source or move to OpenPDF or Apache PDFBox.

Why not just ask a chatbot or grep for itext?

A grep finds the word itext but does not say which library replaces each module: forms and sign go to PDFBox, layout goes to OpenPDF, html2pdf goes to openpdf-html. Chatbot snippets often import com.lowagie.text, which OpenPDF 3 renamed to org.openpdf.text. The check gives the replacement line per module, with current versions from Maven Central.

What is free and what needs a licence key?

Free, without a key: the open file, all findings from the 15 rules, and every replacement line. A licence key adds the whole workspace at once as one dated migration plan, every module and iText artifact mapped to its replacement, and a CI gate that fails a build adding new com.itextpdf use. One payment, not a subscription.

What does the alternative cost?

Staying on iText in closed-source or SaaS code means a commercial iText licence; iText publishes no price on its AGPLv3 page. Switching to another commercial Java PDF library costs money too: Aspose.PDF for Java lists its Developer Small Business licence at US$1,199 per developer. OpenPDF and Apache PDFBox are open source.

Ask about this tool

One question, answered by the person who built it. Your email only if you want the answer sent.

OpenPDF Migration Check: iText AGPL Gate

Get the full version $29

Find a tool

Worked example

What iText says

The two open replacements

The sample pom.xml, line by line

Gradle projects

What it will not do

Try it

15 seconds — what it actually does

Questions people ask

Ask about this tool

OpenPDF Migration Check: iText AGPL Gate

Get the full version $29

Find a tool

Worked example

What iText says

The two open replacements

The sample pom.xml, line by line

Gradle projects

What it will not do

Try it

15 seconds — what it actually does

Questions people ask

Ask about this tool

Same job, next tool