PDF Parsing for RAG in 2026: MinerU, Docling, Marker Compared

Document parsing is the step most RAG pipelines get wrong and then blame on the retriever. This is a working comparison of the open-source PDF parsers that matter in mid-2026: MinerU, Docling, Marker 2, Surya, PDF-Extract-Kit and Zerox, plus the standalone OCR vision models that are quietly eating all of them. It is written for people who have to run ingestion on their own hardware, at volume, and then get the license past a review.

Three layers, and the one that collapsed

Every serious parser is built in three layers.

The first is the embedded text layer. Born-digital PDFs already carry glyph positions, and pulling them is nearly free: PyMuPDF and pdfplumber handle a page in single-digit milliseconds on a laptop CPU. The catch is that a PDF text layer has no concept of reading order, columns, captions, headers or table cells. It is a bag of positioned glyphs with a plausible-looking extract_text() method on top.

The second layer is layout detection: an object detector that labels regions as title, paragraph, list, table, figure, formula, header or footer, then sorts them into reading order. This is the layer that decides whether a two-column paper becomes coherent prose or interleaved nonsense.

The third layer is recognition of everything the text layer cannot supply: OCR for scanned pages, formula recognition for math, structure recognition for table grids.

The story of 2026 is that layers two and three have collapsed into a single vision-language model in most of the leading tools. Marker 2 routes layout, OCR and equations through Surya 2, a 650M-parameter VLM. MinerU ships VLM and hybrid backends alongside its classic pipeline. Docling added a --pipeline vlm path built on granite-docling-258M. The modular stack has not disappeared, but it is now the CPU fallback rather than the default.

What the benchmarks actually say

Two benchmarks matter. olmOCR-Bench from Ai2 covers roughly 1,400 documents and more than 7,000 unit-test style assertions, is released under ODC-BY, and is the one most parser authors now report. OmniDocBench v1.6 from OpenDataLab is the other, with heavier Chinese-language and scientific coverage.

Datalab published a head-to-head run on a single B200 alongside the Marker 2.0.0 release on 20 July 2026. Treat the throughput column as an upper bound you will never see on your own hardware, but the ordering holds.

Tool and mode	Engine	olmOCR-Bench	Pages/s on B200	GPU floor
Marker 2, balanced	Surya 2 VLM	76.0	2.9	NVIDIA GPU served by vLLM
Marker 2, fast	rf-detr layout detector	66.6	7.4	CPU viable
Marker 2, --disable_ocr	text layer only	43.6	23.7	CPU
MinerU 3.4, pipeline	DocLayout-YOLO + PP-OCRv6	72.7	0.54	4 GB VRAM
MinerU 3.4, vlm or hybrid	MinerU2.5 VLM	not in this run	not in this run	8 GB VRAM
Docling 2.116	RT-DETR + TableFormer	50.3	2.1	CPU viable
Surya 2 standalone	650M unified VLM	83.3	5 on an RTX 5090 at 96 DPI	consumer GPU
olmOCR 0.4	olmOCR-2-7B-1025-FP8	82.4	not in this run	12 GB VRAM
Chandra 2	Datalab OCR VLM	85.8	not in this run	not published
LiteParse, OCR disabled	Rust text-layer parser	20.4	1,721	CPU

Docling's 50.3 is the number that surprises people. It is real, and it is also not the whole story: restricted to born-digital PDFs, Docling scores 64.0 against 83.5 for Marker 2 and 83.3 for MinerU's pipeline. Docling is not trying to win an OCR benchmark. It is trying to emit a typed document object with a stable schema, and it is the only one of the three with an MIT license and Linux Foundation (LF AI and Data) governance behind it.

The pure VLM tier sits above all the pipeline tools. Chandra 2 from Datalab reports 85.8 plus or minus 0.8 on olmOCR-Bench, and Ai2's olmOCR 2 lands at 82.4 plus or minus 1.1. OmniDocBench v1.6, refreshed on 10 April 2026, ranks a different cut of the field: DeepSeek-OCR 2 at 90.25 and MonkeyOCR-pro-3B at 88.57, both at 3B parameters, with dots.ocr at 90.77, PaddleOCR-VL at 94.18 and MinerU2.5 at 93.04. Parameter count is not destiny: Dolphin-1.5 scores 86.52 at 0.3B. Now compare those with the vendor self-reports. PaddleOCR-VL-1.6, released 28 May 2026, claims 96.33 on that same benchmark, and MinerU's README claims 95.26 to 95.39 for its VLM and hybrid backends. Both sit roughly two points above where the public leaderboard puts them. Reproduce a number before you plan a quarter around it.

Layout detection is where pipelines break

If your extracted text reads fine but your retrieval is bad, layout is usually the culprit: a footnote fused into a body paragraph, a table caption orphaned two chunks away from its table, a running header repeated 400 times so it dominates your embedding space.

The classic approach is an object detector over a page raster. PDF-Extract-Kit is the reference implementation of that design and the ancestor of MinerU's pipeline backend: DocLayout-YOLO or LayoutLMv3 for regions, a fine-tuned YOLOv8 for formula detection, UniMERNet for formula recognition, PaddleOCR for text, and StructEqTable or StructTable-InternVL2-1B for tables. It is a model zoo with a config file, and it is genuinely useful if you want to swap one stage without adopting a whole framework. It is also effectively frozen: the last substantive release was v1.0 in October 2024. Use it as a component library, not as a maintained product.

Docling uses an RT-DETR layout model trained on DocLayNet plus TableFormer for table structure, which is why it is CPU-viable and why its layout labels are unusually consistent across document families. MinerU's pipeline backend adds two things most tools skip: cross-page table merging and automatic header and footer removal. Those two features alone are worth several points of downstream retrieval quality on long reports, and they are the reason MinerU keeps showing up in archive-scale jobs despite its poor per-page throughput.

Marker 2 offers both designs behind one flag. --mode fast uses a lightweight rf-detr detector and is tuned for CPU. --mode balanced hands the page to Surya 2 and gets roughly 9 points of olmOCR-Bench for roughly 2.5x the wall-clock cost.

Tables and formulas separate the tools

Text extraction is close to solved. Tables and math are not.

For born-digital documents with ruled tables, the boring tools still win on cost. Camelot reads lattice and stream tables directly from the PDF vector content and gives you a DataFrame without touching a GPU. If your corpus is financial filings with consistent ruling, benchmark that before you buy an H100.

For everything else, the difference is what the parser emits. MinerU converts tables to HTML and formulas to LaTeX, which is the right pair of choices: HTML survives rowspan and colspan, and LaTeX is what downstream models were trained on. It reports strong displayed-equation fidelity on scientific papers, which is the main reason it remains the default for arXiv-scale ingestion. Docling routes tables through TableFormer into a typed cell grid inside DoclingDocument, so you can query structure programmatically instead of regexing HTML. Marker 2 will give you markdown, JSON, HTML or pre-chunked output, and its --use_llm flag layers a hosted model (Gemini by default, with Claude, OpenAI, Vertex, Ollama and OpenRouter supported) over the VLM output for accuracy-critical documents.

Nougat deserves a mention as the model that proved academic PDF to markdown was tractable, but it has been superseded on every axis by the 2026 VLM generation and should not be a new project's starting point.

OCR fallbacks and when to trigger them

Every pipeline needs a decision rule for "this page has no usable text layer." The usual heuristic is characters per page below some threshold, or a text-layer-to-page-area ratio, evaluated per page rather than per document, because mixed corpora routinely contain a scanned appendix bolted onto a born-digital report.

The cheap fallback tier is still Tesseract, which reached 5.5.3 on 24 July 2026 and stays in steady maintenance rather than active model development, usually driven by OCRmyPDF, which wraps Ghostscript and Tesseract to produce searchable PDF/A with a sidecar text file. If your requirement is "make this archive greppable" rather than "make this archive chunkable," OCRmyPDF is the whole answer and it runs on a CPU:

ocrmypdf --skip-text --output-type pdfa \
  --sidecar page_text.txt input.pdf output.pdf

The middle tier is PaddleOCR. PP-OCRv6 landed on 11 June 2026 in PaddleOCR 3.7.0 and is a genuinely large jump for a lightweight detector-plus-recognizer stack, with one model covering Chinese, English, Japanese and 46 Latin-script languages. MinerU 3.4, released 18 June 2026, adopted PP-OCRv6 in its pipeline backend and reported roughly an 11 percent OCR accuracy gain on OmniDocBench v1.6 with about double the OCR throughput. Docling exposes OCR as optional extras, so you pick your engine at install time:

pip install "docling[tesserocr]"   # or [easyocr], [rapidocr]
pip install "docling[vlm]"         # required for the VLM pipeline
docling --pipeline vlm --vlm-model granite_docling report.pdf

The top tier is a document VLM doing OCR and layout in one pass. olmOCR is the cleanest option here for anyone who cares about licensing: Apache-2.0 on both code and weights, a documented 12 GB VRAM floor tested on RTX 4090, L40S, A100 and H100, and a published cost of under 200 USD per million pages converted. It runs on vLLM by default with allenai/olmOCR-2-7B-1025-FP8 and can point at any OpenAI-compatible endpoint.

pip install olmocr[gpu] --extra-index-url https://download.pytorch.org/whl/cu128
olmocr ./localworkspace --markdown --pdfs ./archive/*.pdf

DeepSeek-OCR is a 3B BF16 model under an MIT license, and neither the model card nor the repo publishes a VRAM floor, so size it from the weight files and your own token budget rather than from a figure in a blog post. MonkeyOCR ships smaller checkpoints alongside the 3B, which is what puts this tier within reach of consumer hardware at all, but the same caveat applies: measure it on your own card before you commit.

Zerox belongs in a category of its own: MIT-licensed, no local model at all, it renders each page to an image and asks a hosted vision model for markdown. It is 15 lines of glue you could write yourself, and that is the point. For a few thousand pages a month it is cheaper and faster to ship than any self-hosted stack. For a million pages, or for documents you are not allowed to send to a third party, it is the wrong tool.

pip install py-zerox   # needs poppler on the system
npm install zerox      # needs graphicsmagick and ghostscript

GPU budget, in pages rather than teraflops

Convert throughput to wall clock before choosing. Using the B200 numbers above and a one-million-page corpus on a single accelerator:

• MinerU pipeline at 0.54 pages/s: about 21 days
• Docling at 2.1 pages/s: about 5.5 days
• Marker 2 balanced at 2.9 pages/s: about 4 days
• Marker 2 fast at 7.4 pages/s: about 1.6 days
• Marker 2 with OCR disabled at 23.7 pages/s: about 12 hours

Those gaps are large enough to dominate the accuracy differences in cost terms. Marker 2 balanced beats MinerU's pipeline by 3.3 points of olmOCR-Bench and is roughly 5x faster, which is an unusually clean win. MinerU's answer is its VLM and hybrid backends, which its README reports at 95.26 to 95.39 on OmniDocBench v1.6 against 86.47 for the pipeline, at the cost of moving the VRAM floor from 4 GB to 8 GB and giving up CPU execution entirely.

Memory floors worth planning around: MinerU wants 16 GB of system RAM minimum and recommends 32 GB or more, plus about 20 GB of disk for weights, on Volta-or-newer NVIDIA hardware or Apple Silicon. olmOCR wants 12 GB VRAM and 30 GB of disk. Marker and Surya spawn a local inference server on first use, vLLM on NVIDIA and a llama.cpp path elsewhere, for which Datalab ships GGUF weights, and will reuse an existing one through SURYA_INFERENCE_URL, which matters if you are running several workers on one box.

Markdown or JSON is not a formatting question

Markdown is the wrong storage format and the right presentation format. Once you flatten a page to markdown you have thrown away page numbers, bounding boxes, block types and confidence, which are exactly the fields you need later for citations, for reranking by block type, and for debugging a bad chunk.

Persist structured output, render markdown at chunk time. Every serious tool supports this. Docling's DoclingDocument is the most complete version: a typed tree with provenance, exportable to markdown, HTML, JSON or DocTags, which is why it shows up as the ingestion layer inside larger frameworks even when a different model does the actual recognition. MinerU emits a reading-order-sorted JSON content list alongside its markdown. Marker 2 exposes --output_format json for a block tree with metadata and --output_format chunks if you want it to do the segmentation.

pip install marker-pdf
marker_single paper.pdf --mode balanced --output_format json
marker ./archive --mode fast --workers 8

Unstructured sits slightly to the side of this comparison. It is Apache-2.0, it partitions far more than PDFs, and partition_pdf(strategy="hi_res") gives you layout-aware elements with a consistent element taxonomy across every input type. Its per-page accuracy on hard PDFs is not competitive with the 2026 VLM tier, but if your corpus is 40 percent email and PowerPoint, a uniform element model across all of it is worth more than three points on a PDF benchmark.

Licensing traps

This is where teams lose weeks. Parsing tools have unusually messy licensing because the code and the weights are frequently licensed differently, and because the AGPL propagates through dependencies most people never read.

Tool	Code	Weights	The trap
Docling	MIT	Apache-2.0 (granite-docling)	none material
olmOCR	Apache-2.0	Apache-2.0	none material
Unstructured	Apache-2.0	varies by extra	hi_res pulls heavier transitive deps
Zerox	MIT	n/a	your documents leave your network
MinerU	MinerU Open Source License, Apache-2.0 base	same	commercial license required above 100M MAU or 20M USD monthly revenue, plus mandatory visible attribution if you offer it as a service
Marker 2	Apache-2.0	modified AI Pubs OpenRAIL-M	repo states free under 5M USD funding or revenue
Surya 2	Apache-2.0	modified AI Pubs OpenRAIL-M	same 5M USD line
Chandra 2	Apache-2.0	modified OpenRAIL-M	repo states 2M USD, plus a clause barring competitive use against their API
PDF-Extract-Kit	AGPL-3.0	model-specific	AGPL inherited through YOLO and PyMuPDF
PyMuPDF, pymupdf4llm	AGPL-3.0 or Artifex commercial	n/a	AGPL section 13 triggers on network use

Three things to internalize.

First, the Datalab family (Marker, Surya, Chandra) splits permissive code from restricted weights. Apache-2.0 on the repo tells you nothing about whether you can use the model. The revenue thresholds also differ between repos: Marker and Surya state 5M USD, Chandra states 2M USD. Read the actual license file in the version you pin, not a blog post about it.

Second, MinerU's thresholds are high enough that most teams will never hit them, but the attribution clause is not conditional on revenue. If you expose MinerU-backed parsing as a service to third parties, you have to say so visibly in the product or public docs, and non-compliance terminates the license automatically.

Third, AGPL is the one that bites, and it usually arrives through the back door. PyMuPDF is dual-licensed AGPL-3.0 or Artifex commercial, and pymupdf4llm depends on it. PDF-Extract-Kit is AGPL-3.0 specifically because of its YOLO and PyMuPDF dependencies. Because a RAG ingestion service is almost always network-accessible, AGPL section 13 applies to you even though you never distribute a binary. Audit the transitive dependency graph of whatever parser you pick, not just its top-level LICENSE.

Choosing by use case

Batch archives, millions of pages, quality-per-dollar. Marker 2 in fast mode, escalating to balanced only for pages that fail a quality gate (low character count, detected formula regions, or a low-confidence layout). The two-tier routing is where the actual savings are: most archives are 80 percent boring text pages that never need a VLM. Budget for the OpenRAIL-M weights license if you are above the revenue threshold.

Scanned and handwritten documents. Chandra 2 if the OpenRAIL-M terms work for you, olmOCR if they do not and you need Apache-2.0 end to end. Both are large jumps over the Tesseract tier on degraded scans. Keep OCRmyPDF in the pipeline anyway as the artifact producer: a searchable PDF/A is a deliverable, and a markdown file is not.

Scientific PDFs with dense math. MinerU, VLM or hybrid backend. It converts formulas to LaTeX rather than mangling them into unicode, merges tables across page breaks, and strips journal running heads. If you need to swap in a different formula recognizer, PDF-Extract-Kit gives you the UniMERNet stage as a standalone component.

Low latency, interactive, one document at a time. Docling. It is MIT, it runs acceptably on a CPU, it starts fast because there is no VLM server to warm, and its typed output plugs straight into a chunker. Accept that you are trading roughly 25 points of olmOCR-Bench for that, and gate the hard documents to a VLM path.

Small volume, no infrastructure, permissive license. Zerox. Accept the data egress or do not use it.

What to watch next

The most interesting development is not a better parser but the argument that you should not parse at all for retrieval. ColPali established that late-interaction embeddings over rendered page patches beat text-based RAG on visually dense documents with no OCR anywhere in the loop, and ColQwen2 has since become the practical default on ViDoRe. That does not remove the need for parsing (you still need text to put in a model's context and to cite), but it does change the architecture: retrieve visually, parse only the handful of pages you actually retrieved. That inverts the cost model completely, because you stop paying VLM inference on the 99 percent of pages nobody ever queries.

The second thing to watch is benchmark hygiene. The highest numbers quoted anywhere in this space are self-reported by the model's authors on their own harness, and they sit consistently above what the public OmniDocBench leaderboard gives the same models. Before you switch parsers on a leaderboard delta, run 200 pages of your own corpus through both and diff the output. It takes an afternoon and it is the only benchmark that describes your documents.