PDF to Markdown Locally: 4 Converters Compared

Short answer: Marker or MinerU if you have an NVIDIA GPU and messy real-world PDFs; Docling if you are CPU-only, air-gapped, or feeding a mixed pile of Office files; MarkItDown only when the PDFs are simple and you want six dependencies instead of PyTorch. All four are actively maintained — every one of them shipped a release to PyPI within the month before this page was written, the most recent on 17 August 2026 — and all four are free to run locally. The differences that decide your pipeline are layout fidelity, whether a GPU is available, and two licence clauses most people never read.

Versions this page was verified against, on 18 August 2026: Docling 2.120.2, MinerU 3.4.5, MarkItDown 0.1.7, marker-pdf 2.0.0. All four move weekly. Pin your versions.

---

Pick One in 30 Seconds

If you only read one table, read this one.

---

Why Your Current Loader Broke

Almost every "my RAG retrieves nonsense" ticket traces back to one of four PDF failures, and none of them are the embedding model's fault.

1. Two-column reading order. A naive text extractor walks the PDF content stream, which is drawing order, not reading order. On an academic paper that interleaves the left and right columns line by line. Your chunks end up as alternating half-sentences from two different arguments, and no embedding model can rescue that.
2. Table structure collapse. A PDF table is not a table — it is positioned text plus, sometimes, some lines. Flatten it and "Revenue 2024 1,204 2025 1,388" becomes a single unlabelled string. Retrieval then answers the wrong year with total confidence.
3. Equations to gibberish. Math is glyphs from a symbol font. Extract naively and you get mojibake; you need a model that recognises the region as math and emits LaTeX.
4. Scanned pages returning nothing. No text layer, no text. The worst version of this failure is the silent one — the loader returns an empty string, the chunk is indexed as empty, and nothing errors.

A converter that handles all four is doing document understanding, not text extraction. That is why three of these four tools ship models and one does not.

If your problem is upstream of this — chunking strategy, embedding choice, retrieval scoring — fix that first with our local RAG setup guide. A perfect parser will not save a badly chunked index.

---

The Four Tools, Verified

Every command below is from the project's own README, checked against the version named.

Docling 2.120.2 — the flexible, MIT one

Docling is IBM's document-conversion pipeline and the most modular of the four. Its README lists advanced PDF understanding including "page layout, reading order, table structure, code, formulas, image classification", extensive OCR support for scanned PDFs and images, local execution for sensitive data and air-gapped environments, an ASR path for audio, video parsing, chart understanding, and a service mode via docling-serve.

pip install docling

# CLI — accepts a local path or a URL
docling https://arxiv.org/pdf/2206.01062

# Or run the GraniteDocling 258M VLM pipeline instead
docling --pipeline vlm --vlm-model granite_docling https://arxiv.org/pdf/2206.01062

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # local path or URL
converter = DocumentConverter()
result = converter.convert(source)
print(result.document.export_to_markdown())

The install story is better than its reputation suggests. On PyPI, docling 2.120.2 is a metapackage that pulls docling-slim[standard], and docling-slim declares just eight core dependencies (certifi, docling-core, filetype, pluggy, pydantic, pydantic-settings, requests, tqdm). Everything else sits behind named extras on the docling package itself — pip install docling[easyocr] and friends, the full set being easyocr, rapidocr, tesserocr, ocrmac, onnxruntime, vlm, remote-serving, asr, htmlrender and xbrl. That extras list is the real selling point — you choose the OCR engine, including Apple's native one on macOS, instead of accepting whatever the tool bundled. Licence: MIT. Python 3.10+.

MinerU 3.4.5 — two backends, one CLI

MinerU converts PDF, images, DOCX, PPTX and XLSX to Markdown or JSON with what its README calls a "VLM + OCR dual engine" and 109-language OCR. The two backends are the point:

pip install --upgrade pip
pip install uv
uv pip install -U "mineru[all]"

# GPU path
mineru -p <input_path> -o <output_path>

# Pure CPU path
mineru -p <input_path> -o <output_path> -b pipeline

Stated system requirements from the same table: 16GB RAM minimum, 32GB recommended; 20GB disk minimum, SSD recommended; Python 3.10-3.13. GPU acceleration requires "Volta and later architecture GPUs or Apple Silicon" — note that floor if you are running older hardware, and see our Pascal GPU guide if your card is a GTX 10-series. On Windows, only Python 3.10-3.12 works because the ray dependency has no 3.13 Windows build.

Recent release notes worth knowing: the 3.4 line upgraded the pipeline backend's OCR model to PP-OCRv6, which the project reports as roughly an 11% OCR accuracy improvement on OmniDocBench v1.6 and about a 100% speed increase in OCR processing. Both are the project's own figures.

MarkItDown 0.1.7 — the thin one, and that is the point

MarkItDown is Microsoft's lightweight converter, and it is honest about its scope. Its README: it is "most comparable to textract, but with a focus on preserving important document structure and content as Markdown", and the output "is meant to be consumed by text analysis tools -- and may not be the best option for high-fidelity document conversions for human consumption."

pip install 'markitdown[all]'
# or only what you need:
pip install 'markitdown[pdf, docx, pptx]'

markitdown path-to-file.pdf > document.md
markitdown path-to-file.pdf -o document.md
cat path-to-file.pdf | markitdown

Six non-optional dependencies. A ~70KB wheel. No models, no downloads, no CUDA. For DOCX, PPTX, XLSX, HTML and simple born-digital PDFs it is genuinely the right answer — instant install, instant conversion, nothing to maintain. For a two-column paper full of tables it is the wrong answer, and no configuration changes that.

One trap. The markitdown-ocr plugin adds OCR by calling an LLM vision model through the standard llm_client / llm_model pattern, so it is only local if you point it at a local OpenAI-compatible server. And per its own docs, if no llm_client is provided "the plugin still loads, but OCR is silently skipped" — a silent skip, not an error. In a batch job that is how you get a thousand empty chunks.

marker-pdf 2.0.0 — text-layer-first, VLM where needed

Marker reads the PDF text layer and calls a vision model selectively, which is why it can be both accurate and fast. Its README says it "works on GPU, CPU, or MPS", with modes that default by device: balanced on GPU, fast on CPU and MPS.

pip install marker-pdf
# non-PDF inputs need the extras:
pip install marker-pdf[full]

marker_single /path/to/file.pdf
marker /folder --output_dir out
marker /folder --output_dir out --mode fast --disable_ocr   # pure CPU, no VLM

The mode flags are the whole product:

• balanced (GPU default) — surya VLM for layout, OCRs inline math, and re-OCRs the whole page whenever any embedded text is bad.
• fast — layout plus text-layer path, much cheaper.
• --disable_ocr — never calls the VLM; pure text-layer extraction, and the README is clear that "equations and scanned pages are skipped".

Deployment note that catches people out: the surya inference server auto-spawns on first use and needs vLLM (with Docker plus the NVIDIA Container Toolkit) on NVIDIA GPUs, or a llama.cpp llama-server binary on CPU and Apple Silicon. Marker is the heaviest of the four to stand up, and the only one whose "install" includes a container runtime on the GPU path. Its declared dependency list includes torch and transformers, so budget for a multi-gigabyte environment.

---

What the Published Benchmarks Say

Read this section as two vendors' claims, not as a referee's scoreboard. We did not run our own five-document corpus for this page, and we are not going to present numbers we did not measure as if we had.

Marker's repository publishes an olmocr-bench comparison — 1,403 PDFs, roughly 8,400 pass/fail unit tests across math, tables, reading order, headers/footers and old scans, scored with the official olmocr-bench checker, throughput measured as sustained concurrent pages/sec on one B200 host:

MinerU's repository publishes a different benchmark — OmniDocBench v1.6 end-to-end overall — where its pipeline backend scores 86.47 and its VLM backend 95.39 on the high-accuracy setting, 95.26 on medium.

Four caveats that matter more than the numbers:

• Both tables are self-reported by the tool being compared. Marker's table is in Marker's repo; MinerU's is in MinerU's. Neither is independent, and the two use different benchmarks and metrics, so the scores cannot be placed in one column.
• Marker's table compares MinerU's pipeline backend, not its VLM backend. Marker's own text acknowledges that "MinerU's own VLM backend scores higher but is a different, full-page-VLM approach". That is a fair comparison of like with like, and also the reason the comparison understates MinerU's ceiling.
• A B200 is not your laptop. The throughput column is sustained concurrent pages/sec on datacentre hardware; nothing in it predicts what a 12GB consumer card will do.
• Docling's 50.3 is a default-configuration score. Docling's pluggable OCR backends and VLM pipeline are not what was run.

The one number in that table we would treat as genuinely decision-shaping is the 43.6 vs 76.0 gap between CPU no-OCR and GPU balanced mode in the same tool. That is a clean internal comparison, and it is the honest price of not having a GPU.

---

Hardware and Install Weight

The real selection criterion for most people is not accuracy — it is whether the thing installs and runs on the box you have.

Dependency counts are from each package's declared non-optional requirements on PyPI for the version named; disk and RAM figures are only listed where the project states them, because a number we did not measure and the project did not publish would be an invention. If you want to know whether a given model fits your card before you install anything, our VRAM calculator does that arithmetic.

---

Licences: The Trap Nobody Reads

Two of these four split the code licence from the model licence, and that is where commercial projects get caught.

We are summarising, not advising. Read both licence texts before you put either in a shipping product, and if revenue thresholds apply to you, get it in writing.

---

Test It on Your Own Corpus

Twenty of your own pages beats any benchmark on the internet, including the two quoted above. Here is the version of the test that takes an afternoon.

Build a five-document set that mirrors your real corpus: a two-column paper, a table-heavy report, a slide deck, a scanned page, and whatever your weirdest recurring format is. Then:

# one document, four tools, four outputs
markitdown sample.pdf -o out/markitdown.md
docling sample.pdf --output out/
mineru -p sample.pdf -o out/mineru -b pipeline
marker_single sample.pdf --output_dir out/marker

Score them on the three things that decide retrieval quality, not on how the Markdown looks:

1. Cell recall on one table. Hand-mark the ground truth for a single table, then count how many cells survive with their row and column labels attached. This is the single most predictive check for RAG, and everyone skips it.
2. Reading order on the two-column page. Read the first 300 characters of output aloud. If two arguments are interleaved, that tool is out for that corpus.
3. Non-empty output on the scan. Check the byte count, not the exit code. Silent empty output is the failure mode that poisons an index without ever raising an error.

Time each run with time and note peak memory. If two tools tie on quality, take the faster one — you are going to re-run this over thousands of documents.

If you want the fully rigorous version, Marker's repo ships a reproducible harness in benchmarks/, including competitor runners for Docling and MinerU, plus the olmocr-bench scoring path. It is the fastest way to reproduce or challenge the numbers in the section above with your own hardware.

Once the Markdown is clean, the rest of the pipeline is the part we have already written up: chunking and retrieval with Ollama and ChromaDB, choosing an embedding model, and building an agent on top of it.

---

Verdict

There is no single winner, and anyone who names one has not looked at your documents.

• Marker is the strongest default on an NVIDIA box for born-digital PDFs with math and tables — provided you are comfortable with a Docker-backed inference server and you fit inside the model-weights licence.
• MinerU is the one to pick when the corpus is mixed, multilingual or scan-heavy, and when you want the option to escalate from a CPU pipeline to a full-page VLM without changing tools. It is also the most explicit about what hardware it wants, which is a virtue.
• Docling is the pragmatic choice for CPU-only and air-gapped work, and the only one that lets you swap the OCR engine to suit the documents. MIT, modular, boring in the best way.
• MarkItDown is not competing in the same category, and pretending otherwise does it a disservice. For Office documents and simple PDFs with six dependencies and no models, nothing else is close.

The most common mistake is picking a heavyweight parser for a corpus that never needed one, and the second most common is running MarkItDown over scans and wondering why the index is empty. Spend the afternoon on the twenty-page test. It will cost you less than the week you would otherwise spend blaming the embedding model.

---

Sources

• docling-project/docling — README feature list, install and usage commands; version, licence and dependency data from the docling and docling-slim PyPI entries (2.120.2)
• opendatalab/MinerU — README backend comparison table, system requirements, install and CLI commands, OmniDocBench v1.6 figures and licence change notes; version and licence from PyPI (3.4.5)
• microsoft/markitdown — README scope statement, install extras, CLI usage and the markitdown-ocr plugin notes; version and dependencies from PyPI (0.1.7)
• datalab-to/marker — README modes, inference-backend prerequisites, licensing statement and the olmocr-bench comparison table; version from PyPI (2.0.0)
• olmocr-bench — the benchmark Marker's table is scored against
• Repository files, READMEs and PyPI metadata were read directly on 18 August 2026. All four projects release frequently; re-verify versions before you build on them.

---

FAQ