Generating PDFs in Java: four libraries compared

The libraries

The newest releases on Maven Central on 5 November 2026. For the letters with an SVG logo, the modules the others need to draw SVG, each at its newest release: iText's svg module 9.8.0, Apache Batik 1.20, and for PDFBox the pdfbox-graphics2d bridge 3.0.5.

Each library is used the way its own documentation shows: iText's and OpenPDF's Document for flowing text, PDFBox's content streams with lines wrapped by hand, as it has no layout of its own, and PDFjet's TextFrame and Table, and for the report TextFlow. Every program reads the font files from disk once, into memory, and each document makes its fonts from those bytes, as a server would: iText and OpenPDF with their own default caches, PDFBox with its TrueType font parsed once and reused, as its API allows; PDFjet has no font cache and parses the bytes for each document. We ran iText both with its font cache and without it: without it, iText takes 1 to 5 ms more per document. The results here are with font caching.

Features

What each library has, as of the versions above, from its source at the release tag, its Maven POM and its documentation; only the features the documents use were tested here. A module is another jar of the same project; an add-on is a separate product of the same company.

PDFBox has no table of its own, so its programs here draw the tables by hand: a gray box behind the header, each cell's text measured to align the numbers right, a rule under each row, the header again on each new page, and the page numbers in a second pass once the pages are counted.

The other jars each of the others needs at run time, from its POM: PDFBox pdfbox-io, fontbox and commons-logging; iText io, commons, jackson-databind, slf4j-api and bouncy-castle-connector, and its layout jar for tables and flowing text; OpenPDF none: Maven adds brotli4j, its service jar and a native jar for the platform, needed only for Brotli compression (OpenPDF ran here without them). pdfHTML, pdfSweep and pdfOCR are iText add-ons under the same terms as iText Core, AGPL or commercial; pdfCalligraph, pdfRender and pdfXFA are commercial only. PDFjet Pro is PDFjet's add-on, commercial.

Far more people have worked on PDFBox, iText and OpenPDF than on PDFjet, and far more people use them, with more answers on the web for every question; iText also has a company behind it with paid support.

What was measured

Five tasks, specified exactly in SPEC.md, the same text and the same layout in every library:

• invoice: 1 page, the PDFjet logo, two address blocks, a table of 15 rows, totals.
• statement: 12 pages, a table of 600 transactions with running footers "Page n of N".
• report: 18 pages, 120 paragraphs of flowing text and 4 photos, JPEGs of 1870 × 2420 pixels, 1.8 MB in all.
• multilingual: 1 page, a notice in eight languages: English, French, German, Polish, Turkish, Greek, Bulgarian and Ukrainian.
• letters: 1,000 one-page letters with the logo as PNG, and again as SVG, timed as the batch (with Noto, the SVG logo only).

All in IBM Plex Sans, embedded as subsets, and all again in Noto Sans, a much larger font.

Method. Each library in its own fresh JVM, in a random order, three rounds; within a JVM the tasks run in the same fixed order for every library. Each task is warmed up for at least 20 runs and 3 seconds, then timed over 15 runs (the letters: 2 warm-up batches, 5 timed); the figure is the median of the three round medians. An asterisk (*) marks a figure whose rounds differ by more than 5%. The first PDF of a fresh process is the median of 5 processes. OpenJDK 25, .NET 10, Go 1.27, Swift 6.4, on an AMD Ryzen 5 5600G with Linux, after a reboot, in the performance power profile, nothing else running. After the run every PDF is checked, and the log is published: MuPDF opens it with no warning, it has the expected pages, the check strings of SPEC.md are in its text (the last sentence of every language for the notice), both fonts are embedded as subsets, and qpdf --check passes.

Results

Every measurement is drawn as a chart above, and the tables of every figure, with PDFjet in C#, Go and Swift beside the four libraries, are in the appendix at the end.

To draw the SVG logo the others need another module or library, and each was given the one its users would choose:

PDFjet in C#, Go and Swift

PDFjet is also written in C#, Go and Swift: the same classes and the same public API in each, and the same documents laid out the same way, which an automated check compares on every change. The last three columns of the tables in the appendix are the same documents made by each of them. For a program that makes PDFs, what counts is what the port of its language makes, and how fast: that is what those columns show.

Each port compresses its pages with the Deflate its language offers, but for Swift: Swift offers none on Linux, so the Swift port has an encoder of its own, which searches less than zlib. Its PDFs, the largest of the four, are larger because of that encoder, not because of Swift.

Reproduce it

Everything is in github.com/edragoev1/pdf-libs-benchmarks: SPEC.md, the text of the notice, the logo and the photos, the program of each library and port, the run and check scripts, and the raw results with their logs. java/run.sh runs the four Java libraries (about 15 minutes) and java/check.sh checks every PDF; run-all.sh runs everything, as for these results; dotnet/, go/ and swift/ run PDFjet's other ports the same way; make-tables.py makes every table of this report from the results.

Judgment calls

• The table rows of every library are 13.2 pt high, PDFjet's default for IBM Plex Sans at 9 pt; iText's and OpenPDF's cell padding was adjusted to match it, as without it their page counts differ.
• OpenPDF uses setStrictImageSequence(true), or it moves text above a photo that goes to the next page.
• Every library is at its default compression: all four compress their streams, and PDFBox alone writes object streams, its default, which make its files smaller; iText and OpenPDF can write them too, as an option.
• PDFBox shapes ligatures (GSUB) by default on every showText, a cost that grows with the font's tables; the others do none, so it is turned off here (setEnableGsub(false)), as a PDFBox user who wants speed does. In the run of 26 October, with it on, PDFBox took 43 ms for the statement in Plex and 524 ms in Noto; without it, 5.8 and 5.4 ms.
• iText and OpenPDF use their large-table modes for the statement, as their documentation shows for long tables. iText's ordinary Table was timed too, and was slower (about 106 ms against 72, in the run of 26 October).
• PDFBox's report time is almost all in reading the four photos: createFromByteArray, as its documentation shows, decodes each JPEG (about 38 ms here) to read its size and colors, then embeds its bytes unchanged. Building the image object by hand with DCTDecode avoids it; few users do.
• PDFBox draws one rule under each table row and one header rectangle, where the others draw a border under each cell: slightly less work for PDFBox.
• With Noto Sans, PDFjet's report is 21 pages to the others' 20, and its statement 13 to their 12: PDFjet spaces lines and table rows by the font's own height, and Noto's is larger than Plex's, so PDFjet makes a page more of each. With Plex every library makes the same pages (java/check.sh prints the counts side by side).

Appendix: the tables

Time per document, IBM Plex Sans

Time per document, warm, ms (the letters: the batch of 1,000, s). In every table lower is better, faster, less memory, smaller files, fewer lines, and the best of the four Java libraries is in bold. The last three columns are PDFjet in C#, Go and Swift, shown with them but not ranked against them.

* The three rounds of this figure differ by more than 5%; the figure is their median.

Time per document, Noto Sans

With Noto Sans, a large font, ms (the letters: the batch of 1,000, s):

* The three rounds of this figure differ by more than 5%; the figure is their median.

The size of the PDFs

The size of the PDFs, KB:

Memory allocated per document

Memory allocated per document, MB. Each runtime counts it its own way: Java and C# the bytes the timing thread allocates, Go every allocation of the process (Go's TotalAlloc), Swift every malloc of the thread:

The first PDF of a process

The first PDF of a fresh process, each of the five documents, as a serverless function or a newly started container pays it on a cold start, or a desktop app on its first export, ms; then the peak memory of the whole process, mostly the JVM itself, MB:

Lines of code

Lines of code of each program, without blank lines and comments; "helpers" are the methods a library's tasks share (fonts, cells, footers, word wrapping), counted in the total: