Document understanding with TableFormer, pluggable OCR, DoclingDocument JSON and local-first MIT licensing. Slower than raw extractors, heavier install (~500 MB models). Install →
Docling vs Alternatives
No universal winner — only the right fit for your documents, hardware, license and RAG stack. TL;DR below, proof in the matrix.
Verified with Docling v2.129.0 · Last checked 2026-09-22 · Independent, no paid placement.
Mixed PDFs for local RAG → Docling. Papers, math & CJK on GPU → MinerU. Multi-format enterprise ETL → Unstructured. Millions of clean digital PDFs at max speed → PyMuPDF (+ pdfplumber for grid tables). Books and scanned prose → Marker. Zero-infra managed parsing → LlamaParse. Honest trade-offs below.
Who should pick what?
Broadest format coverage (60+) with partition + chunk_by_title and a paid cloud API. hi_res quality costs setup and GPU; best features drift to commercial tiers.
Fastest text extraction (~0.01 s/page) and precise grid tables. No layout model, no OCR, AGPL terms on PyMuPDF — silent empty output on scans.
Beautiful Markdown for books and papers with Surya 2 + LaTeX math. Marker 2 runs CPU-ok in fast mode and best on GPU; Apache-2.0 code with a weight cap — weak on borderless business tables.
Layout SOTA with DocLayout-YOLO, UniMERNet LaTeX formulas and best-in-class CJK. GPU needed, heavy install, Apache-based license with commercial thresholds — the pick for papers and math.
Three questions, one starting point
Answer three questions — get a starting recommendation. Then confirm it in the matrix.
The full comparison matrix
Grouped by what buyers actually ask. Hover the ? for definitions; every tool name links to its official docs. Filter and differences toggle cut the noise.
| Capability | Docling | Unstructured | PyMuPDF / pdfplumber | Marker | MinerU |
|---|---|---|---|---|---|
| Document understandingWhether the tool reconstructs reading order, layout and tables — or just dumps text. | |||||
| Layout & reading order ? | Yes | Partial (hi_res) | No | Yes | Yes (DocLayout-YOLO) |
| Table structure ? | Yes (TableFormer) | Partial / paid tiers | Basic grid | Yes | Yes (TableMaster + merge) |
| Formulas & math ? | Enrichment pass | Partial | No | Yes (Surya 2) | Best (UniMERNet LaTeX) |
| Multi-column handling ? | Yes | Partial | No | Best-in-class | Yes |
| Header / footer removal ? | Yes | Yes | Manual | Partial | Yes (auto) |
| Text extraction & OCRDigital PDFs need fast extraction; scans need OCR. No single engine wins both. | |||||
| Native text speed ? | Medium (~0.3–3 s/pg) | Fast / hi_res medium | Fastest (~0.01 s/pg) | Fast (CPU ok) | Slow (GPU-bound) |
| Scanned-document OCR ? | Yes (pluggable) | Yes | No (needs Tesseract) | Yes (Surya 2) | Yes (PaddleOCR) |
| OCR engine choice ? | 6+ engines | Tesseract / Paddle | External only | Built-in (Surya 2) | Built-in (PP-OCRv6) |
| CJK & complex scripts ? | Good | Good | Basic | Good | Best-in-class |
| Inputs & outputsWhat goes in (formats) and what comes out for LLMs (Markdown, JSON, chunks). | |||||
| Input formats ? | 20+ formats | 60+ formats | PDF-centric | PDF + books | PDF + Office + EPUB |
| Markdown output ? | Yes | Yes | Via pymupdf4llm | Yes | Yes |
| Structured JSON ? | Yes (DoclingDocument) | Yes (Elements) | No | Partial | Yes (content list) |
| Chunk-ready structure ? | Yes | Yes (chunk_by_title) | No | Yes (--output chunks) | Partial |
| Deploy & operationsWhere it runs, what hardware it needs, and what it costs to operate. | |||||
| Local / offline execution ? | Yes | Partial (API push) | Yes | Yes | Yes |
| Hardware needs ? | CPU ok, GPU faster | CPU ok, GPU for hi_res | CPU only | CPU ok, GPU for best | GPU needed (4–8 GB) |
| Install weight ? | ~500 MB models | Heavy (Detectron2) | Light (~20 MB) | Medium–heavy | Heavy |
| License ? | MIT | Apache 2.0 + commercial | PyMuPDF: AGPL / pdfplumber: MIT | Apache-2.0 + weight cap | Apache-based + thresholds |
| AI / RAG fitFramework connectors, agents and multimodal inputs for production RAG. | |||||
| RAG integrations ? | Yes | Yes | No | Partial | Partial |
| Agent / MCP server ? | Yes | No | No | No | No |
| Audio / video (ASR) ? | Yes | No | No | No | No |
| Cloud API option ? | Self-host | Yes (paid) | No | Yes (Datalab API) | No (opt-in remote) |
| Cost & trustPrice per page, governance and how to verify claims yourself. | |||||
| Self-host cost ? | Free (MIT) | Free OSS / paid API | Free / licence terms apply | Free within weight cap | Free within thresholds |
| Governance ? | Linux Foundation AI | Unstructured.io | MuPDF / community | Datalab | OpenDataLab / SAI Lab |
| Best for ? | Accurate local RAG | Multi-format ETL | Fast text extract | Books & papers | Papers, math & CJK |
Orientation, not a benchmark. Accuracy figures come from independent 200–500 PDF studies — see Method. Always re-verify against official docs; versions move fast.
Honest one-on-ones
Where Docling wins, where it loses, and the exact moment to switch.
Docling vs Unstructured
Official docsRule of thumb: Local RAG from PDFs → Docling. Heterogeneous enterprise ETL (SharePoint, S3, 60+ formats) → Unstructured.
Strengths (Unstructured)
- 60+ input formats and cloud connectors
- chunk_by_title for structure-aware chunking
- Managed API with orchestration
Limits
- hi_res needs Detectron2/GPU and setup
- Best features drift to paid tiers
- Local OSS trails the cloud API
Verdict: PDF-first RAG in your own hands? Docling. Format zoo with managed ops? Unstructured — budget for the API.
Docling vs PyMuPDF / pdfplumber
Official docsRule of thumb: Known-clean digital PDFs at volume → PyMuPDF. Everything else → put Docling in front.
Strengths (PyMuPDF)
- ~0.01 s/page — 10–50× faster than ML pipelines
- Minimal install, runs anywhere
- pdfplumber shines on grid tables
Limits
- No layout model, no reading order
- No OCR — silent empty output on scans
- Watch PyMuPDF AGPL terms
Verdict: Speed is everything and PDFs are clean? PyMuPDF. As soon as tables, columns or scans appear, Docling earns its keep.
Docling vs Marker
Official repoRule of thumb: Business tables on local CPU → Docling. Books and scanned prose, CPU-ok or GPU → Marker 2.
Strengths (Marker)
- Best reading order in multi-column layouts
- Surya 2 OCR + LaTeX math
- Clean Markdown for books; fast mode runs on CPU
Limits
- Best quality still wants a GPU (balanced mode)
- Medium–heavy install
- Apache-2.0 code but weights capped (~$5M); weak on borderless tables
Verdict: Independent 200-PDF benchmarks put Docling ahead on tables (TEDS ~0.89 vs ~0.81) and Marker ahead on reading order. Your use case decides.
Docling vs MinerU
Official repoRule of thumb: Business tables on local CPU → Docling. Papers, math and CJK on GPU → MinerU.
Strengths (MinerU)
- Layout SOTA (97.5 mAP claimed) with DocLayout-YOLO
- UniMERNet LaTeX formulas; cross-page table merge
- Best-in-class CJK support
Limits
- GPU needed (4–8 GB VRAM); slow pipeline per page
- Heavy install; tables emit as HTML
- Apache-based license with commercial thresholds + attribution duties
Verdict: MinerU leads on layout and formulas, Docling on the typed document model, CPU-friendliness and license simplicity. Route by corpus: papers to MinerU, business docs to Docling.
Docling vs MarkItDown
Official repoRule of thumb: Simple digital PDFs + Office mix in constrained envs → MarkItDown. Structure, tables or OCR → Docling.
Strengths (MarkItDown)
- MIT, ~80 MB, sub-second per document
- Huge format tail (Office, HTML, audio, EPUB)
- Optional Azure Document Intelligence OCR backend
Limits
- pdfminer core: no layout model, tables break
- Columns interleave; no OCR by default
- OCR paths need an LLM plugin or paid Azure pages
Verdict: Keep MarkItDown around for the Office/fast path — it is a converter, not a document-understanding replacement.
Docling vs LlamaParse
Official docsRule of thumb: LlamaIndex stack, non-sensitive docs, modest volume → LlamaParse. Confidential, offline or high-volume → self-host Docling.
Strengths (LlamaParse)
- Tiered modes (Fast to Agentic Plus) with version pinning
- Strong messy-layout accuracy; generous free tier
- Zero infra; native LlamaIndex integration
Limits
- Per-page bill (~$0.003–0.01); scales linearly
- Data leaves the building; closed source
- SDK migration in progress; no public bench transparency
Verdict: Pay for convenience, not exclusivity — 2026 benchmarks show small open VLM parsers matching hosted quality on a single GPU. Mistral OCR, Reducto, Extend and hyperscaler APIs (Azure, Textract, Google) play the same managed lane: compare per-page cost, egress and lock-in.
Same job, four tools
PDF → Markdown in each tool. Copy, run, feel the setup and output difference.
docling convert report.pdf --to md --ocr-engine rapidocrLocal pipeline with layout + tables + OCR in one command.
from unstructured.partition.pdf import partition_pdf
elements = partition_pdf('report.pdf', strategy='hi_res')hi_res needs layout models; the fast strategy scores far lower.
import fitz
doc = fitz.open('report.pdf')
text = '\n'.join(p.get_text() for p in doc)Blazing fast — but silent empty output on scanned pages.
marker_single report.pdf --output_dir out/Marker 2 fast mode runs CPU-ok; best quality on GPU.
mineru -p report.pdf -o ./outNeeds a GPU; tables land as HTML, formulas as LaTeX.
markitdown report.pdf -o report.mdSub-second and tiny — but no layout model and no OCR by default.
How this page is built
Sources: official docs (Docling, Unstructured, PyMuPDF, Marker repo) plus independent benchmarks — a 200-PDF comparison (table TEDS, reading order) and a 500-PDF enterprise study (tables, columns, OCR, speed). Key findings: Docling leads on tables (~97.9% / TEDS ~0.89), Marker on reading order and GPU speed, PyMuPDF on raw speed.
Honesty rules: no paid placement, rival strengths named, version (Docling v2.129.0, Last checked 2026-09-22) shown at the top. Licenses re-checked in 2026: Marker 2 code is Apache-2.0 (weights capped), MinerU moved to an Apache-based license with commercial thresholds. Corrections via GitHub — re-checked against official sources.
For OCR-engine choices specifically, see the OCR explorer.