Which PDF→Markdown
tool should you trust?

How pdfmux compares

Every tool below is good — they’re just built for different jobs. The honest split: most are a single engine you trust blindly. pdfmux is the layer that checks the work and routes to the right engine per page.

Reflects each tool’s documented features as of July 2026. “Routes engines” = automatically picks a different extractor per page. Every tool name links to its full head-to-head with install commands and tradeoffs, or see the full 7-tool comparison and all comparison posts.

Same documents, same machine, stopwatch running

Feature tables are claims. These are measurements — run 11 July 2026 on a CPU-only dev machine (no GPU), each tool in its own process with a 240-second cap per document. Versions: pdfmux 1.7.0, PyMuPDF 1.28.0, pymupdf4llm 1.28.0, MarkItDown 0.1.6, Docling 2.112.0. Two representative documents shown; six were run.

The honest read: raw PyMuPDF is the speed king and always will be — if you trust every page blindly, use it. MarkItDown is quick and solid on clean text. pdfmux spends its extra seconds classifying every page, scoring the output 0–1, and writing the audit manifest — that’s the product. Docling’s layout models want a GPU; on CPU it timed out on both 100+ page documents in this run (its table accuracy remains best-in-class where it fits). All six PDFs here were clean digital text, so pdfmux routed zero pages to OCR and scored 1.0 across the board — on scanned or degraded input the confidence signal, not the stopwatch, is what changes your outcome. Full data: benchmarks/output/compare-hub-2026-07-11 in the site repo, reproducible via compare_hub_benchmark.py.

It audits the others, too

pdfmux doesn’t only compete with Marker, Docling and LlamaParse — it certifies them. Run your current extractor, then pdfmux verify reports which pages it silently dropped. That’s the wedge no other tool offers: a free second opinion on the extraction you already trust.

Measured on 433 real customer documents — the failing run was pdfmux’s own early pipeline, which is exactly why it now flags what it can’t read instead of dropping it. Try it at pdfmux.com/audit.

We publish our own error rates

Every tool on this page publishes accuracy scores. Ask any of them — including us — for the rate at which their checker cries wolf, and the defect classes it cannot see at all. That is the number that decides whether you can put a verifier in CI. Here is ours, measured on GT-0: a pre-registered, public corpus of 24 documents across 8 categories, with the seeded defects and the measurement script published alongside it so the result can be reproduced or disputed.

Alongside those: a 6.7% false-alarm rate (1 of 15 verifiable documents hard-failed a correct, independently transcribed extraction), and 25% of the corpus declined outright as unverifiable rather than guessed at. The table blind spot had a stated cause — the integrity check tested that a table was present, not that it was complete — and v1.8.7 closes it with a table_truncated flag that compares row counts document-wide and for the largest single table block. On the pre-registered corpus, measured end-to-end with pdfmux 1.8.7: of 4 applicable seeded truncations the verifier detects 1 — a 75% false-negative rate, against 80% before the flag existed. The check counts Markdown pipe rows, but the source text pdfmux re-derives from a PDF usually contains no pipe-table markup at all (0 rows on both cases measured), so it cannot fire on the path that matters. It only helps when the source itself is Markdown. Treat table completeness as unsolved. That re-run is not yet part of the published measurement script, so the table above reports the pre-1.8.7 checks; and the flag counts rows, so column loss can still pass. Source re-derivation also fails on Arabic RTL and some subsetted-font PDFs. Full write-up: pdfmux-bench/VERIFIER-VALIDATION.md.

Most RAG hallucinations start at extraction

Standard extractors silently fail on scanned pages (empty text), two-column layouts (scrambled reading order), and tables (lost structure). Your chunks look fine but contain broken text. pdfmux scores every page 0–1, flags the failures, and re-extracts them with a stronger backend — so your embeddings are built on clean text. It’s the only LangChain / LlamaIndex loader that attaches a per-page confidence score you can filter on before embedding.

Want this without running it?

pdfmux Cloud runs the same extraction behind a hosted API — signed per-batch manifests, per-key page quotas, free tier at 100 pages / month, paid tiers from $49. Live now — sign in and mint an API key on the free tier, no card. Start free →