JPedal vs Apache PDFBox: PDF to image speed and memory benchmark

Our JPedal Java PDF library 2026.11 rendered PDFs to images in 21% less time than Apache PDFBox 3.0.8 and allocated 23% less memory. We ran both on 2,075 public PDFs from Govdocs1 and timed the 1,914 where both drew the same pages. The code is on GitHub, so you can repeat the test on your own files or another library.

TL;DR The gap depends on what’s in the file. Half the files were a draw, mostly plain text pages, and PDFBox was faster on 20%. On plain text and vector pages there’s little between them. On PDFs with images JPedal pulls ahead, most of all on black-and-white scans, where it was twice as fast on the typical file. On the median file JPedal also held less than half the memory PDFBox did at its peak.

Contents:

Is JPedal faster than PDFBox?

The other 978 files were a draw. We count a file as a draw when the two times are within 5% or 5ms of each other, about the variation we measured between runs of the same file. Without that rule, JPedal was faster on 940 files and PDFBox on 974, mostly by a few milliseconds.

JPedal’s total was 0.79 times PDFBox’s. Per file, the geometric mean ratio was 0.93 (95% confidence interval 0.91 to 0.94), so on a typical file JPedal took about 7% less time.

The two figures differ because heavy files dominate the total. A plain text file PDFBox renders a few milliseconds faster barely moves the total. A scan that takes 10.3 seconds in PDFBox and 2.6 in JPedal moves it by almost 8.

How we tested

The files come from Govdocs1, a corpus of real documents crawled from US government web servers, which Digital Corpora describes as freely redistributable to the best of its knowledge. We used every PDF in zips 500 to 504: 2,075 files and 51,933 pages. We chose those zips before running the benchmark and hadn’t used them in any JPedal performance work.

We compared JPedal 2026.11 with Apache PDFBox 3.0.8, the current release. We have been following PDFBox since Ben Litchfield started it in 2002. To make it comparable, we tested it with its optional decoders installed. PDFBox reads JBIG2 and JPEG 2000 images only if two optional libraries are on the classpath; without them, it skips those images and logs a warning. We added both, JBIG2 ImageIO 3.0.5 and JAI Image I/O JPEG 2000 1.4.0, so PDFBox did the same work as JPedal.

Both libraries rendered every page to an RGB image at 150dpi, with their default settings, using the calls in the code at the end of this post. A file’s time runs from opening it to finishing its last page.

They ran in one JVM on one thread: Java 21.0.13 on an Apple M5 Mac running macOS 27, with a fixed 4GB heap. One pass through every file was thrown away first, so class loading and JIT compilation didn’t land on either library’s figures. Then came three measured passes. Each shuffled the file order, each file picked at random which library went first, and a full garbage collection ran before each timing, so neither library inherited the other’s garbage. We took the median of the three passes for each page.

The benchmark code is on GitHub under the Apache 2.0 license, and the per-file results are available as CSV. To test another Java PDF library, write one small class that opens a file and renders a page, and name it on the command line.

Checking both libraries drew the same thing

Before any timing, both libraries rendered every page and we compared the two images. Pixels never match exactly between two renderers, because antialiasing and font hinting differ, so the check compares the pages in 4×4 pixel cells, where those differences average out. A page fails if the image sizes differ, if the overall darkness differs a lot, if the cells differ too much on average across the whole page, or if any 64×64 pixel area shows content in one image that is missing or different in the other. That last test catches a skipped image or a missing block of text too small to change the page as a whole.

A file counted only if every page passed. 1,914 of the 2,075 did. JPedal rendered all 2,075. PDFBox threw a font parsing error on one file, 504076.pdf, so that file is out of the comparison.

Each of the other 160 had at least one page that differed. In the side-by-side images, many weren’t missing anything: pages that look the same at a glance, or one library drawing a border around a link where the other didn’t. The rest were real differences: different substitute fonts for a font the PDF doesn’t include, or pages rendered at different sizes.

Excluding files could tilt the result, so we also ran the numbers on all 2,074 files both libraries rendered. JPedal’s total was 0.78 times PDFBox’s, against 0.79 for the matched files.

Which documents each library is faster on

We sorted the files by what’s in them, as in our PDF vs PNG test. A file counts as image-heavy when images make up more than half its size, and takes the name of the image compression that dominates.

On plain text and vector pages the two are level. Of those files, 67% were a draw, PDFBox was faster on 22% and JPedal on 11%, and the totals end up within 2%. Fonts matter less than images. On plain text pages the totals were within 2% whether or not the fonts were embedded.

On PDF files with images JPedal is generally quicker, and the more the file depends on images, the bigger the lead: 12% less time on text with small images, 23% on JPEG-heavy files, 28% on Flate-compressed images and 62% on scans. On scans, JPedal was faster on 58 of the 63 and twice as fast on the typical file.

JPedal was faster on all 7 JPEG 2000 files, but 7 files are too few to say much about.

Light, medium and heavy documents

Grouping by how long files took, averaged across both libraries:

Light files are close, and most are a draw. The heavier the file, the more often JPedal wins and the bigger the margin. Page count alone matters less. JPedal’s total was between 0.72 and 0.82 times PDFBox’s in every page-count band, from single pages to files over 50 pages.

What the difference means in practice

On a typical file the difference is too small to notice. The median file took 104ms in JPedal and 109ms in PDFBox.

It’s noticeable on heavy documents. 500366.pdf, an 88-page scan, took 2.6 seconds in JPedal and 10.3 in PDFBox. It also adds up at volume. The average file took 0.22 seconds in JPedal and 0.28 in PDFBox, so a million documents like these on one thread would take about 62 hours against 79.

If your documents are plain text, expect the two libraries to perform about the same. If you process scans or image-heavy files, expect JPedal to be faster.

Which uses less memory, JPedal or PDFBox?

We measured memory in a separate run on the same files, one library per JVM, so neither could be affected by the other’s garbage.

Allocated memory is everything a library creates while it converts a file. Most of it is short-lived, and all of it is work for the garbage collector. Over 43,000 pages, JPedal allocated 23% less in total, and less on 58% of files.

Peak memory held is the most a library keeps alive at once while a file is open: the document, its caches and the page being drawn. On the median file JPedal held 4.0MB and PDFBox 9.1MB. The gap widens on heavy files. For 500366.pdf, the 88-page scan, PDFBox allocated 19.6GB and held up to 718MB at once; JPedal allocated 1.3GB and held 9MB.

Allocation isn’t the same as how much memory a library needs. To measure that, we converted the whole corpus again with the heap capped at 256MB, 512MB, 1GB and 2GB. Both libraries converted every file at every size, apart from 504076.pdf, which PDFBox couldn’t render at any heap size because of the font error. For documents like these, neither needs a big heap. One scan in the second set needed more. PDFBox ran out of memory on it at 256MB and 512MB, and JPedal converted it at 256MB (details below).

A second set of files

To check the results weren’t a quirk of one set of files, we ran everything again on 1,274 different Govdocs1 PDFs, from zips 015 to 019, which we also hadn’t used in performance work. 1,140 passed the output check.

On the second set, JPedal took 31% less time in total, against 21% on zips 500 to 504, and was faster on 46 of the 50 scans. Plain text and vector files were close again, and JPedal allocated 33% less memory.

Does PDFBox run out of memory?

On one file in this set, yes. Unlike on zips 500 to 504, PDFBox ran out of memory on 018480.pdf, a 24-page black-and-white scan, with the heap at 256MB and at 512MB. On that file PDFBox allocated 1.8GB and held up to 219MB at once; JPedal allocated 652MB and held 6MB.

PDFBox with subsampling on

PDFBox has a setting, setSubsamplingAllowed(true), that lets it read only every second pixel, or every third and so on up to every eighth, from an image that has more pixels than it covers in the output. PDFBox’s Javadoc for the setting says:

Subsampling may be faster and less memory-intensive in some cases, but it may also lead to loss of quality, especially in images with high spatial frequency.

Scanned text is high spatial frequency: sharp black edges on white. So we ran the second set again with it on.

With subsampling on, JPedal still took 11% less time in total and allocated 8% less memory. On scans PDFBox was 8% faster, but 21 more files failed the output check, 9 of them scans, and on those the text comes out thinner and lighter than without subsampling. It didn’t fix the memory problem either. PDFBox still needed 1GB for 018480.pdf.

018778.pdf, page 2, rendered at 150dpi and shown at actual size. Left: JPedal. Right: PDFBox with subsampling on.

Best and worst cases for JPedal

These were JPedal’s biggest single-file wins and losses against PDFBox.

The biggest JPedal wins are mostly image-heavy files, where PDFBox spends seconds on pages JPedal finishes in a fraction of the time. The biggest losses are text-heavy files. 502212.pdf, a single text page, takes PDFBox 0.12 seconds and JPedal 0.63. 500976.pdf takes PDFBox 0.59 seconds and JPedal 2.53, the largest gap in absolute terms.

When to use JPedal and when to use PDFBox

Use PDFBox if you need an open source license. If your documents are plain text and vector pages, the two libraries took about the same time, and PDFBox costs nothing. If your files include black-and-white scans or JPEG 2000 images, add the two optional decoder libraries; PDFBox’s documentation notes they use licenses that aren’t compatible with Apache 2.0, so check their terms before you ship.

Use JPedal if you render scans, image-heavy documents or high volumes. It took 62% less time on black-and-white scans and 43% less on the heaviest files, and held less memory on the median file. It reads every image format in this test without extra libraries, and support is included in the license.

If you’re not sure which group your files fall into, run the benchmark on them. It’s on GitHub and takes any folder of PDFs. Speed is only one reason people move, and our PDFBox alternative post covers the others.

How we rendered PDFs to images in Java

These are the calls the benchmark times, with the timing code stripped out. Both render page by page at 150dpi to an RGB BufferedImage. For a step-by-step guide, see our Java PDF to image tutorial.

JPedal, with its ConvertPagesToImages class:

import org.jpedal.examples.images.ConvertPagesToImages;

import java.awt.image.BufferedImage;

public class JPedalToImages {
    public static void main(String[] args) throws Exception {
        ConvertPagesToImages convert = new ConvertPagesToImages(args[0]);
        convert.setPageScaling(150 / 72f); // 1.0 = 72dpi
        if (convert.openPDFFile()) {
            for (int page = 1; page <= convert.getPageCount(); page++) {
                BufferedImage image = convert.getPageAsImage(page, false);
            }
        }
        convert.closePDFfile();
    }
}

PDFBox, with PDFRenderer:

import org.apache.pdfbox.Loader;
import org.apache.pdfbox.pdmodel.PDDocument;
import org.apache.pdfbox.rendering.ImageType;
import org.apache.pdfbox.rendering.PDFRenderer;

import java.awt.image.BufferedImage;
import java.io.File;

public class PdfBoxToImages {
    public static void main(String[] args) throws Exception {
        try (PDDocument document = Loader.loadPDF(new File(args[0]))) {
            PDFRenderer renderer = new PDFRenderer(document);
            for (int page = 0; page < document.getNumberOfPages(); page++) {
                BufferedImage image = renderer.renderImageWithDPI(page, 150, ImageType.RGB);
            }
        }
    }
}

JPedal numbers pages from 1 and PDFBox from 0. You can run the JPedal half with the free JPedal trial. The trial adds a watermark to its output, and our figures come from the full 2026.11 release, so expect your JPedal times to differ from ours.

FAQ

Which is faster, JPedal or PDFBox?

JPedal, overall. On the 1,914 of 2,075 public PDFs where both libraries drew the same pages, JPedal took 21% less total time than PDFBox 3.0.8, and the typical file took about 7% less. It wasn’t faster on every file. Counting files within 5% or 5ms as a draw, JPedal was faster on 29%, PDFBox on 20%, and half were a draw, mostly plain text pages. On a second set of 1,140 different files, JPedal took 31% less time.

Where is the difference biggest?

On scanned documents. For 63 black-and-white scans, JPedal took 38.0 seconds in total against PDFBox’s 99.2, and was faster on 58 of them. On plain text and vector documents the two were within 2% of each other.

Does JPedal use less memory than PDFBox?

Yes. Across 1,914 files JPedal allocated 23% less memory in total, and the median file held 4.0MB at its peak against PDFBox’s 9.1MB. On the heaviest file, an 88-page scan, PDFBox held 718MB and JPedal 9MB.

Does PDFBox need extra libraries to render every PDF?

Yes, for two image formats. PDFBox reads JBIG2 and JPEG 2000 images only if the optional JBIG2 ImageIO and JAI Image I/O libraries are on the classpath. Without them it skips those images and logs a warning. We added both, so PDFBox drew the same images as JPedal.

Should I use JPedal or PDFBox?

If your documents are plain text and vector pages, the two libraries are about the same speed, so choose on license and support. If they include scans or a lot of images, JPedal took 12% to 62% less time. PDFBox is free under Apache 2.0; JPedal is commercial, with support included in the license.

Can I run the benchmark myself?

Yes. The code is on GitHub under the Apache 2.0 license, and the Govdocs1 corpus is free to download.