Docling is IBM's MIT-licensed document parser, and it is free to install. Running it is not. Priced against IBM's own published throughput, Docling costs about $0.21 per 1,000 pages of compute, and that figure is measured with OCR turned off. This page works out the real number, the licenses, and where a managed product earns its rate.
Written for US engineering and procurement teams deciding whether to self-host. Every figure is computed from a primary source and the arithmetic is shown. Last updated August 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5 files, the rest unlock when you upgrade
Uploading...
Before you stand up a parsing service, drop in the hardest document you have and see what finished, validated fields look like.
Docling is an open-source Python package that converts documents into structured text. It came out of the AI for Knowledge group at IBM Research in Rueschlikon and is now hosted in the LF AI and Data Foundation. The code is MIT licensed. The default pipeline is not a language model at all: it is a layout model trained on DocLayNet plus TableFormer for table structure, and it runs on an ordinary CPU.
The cost question is where almost every write-up stops at "it's free" and quits. Free to license is not free to operate. IBM published throughput numbers in its own technical report, and those numbers can be priced. At 0.92 pages a second on a 16-core machine, 1,000 pages take 1,087 seconds, which is 0.30 hours. A 16-vCPU Linux instance in US East is $0.68 an hour on demand today. That is $0.2053 per 1,000 pages, or about $205 for a million pages a month.
The caveat that matters more than the number. IBM's performance table carries a one-line caption that most people skip: "OCR is disabled." Every throughput figure Docling has ever published describes parsing a digital PDF, where the text is already in the file. Scanned pages need an OCR engine layered on top, and IBM has never published a throughput figure for any OCR-enabled configuration. If your documents arrive as scans or phone photos, the honest answer is that the public numbers do not cover your case.
About $0.21 per 1,000 pages of compute on the default backend, and about $0.12 on the faster one. The method is simple enough to check: take the pages-per-second figure IBM published, divide 1,000 by it to get seconds, convert to hours, and multiply by what a 16-vCPU Linux instance costs on demand in US East today, which is $0.6800 an hour for a c6i.4xlarge. Nothing here is estimated or rounded from memory.
| Configuration | IBM throughput | Seconds per 1,000 pages | Compute per 1,000 pages | Machine-hours for 1M pages | Compute for 1M pages |
|---|---|---|---|---|---|
| Native backend, 16 threads | 0.92 pages/s | 1,087 s | $0.21 | 302 hours | $205 |
| Native backend, 4 threads | 0.60 pages/s | 1,667 s | $0.31 | 463 hours | $315 |
| pypdfium backend, 16 threads | 1.57 pages/s | 637 s | $0.12 | 177 hours | $120 |
| pypdfium backend, 4 threads | 0.94 pages/s | 1,064 s | $0.20 | 295 hours | $201 |
Two things about that table are worth saying out loud, because they cut in opposite directions. The Intel Xeon E5-2690 IBM benchmarked on is a 2012-generation part, and we are pricing its throughput at a current Ice Lake instance rate, so a real c6i or c7i would finish faster and the true cost per page would be lower than $0.21. Treat the figure as a ceiling. Pulling the other way, 302 machine-hours a month is a 42 percent duty cycle on one instance, which sounds comfortable until a Monday morning batch arrives and you discover you have built a queue, not a converter.
Peak resident memory on the native backend, in IBM's own measurement. The pypdfium backend halves it to 2.56 GB. A 16-vCPU instance with 32 GiB has room, but a small container does not.
A million pages a month is about $205 of Docling compute. The same million pages through a managed layout or prebuilt model at $10.00 per 1,000 is $10,000. That gap is real and it is the honest case for self-hosting.
The $205 does not include the person who owns the service. One engineer spending a day a month on queues, retries, model upgrades and a page that failed to parse costs more than the compute does, by a wide margin.
This is Table 1 from the Docling Technical Report, reproduced in full because it is the only published performance data that exists and it is buried in a PDF. The test set is IBM's own: three arXiv papers and two IBM Redbooks, 225 pages total. The thread budget is set through OMP_NUM_THREADS, once at 4 (the Docling default) and once at 16. OCR is disabled throughout.
| CPU | Threads | Native: time | Native: pages/s | Native: peak memory | pypdfium: time | pypdfium: pages/s | pypdfium: peak memory |
|---|---|---|---|---|---|---|---|
| Apple M3 Max (16 cores) | 4 | 177 s | 1.27 | 6.20 GB | 103 s | 2.18 | 2.56 GB |
| Apple M3 Max (16 cores) | 16 | 167 s | 1.34 | 6.20 GB | 92 s | 2.45 | 2.56 GB |
| Intel Xeon E5-2690 (16 cores) | 4 | 375 s | 0.60 | 6.16 GB | 239 s | 0.94 | 2.42 GB |
| Intel Xeon E5-2690 (16 cores) | 16 | 244 s | 0.92 | 6.16 GB | 143 s | 1.57 | 2.42 GB |
Source: Docling Technical Report, arXiv:2408.09869v5, dated December 9, 2024, AI4K Group, IBM Research Rueschlikon.
pypdfium is roughly 70 percent faster and uses less than half the memory, so the temptation is obvious. IBM states the trade plainly: it "will come at the expense of worse quality results, especially in table structure recovery." If you are parsing prose for a search index, take the speed. If you are pulling line items out of an invoice, the thing you just traded away is the thing you came for.
The technical report is still at v5, dated December 2024, and it describes version 1.0. It says GPU acceleration was then "work-in-progress and largely untested." The package shipped v2.122.0 on August 25, 2026, with roughly eight releases a month through the year. The code has moved a long way past its only published benchmark, which is worth knowing before you quote a pages-per-second figure at anyone.
Docling does not ship an OCR engine of its own. It ships adapters to five, and you install whichever one you want. That is a reasonable design and it is also the part of Docling most likely to bite a production team, for a reason that is in the source code rather than the documentation.
| Engine | Options class | How you get it | What to know |
|---|---|---|---|
| RapidOCR | RapidOcrOptions | Separate install | Runs PP-OCR models. Backends: onnxruntime (default), openvino, paddle, torch. |
| EasyOCR | EasyOcrOptions | Separate install | What the automatic selector picks when a GPU is present. |
| Tesseract | TesseractOcrOptions, TesseractCliOcrOptions | System package | Must be installed as a system package, not through pip. What the selector falls back to with no GPU. |
| Nemotron-OCR | NemotronOcrOptions | Separate install | Linux only and requires CUDA, which Docling pins to 13.x. NVIDIA Open Model License. |
| OcrMac | OcrMacOptions | macOS only | A thin wrapper around Apple's Vision framework. Ships no model artifacts of its own. |
| Automatic | OcrAutoOptions | The default | Probes the machine at pipeline init and picks for you. See the warning below this table. |
In docling/datamodel/pipeline_options.py, the ocr_options field defaults to OcrAutoOptions(). Its own docstring describes what that does: it "probes the runtime environment at pipeline initialization and selects the best available OCR engine (e.g., EasyOCR if GPU is present, Tesseract otherwise)," and language settings are "deferred to the chosen engine's defaults," with the language list defaulting to empty.
Read that again with a deployment in mind. A developer laptop with a GPU and a CPU-only production container will read the same scanned page with two different OCR engines and two different language defaults, with not one line of your code different between them. If you self-host Docling for anything where the output is checked, pin the engine explicitly rather than letting the selector choose. This is the single most useful thing on this page for a team already running Docling.
"MIT licensed" is true and it is also only about the Python code. The models that do the actual work are separate artifacts on Hugging Face with separate terms, and one of the OCR engines Docling now supports is not under an open-source license at all. If you are shipping Docling inside a product a US customer pays for, this table is what your legal review has to cover.
| Component | Where it lives | License | What it means for you |
|---|---|---|---|
| Docling package (the code) | github.com/docling-project/docling | MIT | Cleanest license in the stack. Ship it anywhere. |
| Docling models (layout, TableFormer) | docling-project/docling-models | CDLA-Permissive-2.0 and Apache-2.0 | Dual licensed. CDLA is a data license, not a code license, so counsel reviews it separately. |
| Layout model, current | docling-project/docling-layout-heron | Apache-2.0 | Standard permissive terms. 1.8 million downloads in 30 days. |
| GraniteDocling vision model | ibm-granite/granite-docling-258M | Apache-2.0 | IBM's 258M-parameter document VLM. Optional, not the default path. |
| Nemotron-OCR engine | nvidia/nemotron-ocr-v1 | NVIDIA Open Model License | Not a standard open-source license. Read it before enabling this engine. |
| RapidOCR, EasyOCR, Tesseract | Installed separately by you | Each carries its own terms | Docling does not vendor these. Whatever you install is your license to clear. |
None of this is a warning against Docling. CDLA-Permissive-2.0 and Apache-2.0 are both friendly to commercial use, and most teams will clear them in an afternoon. The point is that "it's MIT" is an answer about one of five artifacts, and the NVIDIA Open Model License on Nemotron-OCR is genuinely different in kind. Check the terms yourself before you rely on this summary.
IBM publishes no end-to-end accuracy figure for Docling. We also checked the one independent leaderboard that covers this category, OmniDocBench from OpenDataLab, and Docling carries no score there either. It was added to the benchmark in a January 2025 changelog entry and it still appears in the evaluation-model registry, where its layout model is listed as docling-layout-heron. But across the end-to-end table, the text OCR table, the table-recognition table and the layout table, there is no Docling row. Thirty-two systems are ranked. Docling is not one of them.
| System | Type | Size | Overall composite | Table TEDS |
|---|---|---|---|---|
| PaddleOCR-VL-1.6 | Specialized VLM | 0.9B | 96.34 | 94.76 |
| Gemini 3 Pro | General VLM | not stated | 92.91 | 89.15 |
| GPT-5.2 | General VLM | not stated | 86.59 | 82.95 |
| MinerU-Pipeline | Pipeline tool | not stated | 86.47 | 81.88 |
| Mistral OCR | Specialized VLM | not stated | 85.66 | 76.78 |
| Marker | Pipeline tool | not stated | 78.44 | 65.77 |
| Docling | Pipeline tool | not stated | Not currently scored | Not currently scored |
Selected rows from the OmniDocBench v1.7 end-to-end leaderboard, checked August 2026. "Not currently scored" means exactly that and nothing more: it is not a low score, it is an absent one. Note also that the Overall column is a composite of text edit distance, table TEDS and formula CDM, so 96.34 is not "96 percent of characters were right." For financial documents the column that matters is Table TEDS, and it ranks differently.
The useful context the board does give you is the shape of the category. Both ranked pipeline-style tools, MinerU-Pipeline at 86.47 and Marker at 78.44, sit well below the specialized vision models at the top. That does not tell you where Docling would land. It does tell you that a modular layout-plus-table pipeline is not automatically competitive with a purpose-built model, which is worth knowing before you assume the free option is also the accurate one. We work through the whole board, and the fact that AWS, Azure and Google publish no accuracy figure at all, in our OCR accuracy comparison.
The input list is unusually long for a document parser, and it has grown well past PDF. Audio and video are in there now, handled by speech models rather than the layout pipeline.
On the way out you get Markdown, HTML, WebVTT, DocLang, DocTags and lossless JSON, plus application-specific schemas for USPTO patents, JATS articles and XBRL financial reports. If Markdown is the output you actually want, our PDF to Markdown API page covers what the managed alternatives charge for the same thing, and it is more than you would guess. If you want rows in a spreadsheet instead, that is PDF to CSV.
Your documents are mostly digital PDFs
This is precisely what Docling is fast and cheap at, and it is what the published numbers measure.
You are building a RAG or search corpus
Structure-aware Markdown and JSON with reading order is a better chunking input than raw text, and this is the job the project was designed for.
The documents cannot leave your network
Local execution with pre-cached models means nothing goes out. For a hard air-gap requirement, self-hosting beats any cloud vendor including us.
You have engineers who want to own it
Docling is a library, not a product. Somebody has to run it, and if that person exists and has the time, the economics are excellent.
Your inbox is scans and phone photos
The published performance data does not cover this path, and you now own an OCR engine choice, a language configuration and a quality problem on top of the parser.
A wrong number costs you money
There is no per-field confidence score in the output and no published accuracy figure to point a risk committee at. Parsers are not validators.
What you need is a workflow, not a parser
Classification, extraction rules, validation, a human review queue for low-confidence fields and an export into your accounting system are all still yours to build.
People reach for a Docling alternative for two different reasons, and they lead to different answers. If you want another open-source parser, the real comparison set is Marker, MinerU and Unstructured, and it is a question about parsing quality on your documents. If what you actually want is to stop maintaining a parsing service, the comparison is with a managed product, and it is a question about which parts of the job you are buying. Here is that second comparison, stated fairly.
| Question | Self-hosted Docling | A managed extraction product |
|---|---|---|
| What you pay | About $0.21 per 1,000 pages of compute, plus your engineers | A published per-page rate, plus nothing else |
| Who runs it | You. A Python service, a container, a queue, a retry policy | The vendor |
| Digital PDFs | Excellent, and this is what the published numbers measure | Excellent |
| Scanned pages | Add an OCR engine yourself. No published throughput for this path | Included in the per-page rate |
| Table structure | TableFormer, and it is genuinely good | Varies by vendor and by meter |
| Confidence per field | Not part of the output | Standard on document APIs |
| Validation and human review | You build it | Part of a workflow product |
| Data leaves your network | Never, if you pre-cache the models | Yes, unless the vendor sells a container |
| Published accuracy number | None | Mostly none either, which is its own finding |
| Upgrade burden | About eight releases a month to track | The vendor's problem |
We sell the managed side of that table, so read the row about compute cost with that in mind: $0.21 per 1,000 pages genuinely is cheaper than anything we or AWS or Azure or Google will charge you, and if your documents are digital PDFs and you have the engineers, self-hosting is the right answer and you should do it. The case for buying is not price per page. It is that a parser hands you text and a workflow hands you checked fields. If you want to see how the managed rates line up against each other first, OCR pricing per 1,000 pages is the cross-vendor reference, and self-hosted OCR cost works the same arithmetic for GPU-based readers.
The same arithmetic applied to GPU readers: real instance rates against real throughput, and where the break-even against a managed API actually sits.
Read itA 7B open-source document reader priced per 1,000 pages on named GPU instances, with the pages-per-dollar figure for each.
Read itThe full OmniDocBench board, plus the finding that the three biggest cloud document APIs publish no accuracy number at all.
Read itMarkdown is not a free output toggle on the big clouds. What Azure and AWS actually charge to hand you Markdown instead of text.
Read itEvery managed vendor lined up on one page, with the parts of a document workflow the per-page rate does not include.
Read itIf the documents genuinely cannot leave your network, the honest options, including the ones that are not us.
Read itA benchmark on arXiv papers cannot tell you how a parser handles your vendor's invoice template. Upload the document you were about to write a Docling script for and see what finished, validated fields look like. If Docling wins on your documents, use Docling.
