SDK 1.1.0

Benchmarks

With the table model, PDFluent scores higher than Docling and pymupdf4llm on table structure (TEDS) on FinTabNet and PubTables-1M.

In its default fast mode it extracts a page in milliseconds and peaks at 17 MB of memory.

Every result names its mode, its dataset, the machine it ran on and the date it was measured.
+0.1501

TEDS over Docling on FinTabNet tables

balanced + table model
+0.1321

TEDS over pymupdf4llm on FinTabNet tables

balanced + table model
17 MB

peak memory, against 46 to 4,454 MB for six other parsers

fast
11.6 ms

per page on one thread, roughly 200 times less time than Docling

fast
Two tiers

Two modes, measured separately

  • fast is the default. The engine reads the PDF's text layer and runs no model. The speed and footprint results are fast mode.
  • balanced with the table model is opt-in. It adds a layout model and Microsoft's Table Transformer, which you download once with pdfluent models install. It runs in Rust, Python, Node and the CLI. The table-structure results are this mode.

Structured extraction (Markdown, blocks, Docling JSON) is a Preview in 1.1.0: output quality is still improving and the API may change in a minor release. Plain text extraction is not a Preview.

Tables vs Docling 2.126.0 and pymupdf4llm 1.28.2

Tables: ahead of pymupdf4llm on all 4, of Docling on 2 of 5.

Balanced tier + table model · opt-in · Preview
AheadLevel or behind
Mode
balanced with the table model
Compared with
Docling 2.126.0 and pymupdf4llm 1.28.2, on the same pages
Measured
PDFluent on 2026-10-14; Docling and pymupdf4llm on 2026-10-08

Higher than pymupdf4llm 1.28.2 on all 4 table measures, and higher than Docling 2.126.0 on 2 of 5, with 2 level. Each value is our score minus the other tool's, followed by a 95% interval from a paired bootstrap over documents.

FinTabNet · TEDS120 pages, 67 documents
vs Docling 2.126.0Ahead
+0.150[+0.119; +0.183]
vs pymupdf4llm 1.28.2Ahead
+0.132[+0.106; +0.158]
A38 · 14-10-2026
PubTables-1M · TEDS120 pages, 55 documents
vs Docling 2.126.0Ahead
+0.087[+0.055; +0.128]
vs pymupdf4llm 1.28.2Ahead
+0.081[+0.046; +0.127]
A39 · 14-10-2026
ParseBench · record match100 pages, 32 documents
vs Docling 2.126.0Level
+0.027[−0.077; +0.128]
vs pymupdf4llm 1.28.2Ahead
+0.314[+0.181; +0.452]
A40 · 14-10-2026
ParseBench · GriTS100 pages, 32 documents
vs Docling 2.126.0Level
+0.014[−0.055; +0.078]
vs pymupdf4llm 1.28.2Ahead
+0.186[+0.101; +0.275]
A40 · 14-10-2026
ParseBench · fully correct tables100 pages, earlier build
vs Docling 2.126.0Behind
−0.114[−0.231; −0.016]
vs pymupdf4llm 1.28.2Not measured
A37 · 08-10-2026

Balanced tier (quality=balanced) with the table model: opt-in, Preview in SDK 1.1, for Python, Node, Rust and the CLI. Measured 14-10-2026; the fully-correct-tables row 08-10-2026 on an earlier build. Pages come from the tuning (development) split of each dataset, so our side is an upper bound, not a held-out result. Paired bootstrap per document, 95% intervals; level means the interval includes zero. The table model (Microsoft TATR v1.1) was trained on PubTables-1M and FinTabNet.c; overlap with these pages has not been checked. Docling 2.126.0, pymupdf4llm 1.28.2. Reproducible with pdfluent-bench (coming).

  1. 1 FinTabNet (financial reports), 120 pages from 67 documents, from the tuning split: pages we looked at while building the feature, so our score is an upper bound and not a held-out result. Measured 2026-10-14 (PDFluent) and 2026-10-08 (Docling, pymupdf4llm). Reproducible with pdfluent-bench (coming).
  2. 2 PubTables-1M (scientific articles), 120 pages from 55 documents, from the tuning split (upper bound, not held out). Measured 2026-10-14 (PDFluent) and 2026-10-08 (Docling, pymupdf4llm). Reproducible with pdfluent-bench (coming).
  3. 3 ParseBench tables, 100 pages from 32 documents, from the tuning split (upper bound, not held out). Measured 2026-10-14 (PDFluent) and 2026-10-08 (Docling, pymupdf4llm). Reproducible with pdfluent-bench (coming).
  4. All three: Microsoft trained Table Transformer v1.1-all on PubTables-1M and FinTabNet.c. We have not checked whether our sample pages are in that training data. PDFluent ran on a 1.1.0 pre-release build; the extraction code is unchanged in the 1.1.0 release. These are quality scores, so the machine does not change them.
Footprint and speed vs six parsers

Fast mode: milliseconds per page, megabytes of memory

Fast tier · default · no models
Mode
fast (no model, text layer only)
Dataset
DocLayNet v1.2, test split, 200 pages from the half we tune on
Machine
one cpx42 cloud VM, 8 vCPU, Linux
Build
a pre-release build from late September 2026, before 1.1.0
Footprintvs all six parsers
Peak memoryAhead
17 MBvs 46–4,454 MB

Lower than each of the six. The range runs from the lightest to the heaviest of them.

Install sizeAhead
8 MBvs 48–2,308 MB

Lower than each of the six. Models for the balanced tier are a separate, opt-in download.

Cold startLevel
114 msvs 115 ms–58 s

LiteParse 2.14.7 started in 115 ms, Docling 2.126.0 in 58 s; the other four fall in between.

C15 · 26-09-2026 · one cpx42 VM · 200 DocLayNet pages (tuning half) · LiteParse 2.14.7, pdfplumber 0.11.8, pymupdf4llm 1.28.2, Docling 2.126.0, Unstructured 0.27.8 and MinerU 4.0.7
Speedms per page · lower is better · each tool its own full batch run
PDFluentFast tier
11.6 msper page, single-thread
1.8 msper page, 8 threads

About 200× faster than Docling 2.126.0, single-thread. pymupdf4llm 1.28.2 took 222 ms per page.

PDFluent, 1 thread11.6
PDFluent, 8 threads1.8
LiteParse 2.14.76.4†
pymupdf4llm 1.28.2222
MinerU 4.0.72,295
Docling 2.126.02,467
Unstructured 0.27.83,990
pdfplumber 0.11.8not run
C16 · 27-09-2026 · one cpx42 VM, 8 vCPU · 200 DocLayNet pages · whole process divided by pages · † LiteParse ran with its own default thread count, which was not pinned or measured, so it is not on the same basis as the 1- and 8-thread figures. pdfplumber was not part of the speed run.

Speed is milliseconds per page for one batch: total process time divided by the number of pages, the same way the other tools are timed. Our numbers were measured on 2026-09-27. The other tools were measured on 2026-09-25 and 2026-09-26 on the same machine class.

On PubTables-1M our figures were 23.9 (one thread) and 4.3 (eight threads) ms per page. The batch produced the same Markdown as running one process per page, on every page.

Unstructured (hi_res) and MinerU run OCR inside their pipelines, and that time is part of their figures. Docling ran with OCR off. PDFluent fast and pymupdf4llm read the text layer only.

The install size is for fast mode. Balanced mode needs the separate models package: the layout model is 306,654,422 bytes and the table model 118,206,817 bytes, plus ONNX Runtime for your platform. A default install has no models; pdfluent models install fetches them and checks every file against pinned hashes.

Office and HTML vs Docling 2.132.0

Office and HTML: at least as good as Docling

Compared with
Docling 2.132.0, default settings on both sides
Data
public U.S. federal files collected from many websites
Method
difference with a 95% interval over websites
Measured
2026-10-04

On every axis in the third column, the lower end of the interval is zero or higher: the data rules out Docling being ahead. The last column lists the axes these runs do not support a claim on.

FormatSampleAt least as good as Docling onNo claim on
DOCX93 files, 23 websitestext, words, headings, heading levels, list levels, tables, table structure (TEDS), coveragenone
PPTX68 files, 20 websitestext, words, headings, heading levels, lists, reading ordertables, table structure (TEDS)
XLSX93 files, 25 websitessheet headings, tables, table structure (TEDS)words
HTML50 pages, 26 websiteslists, tablestext, coverage
Engine · before 1.0

Engine: timings, robustness, rendering, conversion

These results come from before 1.0, so read each one with its date.

Open, extract text, save

Median, with the 95th percentile in brackets.

Operation40 government documents480 test-suite files
Open1.7 ms (p95 30.8 ms)0.26 ms (p95 1.95 ms)
Extract text70.8 ms (p95 635.2 ms)0.232 ms (p95 16.331 ms)
Save0.4 ms (p95 7.2 ms)0.048 ms (p95 0.537 ms)
  • Government documents: 40 govdocs files (median size 292 KB, 95th percentile 3.6 MB), one MacBook, measured on 2026-08-24.
  • Test-suite files: 500 public PDFs from the pdf.js, PDFBox and veraPDF test suites, of which 480 could be read. MacBook Pro with M1 Pro, measured on 2026-09-06. This set is not a sample of real documents: most files are there because they once broke something, and many are tiny, damaged on purpose or have no text layer. That is why these times are far below the government documents.

Robustness

  • 50,000 real PDFs processed with zero crashes (2026-03-09).
  • 76 failures in 550,000 test results (0.014%), all from 7 test files that are known to be broken (2026-03-09).

Rendering, against MuPDF as reference

  • On 5,000 PDFs, 94% render at SSIM 0.95 or higher compared with mutool. Mean SSIM is 0.9869 (2026-04-19).
  • Zero crashes on the files that were not adversarial fuzzing input; 8 of the 5,000 (0.16%), all adversarial (2026-04-19).

PDF/A conversion

  • On a held-out set of 120 govdocs documents, 118 came out PDF/A-2b conformant according to veraPDF 1.28.2. A validator crash counts as not conformant. The median document kept all of its text, compared word by word with mutool as the reader (2026-08-24).
  • How we measure conversion, and why we report text kept next to conformance: how we measure PDF/A.

Replacing text in an existing PDF

197 documents, five words per document spread through the file (977 words). After replacing, we read the file back with pdftotext, which is not our code. Measured on 2026-08-24.

  • With font fallback on: 97.1% of words replaced and 92.5% readable afterwards, and 76.6% of documents fully correct. The fallback added no unreadable words.
  • Default settings: 93.4% replaced, 88.8% readable, and in 70.6% of documents all five words came through.
Method

Reproduce it

After the 1.1.0 release we will publish the benchmark harness as a public repository, pdfluent-bench. It will hold the scripts, the page lists and the scoring code behind the results on this page, so you can run them on your own machine and check our numbers.

This page grows as runs finish. A new result lands here with its mode, dataset, split, machine and date.

Think a result is wrong, or want the method for one? Tell us via contact. We will re-run the test and publish the corrected result here.