iText 5 for Java: a deprecated PDF library with legacy constraints

What iText 5 solves for legacy Java applications

iText 5 is a Java library for creating and manipulating PDF documents. It is relevant to applications that generate PDFs directly, produce PDF/A files, process XML or HTML, use extended PDF functionality or create XML signatures. Its primary audience is now teams maintaining software built against the 5.x line. The README says iText 5 is EOL and recommends iText 9 for new projects.

The product is distributed as several JARs rather than one component with a single stated purpose. `itextpdf-x.y.z.jar` is the core library. `itext-xtra-x.y.z.jar` adds extra functionality, which the README identifies with PDF 2. `itext-pdfa-x.y.z.jar` supplies PDF/A-related functionality. `xmlworker-x.y.z.jar` covers XML and HTML functionality.

That division makes artifact selection part of adoption. A service that only creates ordinary PDFs may have different dependency needs from one that requires PDF/A or XML signatures. The repository reinforces this structure through separate top-level directories named `itext/`, `pdfa/`, `xtra/` and `xmlworker/`, along with a root `pom.xml`. Based on that layout, engineers can review each feature area rather than treating all iText 5 code as one interchangeable module.

The trade-off is direct. iText 5 can serve an established codebase without an immediate platform move, but the README restricts it to security fixes. It lists newer capabilities in iText 9, including HTML to PDF with PDF/UA, PDF redaction, SVG support, broader PDF standards support, data extraction, debugging tools and more modular document workflows. A new Java project has little reason in this repository's own guidance to begin with the older line.

How the itextpdf module layout serves different PDF jobs

The repository's `itext/` directory contains the core project area, while `pdfa/`, `xtra/` and `xmlworker/` correspond to the companion capabilities named in the README. This organization is important because security and upgrade decisions are not necessarily shared by every iText 5 user. For example, the README ties the XML security dependency discussion to use of `com.itextpdf.text.pdf.security.MakeXmlSignature`, rather than presenting that dependency as relevant to every PDF creation task.

The root `pom.xml` identifies the repository as a Maven project. `BUILDING.md` is the documented destination for instructions about building iText 5 from source. The README also points users to the repository's latest releases page for released artifacts. It does not provide a full first-use Java class, Maven coordinate block, Gradle setup or build transcript in the README itself. The repository layout confirms that these implementation details belong elsewhere.

This structure has an operational benefit for legacy teams. Engineers can map an existing use case to a specific module before changing a version. If an application requires PDF/A output, `pdfa/` is directly relevant. XML or HTML processing points to `xmlworker/`, while the README associates `itext-xtra` with PDF 2 functionality. That does not prove which transitive dependencies reach a particular deployment, but it identifies the source areas and artifacts that should be examined.

The architecture also creates migration work. A project should not assume that moving from a core iText 5 dependency to iText 9 is equivalent to replacing one JAR. The README names a broader feature set for iText 9 but does not publish an API or output-compatibility matrix. Existing generation logic may need review even where the functional requirement appears similar.

Installing iText 5 and completing a first compatibility check

The README directs users to the repository's releases page for the latest iText 5 artifacts and to `BUILDING.md` for source-build information. It does not show a complete dependency declaration or executable PDF generation example. A responsible first-use tutorial must stop at those documented entry points rather than invent a package version, flag or API call.

The README identifies the release artifacts using this naming scheme:

itextpdf-x.y.z.jar
itext-xtra-x.y.z.jar
itext-pdfa-x.y.z.jar
xmlworker-x.y.z.jar

Here, `x.y.z` is a version placeholder in the project documentation. It is not a usable release version. Release 5.5.13.6 exists, but the README does not say that this release should be selected for every application. The engineer must choose a published artifact from the releases page and match it to the module required by the application.

Before adding an artifact, record four facts: the application's Java runtime, whether it needs the core library alone, whether it uses PDF/A or XML Worker, and whether it calls `com.itextpdf.text.pdf.security.MakeXmlSignature`. The signature-class question matters because the README describes different dependency choices for users of that class. The repository's `pom.xml` can then be inspected for module and dependency configuration, while `BUILDING.md` remains the documented source for build instructions.

The first post-installation check should be an existing regression case from the application. The README does not identify a sample application or define expected output, so it cannot support a claim that a particular PDF will render correctly. Preserve an existing document before changing dependencies, then compare it through the application's own acceptance process.

Java 5 compatibility constrains xmlsec and Commons IO upgrades

The main compatibility constraint is the Java 5 target. The README states that this prevents the Java 5-compatible modules from updating `org.apache.santuario:xmlsec` to 2.x.x or newer because those releases require Java 8. The same restriction applies to `commons-io:commons-io`: iText 5 cannot upgrade it to 2.7 or newer within the Java 5-compatible modules because that version requires Java 8.

The consequences differ by dependency. Applications that do not use `com.itextpdf.text.pdf.security.MakeXmlSignature` can avoid adding `org.apache.santuario:xmlsec`, according to the README. Applications that do use the class, including for XFA signatures, face two documented choices. They can use `org.apache.santuario:xmlsec` 1.5.8, which the README says works on Java 5 and newer but remains affected by a cited vulnerability. They can instead use `org.apache.santuario:xmlsec` 2.1.7 or newer with Java 8 or newer, but the README warns that this affects the output format.

For Java 8 and higher, the README says applications can mitigate the Commons IO issue by declaring a direct dependency on the latest `commons-io:commons-io` version. It also states that the Commons IO version used in iText remains compatible with the latest releases. This is a dependency-management option for newer runtimes, not a change to the Java 5 target of the Java 5-compatible modules.

This creates a real platform boundary. A service that must remain on Java 5 can be held back from newer dependency releases. A Java 8 service has more options but must investigate XML signature output changes separately. The README provides no rollback procedure or output regression procedure for the cited Santuario issue.

iText 5 security claims and EOL maintenance limits

The README addresses `CVE-2022-24196` and `CVE-2022-24197`, two CVEs often attributed to iText 5. It classifies both as false positives for this project because an incorrect artifact regular expression in some CVE databases causes the attribution. That is the project's own documentation claim. The README does not provide a broader list of resolved iText 5 CVEs or a separate security-support policy.

Dependency findings require a different reading. The Santuario issue is linked to `com.itextpdf.text.pdf.security.MakeXmlSignature`, while the Commons IO concern applies to the Java 5-compatible modules. A dependency scanner may report the presence of an artifact without showing whether the application calls the relevant class or can move to Java 8. The README's discussion therefore favors usage analysis over a simple project-name match.

Maintenance status is narrow. The repository description says only security fixes will be added and directs users to iText 9. The last push was on 2026-07-27. Release 5.5.13.6 was published on 2026-07-23, following 5.5.13.5 on 2026-01-23. These dates establish recent security-oriented repository activity, but they do not make iText 5 a feature-development line.

The upgrade cost should therefore include more than downloading a JAR. Reviewing dependency changes, Java requirements, output compatibility and license implications is unavoidable when the supported path leads toward a replacement product. The README does not document an automated migration or rollback process.

AGPL and commercial deployment constraints in iText 5

The README describes iText as AGPL software. It also says buying a license becomes mandatory when commercial activities distribute iText inside a product or deploy it on a network without disclosing the application's source code under AGPL. Its examples include shipping the library with a closed-source product, offering paid services and serving PDFs through a cloud or web application.

The repository contains `LICENSE.md` and `gnu-agpl-v3.0.0.md`, while GitHub's repository metadata classifies the license as a custom license category. The README's wording makes AGPL the relevant stated model for technical review, but it does not replace the full terms in `LICENSE.md`. This article does not interpret whether a particular product or service complies with those terms.

Licensing can influence migration cost. Moving from iText 5 to iText 9 changes the product line and may require code or dependency review. The README lists capability improvements for iText 9, but it does not provide an API compatibility matrix, migration guide or statement that generated output remains identical. A team with a network deployment should inspect `LICENSE.md` before treating either version as interchangeable.

Conversely, AGPL should not by itself be interpreted as proof that every use requires payment. The README qualifies its statement by mentioning commercial activities, distribution in a product, or network deployment without source disclosure. The exact facts of the intended service determine how the stated terms apply.

Why iText 9 is the documented alternative to iText 5

iText 9 is the alternative named by the project itself. The README recommends it for new projects and says existing projects should consider moving from iText 5. Its listed improvements include HTML to PDF with PDF/UA, support for newer PDF standards such as PDF/A-4 and PDF/UA-2, redaction, SVG, broader language support, IDE debugging, data extraction, modular document workflows, encryption, hashing and digital signatures.

The practical difference is the maintenance direction. iText 5 targets Java 5 and receives only security fixes. iText 9 is presented as the replacement line with continued improvements and bug fixes. For a new Java 8 or newer application, the iText 5 dependency constraints do not offer an obvious advantage. Its continuing relevance comes primarily from compatibility with an existing implementation.

Migration is not documented as a mechanical replacement. The README does not say that iText 5 and iText 9 APIs are source-compatible, that generated PDFs will be byte-for-byte identical, or that every module maps directly to a replacement artifact. It also does not provide a rollback plan. Existing applications should therefore treat the Java runtime, output requirements and module usage as the first adoption checks for iText 9.

This comparison also exposes where iText 5 is the wrong tool. It is a poor fit for a new project that requires the improvements listed for iText 9. It is also a poor fit for a Java 8 or newer deployment that can remove Java 5 constraints. It remains most defensible where compatibility with an established codebase outweighs those concerns.

Editorial conclusion

Adopt iText 5 only when an existing Java application must preserve its current PDF behavior and dependency set. Do not choose it for a new project when iText 9 can meet the requirements. Before retaining or adopting it, inspect LICENSE.md, identify the required module, check the Java runtime and review org.apache.santuario:xmlsec and commons-io:commons-io. The final decision should be based on whether a documented Java 5 or compatibility requirement makes migration riskier than remaining on the EOL line.

Frequently asked questions

Official sources

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