itext-java: a PDF library where the license is part of the API

The license question comes before the technical one

The most consequential fact about this library is not in its API. The README carries an AGPL license badge, and the repository root holds both a `LICENSE.md` and a separate `gnu-agpl-v3.0.md` document. The commercial story is visible in the product structure rather than stated plainly in the README: addons are listed with repository and product links, and the keyword list on the repository topics includes `accessibility`, `digital-signature`, `signature-validation`, `encryption`, `fips`, `pdfa`, `pdfua`, and `pades-standard`.

This is the part that catches teams out. A library under the GNU AGPL carries obligations around network use that many commercial codebases have to plan around before adoption, not after. The core library is freely available under AGPL; the addons that convert XML and HTML to PDF, perform OCR, redact sensitive information, add international character support, optimize file size, and flatten XFA documents are separate products.

So the practical split is that document creation, manipulation, signing, forms, PDF/A and PDF/UA work are what the core covers, while anything adjacent to ingestion and redaction sits in a different commercial conversation. The repository description itself frames the library as the next level of SDK for developers who want the benefits PDF can bring, with a better document engine, high and low level programming capabilities, and the ability to create, edit and enhance documents.

It has 2,258 stars, 474 forks and 77 open issues, and the last push was 2026-09-28.

Two Maven dependencies and a document object

Getting started is a pom.xml fragment, which is refreshingly short for a library of this size.

<properties>
  <itext.version>REPLACE_WITH_DESIRED_ITEXT_VERSION</itext.version>
</properties>
<dependencies>
  <dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itext-core</artifactId>
    <version>${itext.version}</version>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>bouncy-castle-adapter</artifactId>
    <version>${itext.version}</version>
  </dependency>
</dependencies>

Two things to notice. The core artifact is declared with type `pom`, which is how this project packages a module whose real dependencies come through it, so you do not assemble them yourself. And the bouncy castle adapter is listed separately as a direct dependency rather than being optional, which tells you cryptography support is part of the expected setup rather than an add on.

The Hello PDF example is the smallest useful demonstration of the object model.

package com.itextpdf.hellopdf;

import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.layout.Document;
import com.itextpdf.layout.element.Paragraph;

import java.io.FileNotFoundException;

public class HelloPdfApp {

    public static void main(String[] args) throws FileNotFoundException {
      try (Document document = new Document(new PdfDocument(new PdfWriter("./hello-pdf.pdf")))) {
            document.add(new Paragraph("Hello PDF!"));
        }
    }
}

The three layer structure is visible in the imports: a `PdfWriter` opens a destination, a `PdfDocument` is the PDF object model, and a `layout.Document` wraps it to give you a high level content API with `Paragraph` and its siblings. The try with resources closing the layout document is what flushes the file, so getting that wrong is how you produce truncated PDFs.

How the modules divide the work

The repository tree is the clearest statement of the architecture, and the directory names map closely onto the packages in the example.

`kernel/` is the PDF object model, which is what `com.itextpdf.kernel.pdf` refers to. `layout/` is the higher level content API that produces `com.itextpdf.layout.Document` and the element classes. `commons/` holds shared utilities. From there the tree branches by capability rather than by layer: `forms/` for AcroForm work, `sign/` for digital signatures, `barcodes/` for barcode generation, `svg/` for SVG support, `io/` for input and output handling, `font-asian/` for Asian font support, `hyph/` for hyphenation, `resources/` for resource bundles.

Then there are the compliance and format modules, and these are worth separating in your head. `pdfa/` and `pdfua/` are distinct directories, reflecting that PDF/A is about archival conformance and PDF/UA is about accessibility, which are genuinely different conformance regimes with different validators. Two separate Bouncy Castle adapters exist, `bouncy-castle-adapter/`, `bouncy-castle-connector/`, and `bouncy-castle-fips-adapter/`, which tells you FIPS-compliant cryptography is a supported configuration rather than a aspiration.

Two modules exist to serve other projects: `itext7core/` appears alongside `itextcore/`, and `brotli-compressor/` and `webp-image-support/` are self contained. The `pdftest/` directory is a test harness rather than shipped code. There is also a `sharpenConfiguration.xml`, which suggests tooling for analyzing runtime behaviour rather than something a consumer would touch.

Core features, and what sits outside them

The README groups the core capabilities into a bulleted list that is worth reading as a scope boundary.

Creation goes through the layout engine. Manipulation covers merging multiple PDFs into one and adding new content. Digital signing and form creation and manipulation are core. Then come the conformance and utility items: working with PDF/A documents, working with PDF/UA documents, FIPS-compliant cryptography, barcode generation, and SVG support.

Everything else is an addon with its own repository or product page. Converting XML, HTML and CSS to PDF is the one most people reach for, and it is not in the core. OCR on images and PDF documents is an addon. Redacting sensitive information is an addon, which is interesting because redaction is a security feature and a common requirement, yet it sits outside what the AGPL core gives you. Support for international character sets such as Arabic, Chinese, Hebrew and Thai is listed as an addon pointing at a product called Calligraph, which is worth noting given how often multilingual output turns out to be a procurement conversation rather than an engineering one.

Optimization for reduced file size, flattening of XFA documents, and PDF debugging are the remaining addons, with debugging pointing at a repository called rups and its own product page.

For trying capabilities without writing code, the README points at a Demo Lab at itextpdf.com with demo applications runnable online. That is a reasonable way to settle which addon you actually need.

Release cadence and the security track record

The release history gives a clear picture of a project on an active patch rhythm with security treated as routine rather than exceptional.

Release 9.7.1, published on 2026-07-22, was a patch addressing a security vulnerability in the Jackson JSON dependency, bumping it to 2.22.1 to fix CVE-2026-54515, with all users on 9.7.0 encouraged to upgrade. That is the right way to ship a dependency advisory in a library this widely embedded.

Release 9.7.0, published on 2026-07-08, was the third iText Core release of 2026 and added the WebP image format, dynamic page margins and footnotes in the layout module, and strengthened decompression bomb protection. The decompression bomb hardening is telling: it protects against a document that expands enormously when parsed, which is a denial of service vector in any service that accepts untrusted PDFs.

The README also documents GraalVM compatibility from version 8.0.3, supporting native image compilation, with details in the build documentation. For a library that people want to ship inside containerised Java services, native image support matters more than it used to.

The build story is documented in a separate `BUILDING.md` rather than in the README, and the repository also has a `Jenkinsfile` for continuous integration, `sonar-project.properties` for static analysis, and a `SECURITY.md` for reporting vulnerabilities. `BUILDING.md`, `CodeConventions.md`, `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md` complete the contributor documentation set. A .NET version exists as well, and the README notes it, though the Java repository is the subject here.

Editorial conclusion

iText Core is a serious PDF engine rather than a wrapper, and the module boundaries in the repository reflect a real division of labour between a kernel, a layout engine, and format compliance layers. What makes it different from the alternatives is not technical: it is that the free tier is AGPL, so the licensing conversation happens before the technical one, and any commercial deployment that is not itself AGPL needs a commercial agreement. Start with the Maven coordinates and the Hello PDF example, both of which are short enough to read in full, and treat the knowledge base installation guidelines as the real reference for anything beyond basic document creation.

Frequently asked questions

Official sources

1. Issues
2. itext/itext-java on GitHub
3. Project website
4. README
5. Releases