OpenPDF

Create new PDFs and manipulate existing documents through a Java API

The official README lists PDF creation, manipulation of existing documents, text and fonts, images and graphics, tables, encryption, page layout, and text extraction among the core capabilities. That makes OpenPDF useful for both document generation and server-side processing of PDFs already supplied by users or upstream systems.

Sources: [2]

Keep HTML-to-PDF, rendering, and Kotlin support in separate modules

openpdf-html converts HTML/CSS to PDF from a Flying Saucer-derived implementation, openpdf-renderer renders PDF pages to images or Java UI surfaces, and openpdf-kotlin provides Kotlin-oriented PDF creation. The parent POM separates core, HTML, renderer, Kotlin, fonts, and tooling into Maven modules so applications can adopt only the pieces they need.

Sources: [2][3]

Track modern PDF features including PDF 2.0, Brotli streams, and signature-related integrations

The README advertises PDF 2.0 support and transparent reading and writing of Brotli-compressed PDF streams. The 3.0.5 release also includes Brotli support, encryption and signature modernization, and renderer integration work. Bouncy Castle is listed as a recommended dependency for PDF signing, giving the project scope beyond simple document layout.

Sources: [2][5]

A fit for JVM systems needing reports, invoices, HTML templates, previews, or PDF post-processing

OpenPDF fits Java and Kotlin backends that need to generate PDFs directly, services that turn HTML templates into reports or invoices, and applications that merge, edit, encrypt, inspect, or preview existing PDFs. Teams maintaining older iText 2/4-era code can also evaluate the documented migration path rather than replacing the entire PDF layer.

OpenPDF 3.0 means Java 21+ and a package move to `org.openpdf`, so legacy upgrades are not only a version change

The README maps OpenPDF 2.1.x and later to Java 21+, 2.0.x to Java 17+, 1.4.x to Java 11+, and 1.3.x to Java 8+. OpenPDF 3.0 also changes the Java package name from com.lowagie to org.openpdf. Long-lived JVM applications should plan for JDK upgrades, import changes, module differences, and regression testing of code inherited from iText-compatible APIs.

The latest stable release is 3.0.5 from May 22, 2026, while the current parent POM on master identifies 3.0.6-SNAPSHOT. Production builds should pin a formal Maven Central or release version instead of treating the repository snapshot as a stable dependency.

Sources: [2][3][5]

Treat PDF and HTML input as untrusted application input; OpenPDF does not provide a sandbox

The Security Policy explicitly says OpenPDF is not a sandboxed or hardened environment. File paths, image sources, font names, and HTML are processed without application-level validation, so attacker-controlled input can create risks including local-file access, path traversal, SSRF, unsafe base64 data, and memory exhaustion from large or malformed PDFs.

Services that render HTML or external images should apply HTML sanitization, URL and path allowlists, font restrictions, upload-size limits, and isolated execution where appropriate. Licensing also differs by module: the core uses the MPL-2.0 OR LGPL-2.1+ dual-license model, while the README states that openpdf-html and openpdf-renderer are LGPL-2.1 only.

Sources: [4][2][3]