github itext/itext-java 9.6.0
iText Core/Community 9.6.0
on GitHub

4 hours ago

Our second iText Core release of 2026 will please those with a focus on creating accessible and reusable content in PDF. We’ve introduced the ability for iText to perform automatic color contrast checks during creation of PDF/UA documents, which will aid when ensuring generated documents meet many countries' accessibility regulations.

We’ve also added high-level functionality to make creation of Well Tagged PDF documents easier, by letting iText’s comprehensive conformance checking architecture handle all the tricky stuff behind the scenes. You can also target the reuse and accessibility conformance levels defined in the WTPDF specification, depending on your requirements. The accessibility level directly aligns with PDF/UA-2, while reuse is optimized for content extraction, reflow, and machine-driven transformation.

In addition, we’ve extended trusted list validation to include non‑EU countries, along with general improvements to digital signature validation and certificate retrieval.

PDF/UA Color Contrast Checks

For documents to comply with the PDF/UA specifications, you must ensure that foreground and background colors meet the necessary WCAG standards for accessibility. If there is not enough contrast then not only will documents fail in accessibility checkers, text and graphical content will be difficult to read.

Color contrast checking is something that still requires human intervention in most cases, however, iText Core can now warn you if such issues are detected during document creation. It should be noted that this is not a comprehensive check and cannot substitute for an actual “human in the loop”. However, it will help to identify and avoid obvious issues at an early stage.

This functionality is similar to that provided by the WebAIM Contrast Checker, where you can select different values for the foreground and background colors. For WCAG 2.1 level AA which is commonly specified in accessibility regulations, normal text must have a contrast ratio of at least 4.5:1, and 3:1 for large text, graphics, and user interface components (such as form input borders).

We have also improved iText’s layer handling to better accommodate these tests. Previously, reopening a document and accessing layers via PdfPage.getLayers() always returned layers in the “on” state regardless of their persisted visibility. Now, layer properties are correctly persisted after saving and reopening.

Easier WTPDF Creation

The PDF Association’s Well-Tagged PDF (WTPDF) standard specifies requirements for creating PDF 2.0 documents geared towards reuse and accessibility. While both use cases have a large overlap in requirements, some are critical for reuse while others are only required for accessibility. Therefore the standard has conformance levels that clearly identify the requirements for each.

The reuse level is intended for PDF content to be more easily repurposed, extracted, or reflowed, including use cases such as PDF to HTML conversion and enabling responsive layouts on mobile devices. The accessibility level uses the same structural tagging model, but focuses more on ensuring people using assistive technologies can navigate and understand the document.

WTPDF document creation with iText Core was introduced along with the support for PDF/A-4 and PDF/UA-2, which are both based on the PDF 2.0 specification. However, we’ve since added a comprehensive validation architecture with specialized document classes and validation checkers to enforce compliance when targeting specific standards.

To bring WTPDF into line there is now a dedicated WellTaggedPdfConformance subclass of PdfDocument, to join the existing PdfADocument and PdfUADocument classes. In addition, the PdfConformance class now includes the accessibility and reuse conformance levels.

All these changes mean creating WTPDF documents with iText is just as easy as PDF/A and PDF/UA, with no need to worry about remembering which requirements apply to the conformance level you’re targeting. You can now simply use WellTaggedPdfDocument to create a WTPDF document just like you would use PdfUADocument to create PDF/UA, and let iText do the hard work for you.

Non-EU Trusted List Validation

In iText Core 9.3.0 we introduced the List of Trusted Lists (LOTL) system, which lets iText fetch, validate, and cache European lists for eIDAS compliance. To better accommodate other countries which also issue and maintain trusted lists of their own, we’ve extended the feature to include a broad non‑EU processing implementation.

This was achieved by adding a convenient “single file trust list” alternative implementation path, useful for countries where you have a single XML trust list rather than an EU-style LOTL + pointers ecosystem. The existing LOTL services have been refactored to support this, and the existing Ukraine and Moldova trusted lists samples have been updated to use this new implementation.

You can refer to the Java and .NET sample repositories to find the LOTL validation examples updated for this release.

Improved Digital Signature Validation and Certificate Retrieval

For digital signature validation we’ve introduced a single, configurable mechanism to control all online data retrieval (such as CRL, OCSP, issuing certificates, and LOTL), making it easier to enforce network policies and increase reliability in restricted environments.

Certificate chain building and validation have been updated to better handle complex PKI setups. Chain construction now collects all reachable certificates, including multiple CA candidates and cross-signed certificates, without enforcing constraints during the building phase.

Validation then applies RFC 5280–compliant checks over the resulting paths, with a particular focus on correctly enforcing inherited name constraints across the entire certificate chain. This separation of chain discovery and validation improves robustness and correctness when working with real‑world certificate hierarchies.

Pull Requests

For this release we’d like to thank schallb for their contribution to improve LocationTextExtractionStrategy (Java/.NET) by adding support for custom element and newline separators.

As the author describes, they needed a way to better distinguish between spaces and newlines that are part of the extracted text, and the separators inserted by iText when it decides a word boundary or new line between chunks exists. Thanks to this change, the separators inserted in the formatted extracted text can be overridden.

Bug Fixes and Miscellaneous

We also resolved a few customer and internally-reported issues. The MemoryLimitsAwareHandler (Java/.NET) which protects applications from using too much memory when reading or processing PDF content was modified to have different behavior when creating xref tables rather than updating them. The documentation has been updated to reflect these changes.

We fixed an issue where certain Type3 fonts are processed incorrectly, causing multiple glyphs that share the same Unicode mapping to render with incorrect or duplicated content streams. This resulted in missing or wrong glyph appearances when using or extracting the font.

A regression was reported where signing a PDF removed the /DA (default appearance) entry from signature fields, triggering change warnings in Acrobat and affecting re-signing. The fix ensures the DA entry remains untouched during signing to preserve appearance and avoid Acrobat warnings.

An issue was fixed when copying pages from certain PDF/A-converted documents whose outline/action dictionaries were altered (using /Dest instead of /A), leading to a PdfException error reporting an object belonged to a different PDF. Another PDF/A-related fix prevents null pointer exceptions during PDF/A compliance checks by ensuring the content-stream validation parser is given the correct resource dictionary.

Error handling was improved in a few other cases too. For example, iText now throws a clear, specific error when a PDF annotation is missing its required subType property, instead of failing with a generic null pointer exception. A generic null reference exception when merging certain PDFs was replaced by clearer error reporting when input PDFs have syntax issues, making it easier to identify where the problem lies.

Other Stuff

If you use iText for digital signing, you may be interested in the Digital Signatures Hub which contains a ton of useful resources and examples.

Don’t forget that in addition to the resources on our Knowledge Base, on our GitHub you can find a ton of useful up-to-date samples in the following repos:

Java

.NET

NOTE: If you want to create ZUGFeRD/Factur-X-e-invoices with iText Core, we have both Java and .NET code samples available targeting the current ZUGFeRD/Factur-X specification. They demonstrate how to embed the XML invoice data and add the metadata required for conformance. Read this article to learn more about ZUGFeRD/Factur-X, and using these code samples to create EN 16931-compatible e-invoices.

Bear in mind that our master branch contains samples for the current stable release, while the default develop branch is for the bleeding edge commits towards the next release.

New Features

  • DEVSIX-9361 – Easily create WTPDF
  • DEVSIX-9364 – Perform Color Contrast checks for PDF/UA
  • DEVSIX-9626 – Create an implementation for non-EU trusted lists processing

Improvements

  • DEVSIX-9675 – Online data retrieval customization during signature validation
  • DEVSIX-9727 – Certificate chain building must take multiple CA candidates into account
  • DEVSIX-9746 – CertificateChainValidator must check name constraint
  • DEVSIX-9719 – PdfLayers are always on when reopening document and accessing them through pdfPage.getLayers()

Bug Fixes

  • DEVSIX-9678 – Unexpected behavior of MemoryLimitsAwareHandler
  • DEVSIX-9796 – Type3 Font not processed correctly (missing glyphs) when there are multiple glyphs with same unicode mapping
  • DEVSIX-9455 – DA entry is removed from signature field during signing
  • DEVSIX-9817 – Copying converted file using iText causes PdfException: Object belongs to other PDF
  • DEVSIX-4742 – Throw specific error for an annotation missing a subtype.
  • DEVSIX-9231 – Generic NRE is thrown when converting from PDF to PDF/A

Contributors

We’d like to shout out the following contributors for this release:

Check out latest releases or
releases around itext/itext-java 9.6.0

Don't miss a new itext-java release

NewReleases is sending notifications on new releases.

Get notifications