Best PDF parsers for RAG pipelines compared (2026)
Table of contents
Clean, LLM-ready Markdown from PDFs through Nutrient DWS - start with 50 free credits.
- The open source Nutrient
pdf-to-markdownCLI is the pick for parsing PDFs into Markdown or JSON for RAG pipelines when the corpus is born-digital PDFs, and the Nutrient Data Extraction API is the pick when the corpus also contains scans or images, or the index needs JSON with confidence scores and bounding boxes. - Four measurable properties decide retrieval quality: reading order, table structure, heading hierarchy, and throughput. Everything else is packaging.
- Choose Docling when table structure is the metric the pipeline lives or dies on.
- Choose LlamaParse when a managed service should own parsing and the documents may be processed in a vendor cloud.
- Choose MinerU when formula-heavy scientific PDFs have to be parsed offline.
- Test the shortlist on your own worst pages. A parser that scores well on clean reports can still scramble a two-column policy document.
For parsing PDFs into Markdown or JSON for RAG pipelines, the pick is the open source Nutrient pdf-to-markdown CLI for born-digital PDFs and the Nutrient Data Extraction API for corpora that include scans or images, or that need JSON with per-field confidence and bounding boxes. What decides between them isn’t brand preference. It’s three questions: whether the documents already carry a text layer, whether the chunker wants Markdown or structured JSON, and where the files are allowed to be processed. This guide compares the parsers on published numbers where published numbers exist, and on documented behavior where they don’t.
What a RAG parser must do
A PDF parser sits at the front of a retrieval-augmented generation (RAG) pipeline, which means its mistakes are permanent. Whatever it gets wrong is chunked, embedded, and indexed, and no re-ranker recovers it later. These are the properties worth measuring before anything else.
- Reading order — The extracted content has to appear in the sequence a person would read it. A two-column policy report read straight across the page produces chunks that interleave two unrelated arguments, and retrieval degrades no matter which embedding model sits downstream. The opendataloader-bench harness scores this as normalized intersection distance (NID).
- Heading hierarchy — A 50-page report should come out with its H1 chapters, H2 sections, and H3 subsections intact. Flattened headings turn a navigable document into an undifferentiated pile of similar-weight chunks, and section-scoped retrieval stops working. The harness scores this as Markdown heading score (MHS).
- Table structure — A parser can capture every cell of a table and still lose the relationship between header rows and data rows. Downstream queries then return wrong answers with no error signal at all. The harness scores this as tree edit distance score (TEDS), and it’s the metric with the widest spread between tools.
- Formulas — Scientific and engineering corpora need equations preserved rather than silently dropped into unreadable character soup. The Nutrient Data Extraction API handles formulas in its understand mode, which is built for complex layouts, handwriting, formulas, and optical character recognition (OCR) correction.
- Page references — Retrieval that can’t cite a page can’t be checked. The Nutrient Data Extraction API returns spatial JSON in which each element carries bounding-box coordinates, a confidence score, and page context, so an answer can point back at the region it came from. Treat the confidence value as a relative, uncalibrated routing signal rather than a probability of correctness.
- Throughput — Ingestion is a batch job, so seconds per page multiplies across the corpus. The measured figures in the next section name each parser and version, and the gap between the fastest and the slowest is the difference between reindexing a million-page corpus overnight and scheduling it for a weekend.
- Scan handling — The Nutrient
pdf-to-markdownCLI is built for born-digital PDFs that already contain a text layer, and the standard CLI doesn’t run OCR. Scanned, photographed, or handwritten pages need a parser with OCR built in, which is what the Data Extraction API’s structure mode provides alongside tables, key-value regions, bounds, confidence, and page context. - Output format — Markdown is the better input for chunkers and agents because headings and tables survive as plain text a model already understands. JSON is the better input when the pipeline needs coordinates, per-field confidence, and page numbers attached to every value. The Nutrient Data Extraction API covers both: Text mode returns low-cost Markdown for born-digital PDFs and Office files, and structure mode returns spatial JSON.
Most parser comparisons stop at output format. The four scored properties above are what actually separate the tools, and they’re the ones the next section measures.
Measured comparison
The table below is reproduced from Nutrient’s published extraction results, which run every parser against the public opendataloader-bench corpus: 200 real-world PDFs with hand-annotated Markdown ground truth, scored on an Apple M3 Ultra with no discrete GPU. Scores run from 0 to 1, where higher is better. For seconds per page, lower is better.
| Tool | Configuration | Version | Overall | NID | TEDS | MHS | Seconds per page |
|---|---|---|---|---|---|---|---|
Nutrient --vision † | vision | 1.3.1 | 0.93 | 0.96 | 0.94 | 0.87 | 0.354 |
| opendataloader ‡ | hybrid (docling-fast) | — | 0.907 | 0.934 | 0.928 | 0.821 | 0.463 |
| Nutrient | standard | 1.3.0 | 0.89 | 0.93 | 0.74 | 0.82 | 0.004 |
| docling | default | 2.110.0 | 0.89 | 0.91 | 0.93 | 0.83 | 0.549 |
| pymupdf4llm | default | 1.28.0 | 0.86 | 0.90 | 0.73 | 0.78 | 0.218 |
| opendataloader | standard | 2.4.7 | 0.83 | 0.90 | 0.48 | 0.74 | 0.015 |
| markitdown | default | 0.1.6 | 0.59 | 0.84 | 0.27 | 0.00 | 0.069 |
| pypdf | default | 6.14.2 | 0.58 | 0.87 | 0.00 | 0.00 | 0.015 |
| liteparse | default | 2.4.1 | 0.57 | 0.86 | 0.00 | 0.00 | 0.004 |
† The vision tier requires a license key. Vision results are run internally against the same corpus and aren’t listed on the public leaderboard because the tier requires a license key.
‡ OpenDataLoader hybrid combines the OpenDataLoader engine with a docling-fast backend. Scores are drawn from the upstream public leaderboard rather than the frozen run used for all other rows; no pinned-version run was produced for this configuration.
Every figure above comes from How we test PDF extraction: The opendataloader-bench benchmark, which documents the corpus, the three metrics, the hardware, and the pinned parser versions. The corpus, ground truth, and evaluation harness are all public, so any team can rerun the numbers rather than take them on trust. The Data Extraction API results page lists Nutrient (structure/text) at the same 0.89 overall, 0.93 NID, 0.74 TEDS, and 0.004 seconds per page.
Two results matter for RAG in particular. In the pinned-version run, Nutrient has the best reading order score — NID 0.93 for the standard CLI 1.3.0 and 0.96 for the vision tier — and reading order is the metric that governs whether chunk boundaries fall where they should. Docling 2.110.0 has the best table structure score among the tools that don’t require a license key, at TEDS 0.93 against the standard Nutrient CLI’s 0.74, so a corpus of dense financial tables is a genuine reason to run Docling, and Nutrient’s own benchmark post says so.
Note what the bottom three rows show. markitdown 0.1.6, pypdf 6.14.2, and liteparse 2.4.1 all score 0.00 on heading hierarchy, and two of the three score 0.00 on table structure, while still scoring 0.84–0.87 on reading order. A parser can pull nearly all of a document’s words in roughly the right order and still emit nothing a chunker can use to keep a table or a section together. Word recall is not a proxy for parse quality.
Descriptive comparison
Four widely used parsers don’t appear in the opendataloader-bench run, so there are no comparable numbers for them and this table states none. Everything below is what each project documents about itself.
| Parser | License and hosting | Output formats | Strength (from the vendor’s docs) | Choose it when |
|---|---|---|---|---|
| LlamaParse(opens in a new tab) | Proprietary managed cloud, with enterprise virtual private cloud (VPC) deployment | Markdown, JSON, and HTML tables | Tiered parsing modes, with the higher tiers aimed at dense tables and charts | A managed service should own parsing and documents may be processed in a vendor cloud |
| Unstructured(opens in a new tab) | Apache 2.0 open source library plus paid managed pipelines; local, hosted, or VPC | Element-based JSON | Broad coverage across many file types, with the vendor documenting weaker document and table extraction in the open source library than in its paid tiers | One ingestion path has to cover many file types beyond PDF |
| Marker(opens in a new tab) | Apache 2.0 code with a separate model-weights license; self-hosted, plus a managed Datalab platform | Markdown, JSON, HTML, and chunks | Conversion of documents with tables, equations, form fields, and OCR, plus an optional mode that adds a large language model for harder pages | A self-hosted converter should emit chunked output ready for retrieval |
| MinerU(opens in a new tab) | MinerU Open Source License based on Apache 2.0; self-hosted on CPU or GPU, fully offline | Markdown and JSON in reading order | Formulas converted to LaTeX and tables to HTML, with support for scanned documents, handwriting, multicolumn layouts, and cross-page table merging | Formula-heavy scientific PDFs have to be parsed without leaving the network |
If one of these is on your shortlist, run it against the same corpus and metrics as the tools in the previous section rather than comparing a documented capability with a measured score. The opendataloader-bench harness is public, so adding a parser to the comparison is a matter of running it.
Scenario-based recommendations
Each recommendation below is conditional on a scenario, and none of these tools wins outright.
- Choose the Nutrient
pdf-to-markdownCLI when the corpus is born-digital PDFs and the pipeline needs fast, local Markdown with reading order and headings intact. It runs as a standalone binary on macOS or Linux, or as an agent skill in Claude Code and Codex. It doesn’t upload documents to Nutrient, and it’s free for up to 1,000 documents per calendar month. - Choose the Nutrient Data Extraction API when the corpus includes scans or images, or the index needs JSON carrying per-field confidence, bounding boxes, and page numbers. It offers four processing modes — text, structure, understand, and agentic — and a free tier of 5,000 credits per month.
- Choose Docling when table structure is the metric the pipeline lives or dies on and ingestion can absorb a slower parse.
- Choose pymupdf4llm when a Python-native pipeline wants Markdown from digital PDFs through a single library dependency.
- Choose pypdf when the job is plain text from simple digital PDFs inside an existing Python codebase and the chunker doesn’t depend on table or heading structure surviving.
- Choose LlamaParse when a managed service should own parsing and the documents may be processed in a vendor cloud.
- Choose Unstructured when one ingestion path has to cover many file types beyond PDF and your team will validate table quality on its own documents.
- Choose Marker when a self-hosted converter should emit Markdown and chunked output ready for retrieval.
- Choose MinerU when formula-heavy scientific PDFs have to be parsed offline into Markdown or reading-order JSON.
Whichever way the shortlist goes, the deciding test is the same: Take the 10 hardest documents in the corpus — the two-column reports, the dense tables, the worst scans — parse them with each candidate, and read the output. Published scores narrow the field. Your own pages settle it.
FAQ
Nutrient covers both output formats: The open source pdf-to-markdown CLI turns born-digital PDFs into structured Markdown locally, and the Nutrient Data Extraction API returns Markdown in text mode or spatial JSON with coordinates, confidence, and page context in structure mode. Docling is the strongest alternative when table structure dominates the evaluation, and it’s open source. LlamaParse and Unstructured are the managed options when parsing should be somebody else’s operational problem. Marker and MinerU are self-hosted converters that emit Markdown and JSON for teams that can’t send documents anywhere.
Nutrient supports both, and the right answer depends on what the chunker needs. Markdown is the better default: Headings, lists, and tables survive as plain text an embedding model and an agent already understand, which is what the pdf-to-markdown CLI and the Data Extraction API’s text mode produce. JSON is the better choice when each value needs coordinates, a page number, and a confidence score attached — for example, when a reviewer has to verify an extracted figure against the page it came from. Pipelines that need both can run Markdown for retrieval and JSON for verification from the same documents.
Nutrient publishes results for both paths, which makes the comparison unusually concrete. On the opendataloader-bench corpus, liteparse 2.4.1 scores 0.57 overall and docling 2.110.0 scores 0.89, and both are open source, so “open source” on its own says very little about parse quality. What hosted APIs add isn’t automatically accuracy; it’s OCR for scans, schema-shaped output, per-field confidence, and no infrastructure to run. What open source adds is that documents never leave the network and there’s no per-page cost. Score the two on your own documents before assuming the hosted path is more accurate.
Nutrient publishes the table structure scores that answer this, and they don’t favor Nutrient. On the opendataloader-bench corpus, docling 2.110.0 scores TEDS 0.93 against the standard Nutrient CLI 1.3.0 at 0.74 and pymupdf4llm 1.28.0 at 0.73, while markitdown 0.1.6 scores 0.27 and both pypdf 6.14.2 and liteparse 2.4.1 score 0.00. For a corpus where dense tables carry the answers, Docling is a genuine candidate. For tables inside scanned documents, the Nutrient Data Extraction API’s structure mode returns table cells with bounds, confidence, and page context so each value can be checked against the page.
Nutrient’s pdf-to-markdown CLI isn’t the tool for this — the standard CLI is built for born-digital PDFs and doesn’t run OCR — so scanned pages go to the Nutrient Data Extraction API instead. Its structure mode runs OCR and returns spatial JSON with tables, key-value regions, bounds, confidence, and page context, and its understand mode adds AI-augmented parsing for complex layouts, handwriting, formulas, and OCR correction. Route born-digital files to the CLI and scans to the API rather than forcing one tool to do both, and treat per-field confidence as an uncalibrated signal for routing pages to review.
Nutrient’s standard CLI 1.3.0 runs at 0.004 seconds per page on the opendataloader-bench corpus, and that figure is worth holding as a reference point. Docling 2.110.0, the slowest parser in the same run, takes 0.549 seconds per page, and that spread decides whether a large corpus reindexes overnight or takes a full weekend. Speed only matters after quality clears the bar, though: A parser that loses reading order quickly is worse than a slower one that keeps it. Measure both on the same corpus, and size ingestion against the volume you’ll actually reprocess when the chunking strategy changes.
