A vision model reading a financial statement can return a number that appears nowhere on the page. A layout pipeline reading the same page can drop that number, mis-order it, or mangle the column it belongs to — but it cannot invent it, because it never generates text, it only relocates it. That asymmetry, not any accuracy score, is the fact that should decide your document parser, and it is the one no leaderboard reports.
At a glance
Four tools that all turn a PDF into text an agent can retrieve over, split across two fundamentally different ways of doing it.
| Tool | Default mode | Where it runs | Rough marginal cost |
|---|---|---|---|
| Docling | Layout pipeline; an optional VLM mode | Your machine, CPU or GPU | Compute only |
| Unstructured | Layout pipeline across many file types | Library locally, or a hosted platform | Compute, or per-page hosted |
| LlamaParse | Model-driven parse, several quality tiers | Hosted API | Credits; roughly cents per page and down |
| Mistral OCR | VLM per page | Hosted API; on-prem for enterprise | Order of $1–2 per 1,000 pages |
Those prices move and the tiers move faster; treat the column as an order of magnitude, not a quote. The number that matters is not any of them individually but the ratio between per-page cost and the fixed cost of a machine, which is the subject of the cost section below.
Why the accuracy leaderboard does not transfer
Every vendor publishes a benchmark, and the benchmarks broadly agree that model-driven parsing wins on dense tables, multi-column layouts and scans, while deterministic pipelines win on speed and on clean digital documents. That much is real. What is not transferable is the ranking, because a parser's score is a weighted average over the benchmark's document mix, and your mix is different in ways that dominate the gap between vendors.
Consider what "documents" actually means in three real corpora. A corpus of digitally-generated invoices from six ERP systems has no OCR problem at all — every character is already in the file, and the entire task is table structure. A corpus of scanned 1990s contracts is nothing but OCR, and table structure barely appears. A corpus of scientific PDFs is a formula-and-figure problem that neither of the other two tests. A leaderboard built mostly from the third tells you very little about the first, and the spread between vendors on any single benchmark is routinely smaller than the spread between these three corpora on any single vendor.
This is why the useful first move is not reading comparisons — it is assembling fifty pages that look like your worst documents and running all four. That takes an afternoon, and it is the only evidence that is actually about you. Everything below is about the decisions that survive after you have done it, when two parsers score close enough that the score stops deciding.
Two modes, not four vendors
The layout-pipeline mode is a chain of narrow models: detect regions, classify them, run OCR only where there is no embedded text layer, recover table structure from ruling lines and cell geometry, then serialise everything into reading order. Docling and Unstructured are both built this way. It is fast, it runs on a CPU, and its output is traceable — every span can be pointed back to a bounding box on a page.
The VLM mode renders each page to an image and asks a vision-language model to write out the content, typically as Markdown. LlamaParse's higher tiers and Mistral OCR both work this way. It handles the cases that break geometry-based pipelines — a table with no ruling lines, a rotated scan, handwriting, a chart that needs reading rather than detecting — and it does so without you writing a single rule.
The split is by mode, not by vendor, and the tool that makes this clearest is Docling, which ships both: the classic pipeline and an optional VLM path using a document-specific vision model, behind the same interface, on your own hardware. That is a genuinely different offer from the other three, because it means you can route by document type — pipeline for the 90% that are clean, VLM for the 10% that are not — without adding a second vendor, a second bill, or a second egress path.
The failure modes are not symmetric
Here is the argument this post exists for. A layout pipeline fails by omission and disorder. It drops a footnote, merges two columns, splits a table across a page break, returns a cell in the wrong row. Every one of those is ugly, and every one of them is detectable — the output can be checked against the source geometry, and a missing value shows up as a missing value.
A VLM fails by plausible completion. Asked to transcribe a smudged column of figures it will produce a column of figures, and the ones it could not read will be replaced by ones that fit. It will regularise an irregular date format. It will repair a total that does not sum. It will silently normalise a column header to what such headers usually say. None of that is a bug report anyone will file, because the output looks better than the input.
The asymmetry is that the pipeline's failures are loud and the VLM's failures are quiet, and quiet failures propagate. A dropped number surfaces as an agent saying "I could not find it". A fabricated number surfaces as an agent giving a confident wrong answer, six weeks later, to someone who acts on it.
This does not make VLM parsing wrong. It makes it wrong unverified, and the verification is cheap when you know to build it: parse the same page both ways and reconcile the numerics, or re-run the VLM at a different temperature and flag disagreement, or simply require that every figure the agent cites be re-findable as a literal string in a deterministic extraction of the same page. That last check costs one extra pipeline run per document and catches the entire class. See hallucination and grounding for why "the model said it" is not provenance, and finance agents for the domain where this is not optional.
Where the numbers do not matter — a policy corpus, a knowledge base, a support archive — the calculus flips entirely. A VLM that produces clean readable Markdown from a messy scan is straightforwardly better than a pipeline that produces correct-but-shredded text, because retrieval quality depends on the chunk reading like prose. Pick the failure mode you can afford, per corpus, not per company.
The cost curve, and where it crosses
Hosted parsing has near-zero fixed cost and a real marginal cost per page. Self-hosted parsing has a real fixed cost — a machine that is always on — and a marginal cost close to zero until you saturate it. Two curves like that cross exactly once, and you can find the crossing with one division.
Take a hosted VLM at roughly $2 per thousand pages, so $0.002 per page. Take a GPU instance capable of running a document VLM at around $700 a month all-in. The crossing is $700 ÷ $0.002 = 350,000 pages a month. Below that, hosted is cheaper and you should not be running a GPU. Above it, self-hosting wins and keeps winning, because the fixed cost grows in steps while the hosted bill grows in a straight line.
Now do the same for a CPU layout pipeline, which needs no GPU at all: a couple of workers at around $60 a month puts the crossing near 30,000 pages a month. That is a very low bar — a single team's document backlog clears it — and it is why "just use the hosted API" is genuinely correct for pilots and genuinely expensive for anything that reaches production volume with clean documents.
Substitute your own numbers; the ones above are illustrative and every input moves. What does not move is the shape: the decision is a fixed-versus-marginal trade-off, so it is decided by volume, and volume is the one input you already know. Anyone recommending a parser without asking your page count is recommending on vibes. The same reasoning, applied one layer up, is unit economics.
Two costs the arithmetic above leaves out, both of which favour self-hosting more than people expect. Re-parsing: you will re-run the whole corpus when you change chunking strategy, and with a hosted API you pay for the corpus again every time. And egress: sending documents to a third party is a data-protection decision with a review attached, and for some corpora the review is the actual blocker regardless of price. See data residency and sovereignty.
The four, briefly
Docling
MIT-licensed, from IBM Research and now under the LF AI & Data Foundation, and the only one of the four that gives you both modes locally behind one interface. It runs fully offline, which makes it the default answer whenever the documents cannot leave your network. The trade is that you own the operations: throughput tuning, model downloads, GPU capacity if you use the VLM path.
Unstructured
The widest format coverage in the group — it is as much a document ingestion layer as a PDF parser, with connectors and handling for the long tail of office formats, email and HTML that a PDF-first tool ignores. If your corpus is heterogeneous rather than deep, this breadth is worth more than any per-document accuracy delta. Available as a library and as a hosted platform, so the self-host-versus-hosted decision is available without changing tools.
LlamaParse
The most product-shaped of the four, with tiers that let you spend more on the pages that need it, and output deliberately designed to land well in a downstream chunking step. It is the fastest path from "we have a bucket of PDFs" to "retrieval works", and it is priced per page forever, which is the trade.
Mistral OCR
The clearest expression of the VLM-per-page bet: one endpoint, one job, aggressive per-page pricing that gets cheaper on the batch path, and an on-prem option for enterprises that need the mode without the egress. Reach for it when the corpus is genuinely hard — scans, handwriting, tables without lines — and volume is not yet at self-hosting scale.
When to pick which
| Your situation | Start with | Because |
|---|---|---|
| Documents cannot leave your network | Docling, or Unstructured self-hosted | The hosted options are ruled out before accuracy is discussed. |
| Numbers in the output will be acted on | A pipeline, plus a VLM only with reconciliation | Fabrication is the failure you cannot see. |
| Under ~30k pages a month, mixed formats | A hosted API | Below the crossover, your own infrastructure is the expensive option. |
| Millions of pages, mostly clean digital PDFs | A self-hosted CPU pipeline | No GPU needed, and the hosted bill grows linearly forever. |
| Scans, handwriting, tables without ruling lines | A VLM mode, whichever vendor | Geometry-based extraction has nothing to work with. |
| Heterogeneous corpus — email, Office, HTML, PDF | Unstructured | Breadth beats per-document accuracy when the tail is the problem. |
The pattern most mature pipelines converge on is routing rather than choosing: a cheap deterministic pass over everything, a confidence check, and an expensive model-driven pass over only the pages that failed it. That costs one extra classification step and moves the average page cost close to the cheap path's, which is a better outcome than any single-parser decision available.
FAQ
Can I just send the PDF to a frontier model and skip parsers entirely?
For a handful of documents, yes, and it works well. It stops being reasonable at corpus scale for the same reason hosted parsing does — per-page cost that never falls — and you inherit the fabrication risk without the per-page provenance a dedicated parser can give you.
Which of these is most accurate?
The question does not have a portable answer, which is the argument of this post. Model-driven parsing generally leads on hard layouts and pipelines lead on clean digital documents, but the spread between your document types is larger than the spread between vendors. Test on fifty of your own worst pages.
Is Docling's VLM mode as good as a hosted VLM?
Close enough that the comparison is usually decided by operations rather than quality — a document-specific vision model running locally is a different bet from a general frontier model behind an API, and the local one costs you GPU capacity you have to plan for. Benchmark both on your corpus; the gap moves with every model release.
How do I know if my parser is fabricating?
Parse a sample both ways and reconcile every numeric token. Anything present in the model output but absent from the deterministic extraction of the same page is either a real recovery from an unreadable region or a fabrication, and you cannot tell which without looking — which is exactly why the check belongs in the pipeline rather than in a spot audit.
Does the parser choice affect chunking?
Substantially. A parser that preserves heading hierarchy and table boundaries lets you chunk on structure; one that returns a flat wall of text forces you back to fixed-size windows, which is a measurable retrieval regression. Judge output on whether it carries structure, not only on whether it carries the characters.
What about the ones not covered here?
Marker, PyMuPDF4LLM, Reducto, Azure Document Intelligence, Google Document AI and the open-weight OCR models all slot into the same two modes. Place any new entrant by asking two questions: does it generate text or relocate it, and is its cost fixed or marginal? Those answers predict almost everything else.
Further reading
On this wiki:
- Document parsing for RAG — the full treatment of the stage this post is choosing a tool for.
- Chunking and vector search — what the parser output feeds, and why structure survives better than characters.
- Local-first retrieval — the rest of the stack when nothing may leave the machine.
- Data residency and sovereignty — the constraint that decides this before cost does.
- RAG security — what else arrives when you ingest documents you did not write.
- Finance agents — the domain where a fabricated figure is the whole risk.