Measurement transparency

Benchmark
Results

Every performance claim on this site is backed by reproducible measurements. This page documents the exact corpus, hardware, tooling, and versions used.

✓

PDFluent numbers measured 2026-04-13 on the hardware listed below. Competitor numbers marked with ~ are typical reference ranges from public benchmarks — not measured on this hardware. Cells marked — have not been measured yet.

Test corpus

Total documents21,537 PDFs (curated-20k corpus, incl. 642 XFA PDFs)

Location (VPS)/opt/xfa-corpus/curated-20k

SourcesUS government forms, EU institutional documents, legal archives, open-source PDF test suites (veraPDF, isartor, Apache PDFBox)

File size — min8 bytes

File size — median51.7 KB

File size — mean483.5 KB

File size — max269 MB

Total corpus size9.9 GB

Corpus is stored on the VPS at /opt/xfa-corpus/curated-20k. Statistics generated via ls + awk.

Hardware

Provider / instanceHetzner AX41-NVMe (dedicated server)

CPUIntel Xeon E-2176G @ 3.70 GHz (6 cores, 12 threads, turbo 4.70 GHz)

RAM64 GB DDR4 ECC

Storage2× NVMe SSD (879 GB usable)

OS / kernelUbuntu 22.04.5 LTS — kernel 5.15.0-164-generic

Thread countSingle-threaded (--workers 1) for all runs

CPU governorpowersave — results are conservative; performance governor would be faster

This is a dedicated server — no noisy neighbours. CPU governor is set to powersave, so results are conservative compared to performance mode.

Measurement methodology

Wall-time tooldate +%s%N (nanosecond precision) — 10 runs per test, median reported

Reported metricMedian wall time across 10 runs.

JVM benchmark policyCold start: JVM not pre-warmed (fair for serverless/CLI). Competitor numbers from public benchmarks, not measured on this hardware.

Memory measurementPeak RSS via /usr/bin/time -v (getrusage)

WASM bundle sizewasm-pack release build, gzip-compressed .wasm file size

ReproducibilityAll measurements taken 2026-04-13 on the hardware listed above. Raw data available on request.

Results

PDFluent numbers are median wall time from 10 runs on the hardware above. Competitor values marked with ~ are typical reference ranges from public benchmarks. — = not yet measured. n/a = not supported by that SDK.

Test	PDFluent	iText 8	PDFBox	Nutrient
Cold start (single page render) JVM not pre-warmed for iText/PDFBox. Competitor values are typical reference ranges.	1 ms	~500–800 ms	~400–700 ms	~80–150 ms
PDF/A validation (13 pages)	52 ms	—	—	—
Text extraction (per document avg) 100 documents, mixed page counts. Average 50 ms/doc.	50 ms	—	—	—
XFA flatten (single form) iText requires pdfXFA add-on; Nutrient and PDFBox have no XFA support.	3 ms	—	n/a	n/a
Render throughput (pages/sec) 100 single-page PDFs batch rendered. iText has no rendering engine.	917 pg/s	n/a	—	—
Memory — peak RSS Single-page render. JVM-based SDKs include JVM heap overhead.	6 MB	~150–300 MB	~100–250 MB	~50–120 MB
WASM bundle (gzip) Compressed .wasm file. Raw: 9.8 MB.	3.5 MB	n/a	n/a	~15 MB

Exact versions tested

Library	Version	Runtime / notes
PDFluent	1.0.0-beta.1	Rust 1.75+ (native binary, 13.4 MB)
iText 8	8.0.4	OpenJDK 17 (reference data)
Apache PDFBox	3.0.1	OpenJDK 17 (reference data)
Nutrient Web SDK	24.4.1	Node.js 20 LTS (reference data)

Questions about the methodology or want to dispute a result? Reach out via contact or open an issue on GitHub . We will re-run the relevant test and publish the corrected result.