In balanced mode with the table model, PDFluent's table structure scored higher than Docling on FinTabNet and PubTables-1M. In fast mode, it used less memory and less time per page than Docling. Each section names its mode, dataset and date.
Table structure was measured on 2026-10-14 on a 1.1.0 pre-release build; Docling and pymupdf4llm were measured on 2026-10-08. Footprint figures date from [C15, 2026-09-26] and speed figures from [C16, 2026-09-27]; structured extraction ships as Preview in SDK 1.1.0, so re-check before reusing a number.
Mode: quality=balanced with the table model. The numbers are TEDS differences, ours minus theirs, with a 95% interval from a paired per-document bootstrap.¹
| Axis | Sample | vs Docling | vs pymupdf4llm | Verdict |
|---|---|---|---|---|
| FinTabNet, TEDS [A38, 2026-10-14] | 120 pages, 67 documents | +0.150 [+0.119; +0.183] | +0.132 [+0.106; +0.158] | Higher than Docling and pymupdf4llm. Tuning split.¹ |
| PubTables-1M, TEDS [A39, 2026-10-14] | 120 pages, 55 documents | +0.087 [+0.055; +0.128] | +0.081 [+0.046; +0.127] | Higher than Docling and pymupdf4llm. Tuning split.¹ |
Sources: FinTabNet [A38, 2026-10-14], PubTables-1M [A39, 2026-10-14]; competitors measured 2026-10-08.
¹ Mode: quality=balanced with the table-structure model. We measured our side on 2026-10-14 on a 1.1.0 pre-release build with the same extraction code, and Docling 2.126.0 and pymupdf4llm 1.28.2 on 2026-10-08 on the identical pages. The pages come from each dataset's development (tuning) split, which we used while building the table work, so our side is an upper bound, not an independent held-out test. Each number is ours minus theirs, with a 95% interval from a paired per-document bootstrap. The table-structure model we ship is Microsoft's Table Transformer v1.1-all, which Microsoft trained on PubTables-1M and FinTabNet.c. We have not checked whether our sample pages fall inside its training data, so the FinTabNet and PubTables-1M results may favour us for that reason too. Table structure only, on these three samples. Reproducible with pdfluent-bench (coming).
Peak memory, install size and cold start, measured once per competitor and scored from cache, against PDFluent measured live.
Compared against: LiteParse, pdfplumber, pymupdf4llm, Docling, Unstructured and MinerU.
| Metric | PDFluent | Six parsers | Note |
|---|---|---|---|
| Peak RSS | 17 MB | 46 – 4,454 MB | Across the six comparison parsers. |
| Install size | 8 MB | 48 – 2,308 MB | Across the six comparison parsers. |
| Cold start | 114 ms | 115 ms (LiteParse) – 58 s (Docling) | Equal-basis comparison: this is the one axis LiteParse can be compared on directly (see Methodology). |
CLAIMS.md C15, 2026-09-26. Run structured-doclaynet-20260926T031404Z-rescored-1f396f0b3, 200 DocLayNet pages (tuning half), one cpx42, master 400df87f6.
Full-batch throughput on DocLayNet, the whole process divided by page count, the same way the competitors below are measured (see Methodology). PDFluent is roughly 200× Docling at a single thread.
| Tool | ms/page (full batch, DocLayNet) |
|---|---|
| PDFluent, 8 threads | 1.8 |
| PDFluent, 1 thread | 11.6 |
| pymupdf4llm 1.28.2 | 222 |
| Unstructured 0.27.8 | 3,990 |
| MinerU 4.0.7 | 2,295 |
| Docling 2.126.0 | 2,467 |
On PubTables, the same two figures (1 thread / 8 threads) are 23.9 and 4.3 (ms/page, competitor PubTables batch figures are not part of this claim).
LiteParse measured 6.4 ms/page in its own default setup, but its thread count was not fixed or verified, so that figure is not on the same basis as PDFluent's 1-thread (11.6) and 8-thread (1.8) numbers above. This page does not claim PDFluent is faster or slower than LiteParse on a per-page basis; CLAIMS.md C16 is explicit that the comparison would need LiteParse measured at 1 and at 8 threads, on the same machine, first.
CLAIMS.md C16, 2026-09-27. Runs structured-doclaynet-20260927T164425Z and structured-pubtables-1m-20260927T172959Z, master de4f84868, one cpx42 (8 vCPU).
Machine class: A single cpx42 VM for both C15 (2026-09-26) and C16 (2026-09-27, 8 vCPU). One machine, one machine class, across every figure on this page. A number carries its machine class or it is not comparable.
Competitor versions pinned for the footprint run (CLAIMS.md C15, peildatum/as-of 2026-09-26). Re-check before reuse: these version pins are dated, not permanent:
| Docling | 2.126.0 |
| MinerU | 4.0.7 |
| Unstructured | 0.27.8 |
| LiteParse | 2.14.7 |
| pymupdf4llm | 1.28.2 |
| pdfplumber | 0.11.8 |
How competitors were measured: Competitors were measured once and scored from cache rather than re-run for every comparison (CLAIMS.md C15). For the speed claim, PDFluent's column was measured live for this run; the competitor figures came from the same cache (measured 2026-09-25/26 and 2026-09-26, same machine class).
Per-process vs full-batch: The speed figures above are full-batch: one process, divided by page count, which is how the competitor tools are measured. PDFluent also has a per-process number (about 64 ms, which includes per-page process startup). That number sits alongside the full-batch figures in the run files, but it is not the number used for comparison here, because it would not be comparing like with like. The full-batch run was verified to produce identical markdown output to running one process per page, on 200/200 DocLayNet pages and 120/120 PubTables pages (CLAIMS.md C16).