PDFluent vs. iText: A Performance Comparison

Benchmarks are easy to manipulate and hard to interpret. This post attempts to do a fair comparison between PDFluent and iText 9 for server-side PDF processing. We explain exactly how we measured, what the numbers mean, and where iText is legitimately better.

One upfront note: iText has no rendering engine. It cannot rasterize a PDF to an image. Any benchmark involving rendering is PDFluent-only, so we exclude those entirely and focus on the operations both libraries support.

Test environment

Instance:    AWS c6i.2xlarge
CPU:         Intel Xeon Ice Lake, 8 vCPU @ 3.5 GHz
RAM:         16 GB
OS:          Ubuntu 22.04 LTS
PDFluent:    v1.0 (current release)
iText:       9.1.0 (Java), OpenJDK 21.0.2 (GraalVM)
JVM flags:   -Xms512m -Xmx4g -XX:+UseG1GC
Warmup:      10 runs discarded
Measurement: median of 100 runs
PDF corpus:  100 files, 1–50 pages, varied content

We used GraalVM (not standard OpenJDK) to give iText the best possible JVM performance. Standard OpenJDK JIT typically runs 15–25% slower than GraalVM for this type of workload.

Cold start

"Cold start" means: from process launch to first byte of output. This matters for serverless functions, short-lived containers, and any deployment where you can't keep a warm process pool running.

The JVM startup time dominates iText's cold start. GraalVM's ahead-of-time compilation (GraalVM Native Image) can reduce this significantly — we tested that separately:

GraalVM Native Image brings iText much closer. If you compile iText to a native binary, the cold start gap shrinks from ~40× to ~6×. The tradeoff: GraalVM Native Image has restrictions (no dynamic class loading, reflection requires configuration) that can be difficult to satisfy with a complex library like iText.

PDF parsing throughput

Parse 1,000 PDFs (varied sizes, 1–50 pages each). Measure total wall time and peak RSS.

PDFluent's memory advantage is significant: 480MB vs 1,940MB for the same workload. This is partly the JVM overhead (heap metadata, GC bookkeeping, class metadata) and partly iText's object model, which keeps more of the document in memory during parsing.

Memory profile

We also measured peak memory per document, not just batch totals:

The scanned document case shows the biggest gap: PDFluent decodes image streams lazily and frees them after processing; iText's parser holds more of the object graph in the Java heap.

Text extraction

iText's text extraction quality for complex layouts (multi-column, tables, mixed writing directions) is better than ours. iText uses a spatial clustering algorithm that produces more accurate reading-order reconstruction. Our extractor works well for simple layouts but can produce out-of-order text for documents with overlapping text blocks or unusual column structures.

PDF/A validation

iText is the reference implementation for PDF/A processing. Their validation engine is co-developed with the veraPDF team and is considered the most accurate PDF/A validator available. We validate against the same veraPDF conformance checker to compare our results.

We're faster; they're more accurate. The 1.8% accuracy gap on the isartor test suite corresponds to 7 documents where we produce a false negative (we say conformant; the document isn't) or false positive (we flag a violation that isn't there). iText has one false result on this corpus.

For most production use cases, 98.1% accuracy is acceptable. For a workflow where you're certifying documents for legal archiving, that 1.9% matters — in that case, route the edge cases through iText's validation or use veraPDF directly.

ZUGFeRD / Factur-X

iText has good ZUGFeRD/Factur-X support via their pdfHTML and ZUGFeRD-specific API. PDFluent's pdf-invoice crate covers the same ground.

Reproducing these benchmarks

The benchmark code is on GitHub. To run it yourself:

# Public benchmark corpus is not yet open-source.
# Mail [email protected] for the methodology and corpus access.
# Once published, the snippet below is the entry point:
cd benchmarks

# Install dependencies
cargo build --release
mvn -f itext-bench/pom.xml package

# Generate test corpus (requires ~2GB disk)
./scripts/generate-corpus.sh

# Run benchmarks
./scripts/run-all.sh --output results.json

# View results
./scripts/report.py results.json

The corpus generator creates PDFs using a mix of open-source tools (Ghostscript, LibreOffice, LaTeX) so the test set is reproducible. If you get substantially different results on your hardware, open an issue — we want to know.

Summary