# OpenPDF: a Java PDF library forked from iText 4, dual licensed under LGPL and MPL > OpenPDF is the LGPL/MPL successor to iText 4, kept alive as a Java toolkit for creating, editing, rendering and encrypting PDFs. It suits teams that want an iText-era API without the AGPL terms, and it puts input validation squarely on the caller. **LibrePDF/OpenPDF** — OpenPDF is an open-source Java library for creating, editing, rendering, and encrypting PDF documents, as well as generating PDFs from HTML. It is licensed under the LGPL and MPL. - Repository: https://github.com/LibrePDF/OpenPDF - Website: https://github.com/LibrePDF/OpenPDF - Stars: 4,373 · Forks: 715 - Language: Java - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/librepdf-openpdf ## The iText 4 fork that stayed LGPL OpenPDF exists because of a license change. The README states that iText moved to the AGPL beginning with version 5.0, and that OpenPDF is a fork of iText version 4, specifically the iText svn tag 4.2.0, which carried LGPL and MPL headers. The fork was made in October 2016, according to the README's background section. So the project's real audience is Java teams with code written against the iText 4.x API who cannot or will not accept AGPL obligations, and teams starting fresh who want a permissively-ish licensed PDF toolkit rather than a commercial one. The scope is broader than PDF generation. The README lists creating documents from scratch, manipulating existing ones by adding or removing pages and modifying text, extracting text, adding images and graphics, building tables, encrypting documents, setting page size and orientation, and generating PDFs from HTML through openpdf-html, a fork of Flying Saucer forked in June 2025. Rendering pages to images is handled by openpdf-renderer, a fork of PDFRenderer that the README traces to Sun Labs in 2007. There is also a Kotlin module, openpdf-kotlin, for building PDFs from Kotlin. That is a lot of surface for one project, and it is assembled from three separate codebases with different origins. The repository layout reflects this: openpdf-core, openpdf-html, openpdf-renderer, openpdf-kotlin, openpdf-fonts-extra, pdf-swing and pdf-toolbox are all top-level directories. If you only need to write a PDF, you are pulling in a repository whose maintenance burden is spread across all of them. ## How OpenPDF is structured: core, html, renderer, kotlin The README points to separate Maven artifacts per capability. The core library is com.github.librepdf:openpdf. HTML to PDF is com.github.librepdf:openpdf-html. Rendering pages to images or into Swing and JavaFX applications is com.github.librepdf:openpdf-renderer. The Kotlin module lives under openpdf-kotlin in the repository. The licensing does not follow the same split. The README says OpenPDF uses dual licensing and that you may choose either MPL 2.0 or LGPL 2.1, with the SPDX identifier MPL-2.0 OR LGPL-2.1+. But it then states that openpdf-html and openpdf-renderer are licensed with GNU Lesser General Public License 2.1 only. That is a real constraint, not a footnote: if you build a commercial product around HTML-to-PDF, the module you depend on is LGPL-only, while the core is dual licensed. The README also says the project wants source code consistently licensed under LGPL and MPL only, and that new contributions must carry a dual LGPL and MPL license. On the format side, the README claims PDF 2.0 support (ISO 32000-2) and Brotli stream compression via /BrotliDecode for creating and reading PDF streams compressed with Brotli. Those are the two most concrete format-level capabilities listed, and they are the ones worth checking against your own corpus of input files before you commit. ## Installing OpenPDF from Maven Central and writing a first document The README gives one installation path: a Maven dependency. Add the following to pom.xml, using the groupId, artifactId and version exactly as the README shows them. The version 3.0.5 corresponds to the OpenPDF 3.0.5 release. ```xml com.github.librepdf openpdf 3.0.5 ``` After a build, the dependency should resolve from Maven Central under the com.github.librepdf group. The repository also ships a Maven wrapper (mvnw and mvnw.cmd) and a .mvn directory, so building the project itself does not require a preinstalled Maven. For a first real use, the README does not include a code sample. It points instead to the examples directory at pdf-toolbox/src/test/java/org/openpdf/examples, to the JavaDoc on javadoc.io, and to a wiki tutorial that the README itself labels as work in progress. That is where to go for working code: the examples directory is part of the repository, so the snippets there match the version you are building against, unlike blog posts written for iText 4. If you are migrating existing iText code, the README links a wiki page titled Migrating from iText 2 and 4. Read it before renaming imports, because the fork point is a specific svn tag rather than a moving target. ## The security model puts validation on your side of the boundary The README carries an explicit Security Notice, and it is unusually direct for a library of this kind. It states that it is the responsibility of the application developer to ensure that all input passed into OpenPDF is trusted, sanitized, and safe, and that OpenPDF does not perform input validation or enforce sandboxing. It then points to Security.md for guidelines and common risks. Read that as a design boundary. If your service accepts PDFs from end users and feeds them into OpenPDF for manipulation, text extraction or rendering, the library will not be the component that rejects a malformed or hostile file. You need that check upstream, before the bytes reach OpenPDF. This matters most for openpdf-renderer and openpdf-html, where untrusted input is parsed and laid out rather than simply copied. The honest reading is that this is a normal posture for a low-level document library, and it is also a limitation. Projects that bundle parsing, rendering and HTML layout into one artifact often invite users to assume a safety net that does not exist. OpenPDF at least says so in the README. Whether Security.md is detailed enough to build a threat model from is something you have to judge yourself; the README only links to it. ## Where OpenPDF is the wrong tool OpenPDF is a Java library, not an application. The repository has no CLI entry point, no server, and no end-user interface, so anyone searching for an OpenPDF app or an OpenPDF exe is looking for something this project does not ship. The README describes a library and its modules, nothing more. The HTML-to-PDF path is the weakest link for a new project. openpdf-html is a fork of Flying Saucer made in June 2025, which means the fork is young even though the upstream project dates to 2004. If your HTML relies on modern CSS layout, this is not a browser engine and the README makes no claim that it is. For teams whose main requirement is faithful HTML rendering, a library that treats HTML as a secondary module is the wrong starting point. There is also a maintenance question you have to answer for yourself. The last push to the repository was on 2026-09-18, and the most recent release listed is 3.0.5 from 2026-05-22. That is a real cadence, but the README's own tutorial is marked work in progress, and the documentation section leans on JavaDoc and an examples directory rather than a written guide. If your team needs prose documentation before adopting a dependency, budget time for reading source. ## OpenPDF versus iText and other Java PDF options The comparison that matters is the one the project defines for itself. OpenPDF is a fork of iText 4.2.0, and iText moved to AGPL at version 5.0. The practical difference is not the API, which started out compatible, but the license: OpenPDF offers MPL 2.0 or LGPL 2.1 for the core, while later iText versions carry AGPL terms that push commercial users toward a paid license. If your constraint is licensing, that is the whole decision. The cost of that choice is age. A fork of a 4.x codebase does not inherit the architectural work done in iText 5, 7 or the current iText line. PDF 2.0 support and Brotli compression are additions layered onto the fork, per the README, not a rewrite. Teams that need the newest PDF features or a vendor support contract should look at the commercial iText line instead, and accept the license cost as the price of that support. Apache PDFBox is the other common reference point for Java PDF work, and the difference in approach is scope rather than license. OpenPDF bundles HTML conversion and page rendering as sibling modules under one repository; PDFBox keeps its core focused and leaves layout-heavy HTML rendering to separate projects. Neither approach is wrong, but they fail differently. OpenPDF gives you one dependency tree to reason about and one set of license files to audit, including the LGPL-only modules. A narrower core gives you fewer moving parts to upgrade together. Pick based on which of those two risks you would rather carry. ## License choices and the cost of upgrading The README states the dual license plainly: when using the library you may choose either Mozilla Public License Version 2.0 or GNU Lesser General Public License 2.1, with SPDX identifier MPL-2.0 OR LGPL-2.1+. Note that the repository metadata shows the license as NOASSERTION while the README and LICENSE.md describe the dual arrangement; if your compliance process reads metadata rather than files, that mismatch will surface and you should resolve it against LICENSE.md. This is a description of what the project states, not legal advice. The module split is where license review gets interesting. openpdf-html and openpdf-renderer are LGPL 2.1 only according to the README, so a product that depends on HTML-to-PDF has a different obligation profile from one that only uses the core artifact. Audit the actual dependency list, not just the headline dual license. Upgrade cost is a function of how much of the API you touch. The release history shows 3.0.3, 3.0.4 and 3.0.5 arriving between March and May 2026, and the repository contains a changelogs directory plus a createRelease.sh script, so there is a documented trail to read before bumping a version. Because the project is a fork of a frozen upstream, there is no vendor publishing migration guides for you; the changelogs and the iText migration wiki page are what exist. Pin your version, read the changelog between your current version and the target, and test against your own PDF corpus rather than a sample file. ## Conclusion Adopt OpenPDF if you need a Java PDF toolkit under LGPL or MPL and you can accept that input validation is your job: the Security Notice states OpenPDF does not perform input validation or enforce sandboxing. Do not adopt it if you want a maintained HTML-to-PDF pipeline beyond the openpdf-html fork, or if you expect the library to sanitize untrusted documents for you. Before committing, check the openpdf-html and openpdf-renderer license files, since the README says those modules are LGPL 2.1 only, and confirm the artifact coordinates com.github.librepdf:openpdf at version 3.0.5 resolve in your build. ## FAQ ### Is OpenPDF free to use? Yes. The README states OpenPDF is licensed under the LGPL and MPL open source licenses, and that you may choose either Mozilla Public License Version 2.0 or GNU Lesser General Public License 2.1. Note that openpdf-html and openpdf-renderer are LGPL 2.1 only. ### Is OpenPDF free for commercial use? The README describes dual licensing under MPL 2.0 or LGPL 2.1 and does not restrict commercial use, but it also states that openpdf-html and openpdf-renderer carry LGPL 2.1 only. Check the license files for the specific modules you depend on. ### Is OpenPDF safe to use? The README's Security Notice states that it is the responsibility of the application developer to ensure all input passed into OpenPDF is trusted, sanitized, and safe, and that OpenPDF does not perform input validation or enforce sandboxing. Treat validation as your own responsibility and read Security.md. ### Is OpenPDF open source? Yes. The README describes OpenPDF as open source software under LGPL and MPL, and it is a fork of iText version 4, specifically the iText svn tag 4.2.0. The source is hosted in the LibrePDF/OpenPDF repository. ### How do I install OpenPDF in a Java project? The README gives a Maven dependency on groupId com.github.librepdf, artifactId openpdf, version 3.0.5. The repository also includes a Maven wrapper (mvnw) for building the project itself. ### What is OpenPDF? It is an open source Java library for creating, editing, rendering and encrypting PDF documents, and for generating PDFs from HTML. The README lists modules for core PDF work, HTML conversion, rendering and Kotlin. ## Sources - [Issues](https://github.com/LibrePDF/OpenPDF/issues) - [LibrePDF/OpenPDF on GitHub](https://github.com/LibrePDF/OpenPDF) - [Project website](https://github.com/LibrePDF/OpenPDF) - [README](https://github.com/LibrePDF/OpenPDF/blob/master/README.md) - [Releases](https://github.com/LibrePDF/OpenPDF/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/librepdf-openpdf