Bump itext7 from 9.4.0 to 9.7.0

[dependabot]

Updated itext7 from 9.4.0 to 9.7.0.

Release notes

Sourced from itext7's releases.

9.7.0

Our third iText Core release of 2026 brings some significant new capabilities. We've added support for the WebP image format, introduced dynamic page margins and footnotes to the layout module, and strengthened decompression bomb protection. We've also improved append mode reliability and updated several security-related dependencies.

WebP Image Format Support

iText now natively supports the WebP image format, developed by Google to provide superior lossless and lossy compression for web images. This new capability allows you to integrate high-quality, highly compressed modern web images directly into your PDF workflows, significantly reducing file sizes without sacrificing visual fidelity.

Our implementation uses SkiaSharp for WebP decoding on .NET and is delivered as a separate, optional module: webp-image-support. When the module is referenced in your .NET project, iText Core automatically detects and processes WebP images without requiring any additional configuration.

Capabilities

• Automatic WebP image type detection via ImageTypeDetector
• Lossy and lossless WebP image decoding
• ICC color profile handling for accurate color reproduction
• Transparency (alpha channel) support
• Base64-encoded WebP images in HTML/SVG sources

Notes/Limitations

• For animated WebP images only the first frame will be rendered.
• The rotation property is not (yet) supported, but browsers currently ignore this anyway.

Dynamic Margins & Footnotes

We have completely overhauled the way iText handles complex document layouts. This not only allows developers to adjust page margins on the fly, but also includes footnote support with automatic numbering, customizable footnote containers, and intelligent layout logic that ensures footnote anchors and text remain perfectly positioned.

To achieve this, we have introduced a powerful new framework for managing complex document layouts. This overhaul allows developers to adjust page margins on the fly using the new SectionBreak element.
Additionally, we’ve launched comprehensive footnote support, enabling automatic numbering, customizable footnote containers, and intelligent layout logic that ensures footnote anchors and text remain perfectly positioned.

Signatures and Validation

We’ve resolved critical issues related to Append Mode, ensuring that incremental updates to PDF documents are more reliable. This includes better tracking of modified objects and fixing stream inconsistencies, allowing for a more robust document history and preservation of digital signatures.

Page rotation handling for signature layers is also improved, and we fixed some edge-case crashes during form flattening.

To ensure uninterrupted support for digital signature validation, we have released a new version of our EU Trusted Lists resources. This update incorporates the recently updated European Journal sources, maintaining compliance with the latest eIDAS standards.

Security and Stability

iText’s protection against "decompression bombs" inside PDF streams has been enhanced, particularly for single /FlateDecode streams and image-based decompression bombs. The change applies a 100× growth factor limit to all streams by default. Note that the existing API to override protection remains in place, in cases where edge cases may trigger false positives. However, this should be extremely unlikely for real-world uses cases.

Additionally, we have implemented a high-level safety mechanism to detect and terminate infinite layout loops.

Pull Requests

For this release we've incorporated two pull requests. The first is from iText alumni Dmitry Radchuk to add support for the :is() and :where() selectors for the styled-xml-parser module utilized by the pdfHTML add-on. Therefore, full details can be found in the pdfHTML 6.3.3 release notes.

The other pull request comes from Netliomax25 who proposed a way to increase security in iText’s PDF/UA accessibility checks, specifically for rich text inside annotations. The fix swaps in a hardened XML parser to block potential XML External Entity injection attacks.

Bug Fixes and Miscellaneous

... (truncated)

9.6.0

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 WellTaggedPdfDocument 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.

... (truncated)

9.5.0

In this first iText Core release of 2026 we’re focusing on upcoming additions to the PDF specification; specifically adding support for Brotli-compressed PDF streams, and post-quantum-safe algorithms for digital signing.

The validation of PAdES signature profiles has been improved to detect Document Security Store changes between revisions.

In addition, there are various improvements and fixes across the core modules. See below for more details.

Support for Brotli Compressed PDF Streams

The Flate/Deflate compression method was first introduced in version 1.2 of the PDF specification back in 1996. Based on zlib, it has served well though is rather long in the tooth these days. With that in mind, the PDF Association plans to add support for the modern Brotli compression standard to the PDF specification in the near future. As befits our position in the industry, we're introducing Brotli support to iText now rather than later.

In this release we’ve added proof‑of‑concept support for reading and writing PDFs that use Brotli compression, including a new filter handler and corresponding high‑level API hooks.

For now at least, you should consider this feature experimental, since current support for Brotli-compressed PDFs in other software is scarce. Even after it becomes part of the official specification it will take some time for the majority of PDF viewers and browsers to support such documents. As always with new standards and technology, however, it's important for iText along with other major PDF vendors to adopt and popularize them as soon as possible.

For those brave souls who wish to proceed, the new brotli-compressor module is only available from our artifactory, for now. See the README for more details on its usage and configuration.

Post-Quantum-Safe Digital Signature Algorithm Support

Once again, this is one for the future; albeit a rather more uncertain one. Quantum computers are beginning to step outside of the purely theoretical world, and with them comes the dangers of Q-Day. That is, the day when a quantum computer could conceivably instantly render existing means of encryption obsolete.

Fortunately, some extremely clever boffins have been aware of the dangers for some time, and a variety of encryption algorithms has been developed to counter quantum-based attacks. Thanks to the venerable Bouncy Castle cryptographic modules used by iText, we have implemented POC support for the Post-Quantum algorithms supported by Bouncy Castle.

Again, official support in the PDF specification will be coming soon and so it's time for us to implement support in iText. However, it should be noted that these are not yet supported in FIPS mode, as the official PQC-safe algorithms for FIPS are still to be defined. Once PQC-safe FIPS mode is possible, you can be sure iText will be at the forefront of PDF implementations.

PAdES Signature Profiles

We've made further headway into making digital signatures easier with preset PAdES signature profiles. The PAdES profile validation is improved and can detect when the Document Security Store (DSS) changes between revisions. It will emit a TimestampsAfterDSSEvent when appropriate, improving timestamp validation accuracy.

Also in this release you'll find new samples for the Ukraine and Moldova trusted lists which are available from the European Commission's eIDAS Dashboard site.

Pull Requests

For this release we want to thank dajoropo for their contribution to improve error handling when an attempt to create a PDF from a TIFF image fails. Now, iText Core will include the original exception to assist in diagnosing why the error occurred.

Bug Fixes and Miscellaneous

We have introduced a common, cross‑platform JSON AST and converters to serialize/deserialize between Java/C# objects and a unified JSON representation, improving maintainability and GraalVM/AOT support.

Support for East Asian (Japanese) line‑breaking rules in the layout module was added to avoid orphan punctuation at the beginning of lines, improving typography for Japanese text.

We also investigated and resolved an issue with form filling and flattening introduced after version 9.0.0, after a customer reported a regression in performance.

A bug in calculating the maximum number of XRef elements was fixed, avoiding potential overflow issues in large documents.

We fixed an issue preventing OCG layers from being added, modified, or removed in append mode was fixed, including when no prior OCG layers existed.

We also fixed the handling of unencrypted metadata in encrypted documents by aligning decryption logic with encryption dictionary flags (AES‑256 vs AES‑GCM behavior), and clarified how metadata is treated on creation.

A bug when validating a PDF signature was resolved, where iText did not use OCSP/CRL responses that were added to the document’s DSS in a non-timestamped revision.

... (truncated)

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)