Docling vs Marker: Which Open-Source PDF-to-Markdown Library to Pick (2026)
Direct answer: Pick Docling if you want clean structured output (tables, reading order, document hierarchy) with a permissive MIT license and no GPU requirement — it runs acceptably on CPU and exports straight to Markdown, HTML, or JSON. Pick Marker if your workload is GPU-backed batch conversion of long documents and you care most about throughput and high-fidelity Markdown with strong equation handling. Both are excellent; the deciding factors are usually license, whether you have a GPU, and whether your documents are equation-heavy (Marker) or structure-heavy (Docling).
This post compares the two for RAG and LLM pipelines: install, speed, accuracy on tables/equations/layout, GPU needs, output format, OCR, and licensing. If you are weighing the hosted options instead, see Unstructured vs LlamaParse and Docling vs LlamaParse.
The two libraries at a glance
Both Docling and Marker convert PDFs into Markdown suitable for chunking and embedding. They take different design routes to get there.
- Docling is an IBM Research project. It runs a layout model plus a dedicated table-structure model (TableFormer) to produce a structured document object, then serializes that object to Markdown, HTML, JSON, or its own DoclingDocument format. The emphasis is on faithful document structure: reading order, headings, lists, and table cell grids.
- Marker (by Vik Paruchuri) is a pipeline of deep-learning models that converts PDFs, and other formats, to Markdown, JSON, and HTML. It leans on the Surya OCR/layout model family and is built for speed on a GPU, with particular attention to equations, code blocks, and inline formatting.
If you only remember one distinction: Docling gives you a structured document you can serialize many ways; Marker gives you fast, formatting-rich Markdown.
Install
Docling is a single pip install and pulls its models on first run:
pip install docling
from docling.document_converter import DocumentConverter
converter = DocumentConverter()
result = converter.convert("report.pdf")
# Serialize to Markdown
markdown = result.document.export_to_markdown()
with open("report.md", "w", encoding="utf-8") as f:
f.write(markdown)
Docling also exports to other formats from the same parsed object:
result.document.export_to_html() # HTML
result.document.export_to_dict() # JSON-able dict (DoclingDocument)
Marker is also pip-installable. The models download on first use:
pip install marker-pdf
The fastest way to use Marker is its CLI:
# Single file
marker_single report.pdf --output_dir ./out
# A directory of PDFs
marker report_dir/ --output_dir ./out
Or call it from Python:
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered
converter = PdfConverter(artifact_dict=create_model_dict())
rendered = converter("report.pdf")
markdown, _, images = text_from_rendered(rendered)
with open("report.md", "w", encoding="utf-8") as f:
f.write(markdown)
Verdict on install: Both are a single pip command. Docling’s API is a little more direct if you just want a string of Markdown back; Marker’s CLI is the quickest path for batch jobs.
Speed and hardware
This is the sharpest practical difference between the two.
Marker is built for the GPU. On a CUDA GPU it converts documents quickly and scales well across batches; its batch CLI is designed to push many files through with high worker counts. On CPU it still runs, but you give up most of the speed advantage that motivates choosing Marker in the first place.
Docling runs acceptably on CPU. It is designed so a developer without a GPU can still get good results in reasonable time, and it accelerates when a GPU (CUDA or Apple MPS) is present. That makes it the more forgiving choice for laptops, CI runners, and CPU-only servers.
The honest framing: if you have a GPU and a large volume of documents, Marker is usually the faster path to a finished corpus. If you are CPU-bound, Docling is the more comfortable default. Exact numbers depend heavily on document length, page complexity, whether OCR fires, and your hardware, so benchmark on your own documents rather than trusting a single headline figure.
# Docling: prefer GPU when available, otherwise fall back to CPU
from docling.datamodel.accelerator_options import AcceleratorOptions, AcceleratorDevice
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat
pipeline = PdfPipelineOptions()
pipeline.accelerator_options = AcceleratorOptions(
num_threads=8,
device=AcceleratorDevice.AUTO, # picks CUDA / MPS / CPU
)
converter = DocumentConverter(
format_options={InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline)}
)
result = converter.convert("report.pdf")
Tables
Tables are where RAG pipelines bleed quality, so weigh this carefully.
Docling uses TableFormer, a model trained specifically to recover table structure — cell boundaries, row/column spans, and headers. In practice it is one of the stronger open-source options for tables with irregular structure (merged cells, nested headers) and emits a proper grid rather than a flattened text blob. You can tune its table mode for accuracy vs speed:
from docling.datamodel.pipeline_options import PdfPipelineOptions, TableFormerMode
pipeline = PdfPipelineOptions()
pipeline.do_table_structure = True
pipeline.table_structure_options.mode = TableFormerMode.ACCURATE # vs FAST
Marker also detects and renders tables, and produces clean Markdown tables for well-behaved grids. On dense or heavily merged tables it can be less reliable at preserving the exact cell structure than Docling’s dedicated table model. Marker can optionally route table-heavy work through an LLM pass to improve fidelity, at the cost of an external API call and latency.
Verdict on tables: Docling has the edge for complex, structure-critical tables out of the box. Marker is competitive on clean tables and can close the gap with its optional LLM mode.
Equations and math
Marker is the stronger choice for math-heavy documents. It converts inline and block equations to LaTeX and generally preserves notation well, which matters for scientific papers, textbooks, and technical specs where a mangled equation poisons a chunk.
Docling handles formulas and can enrich them, but equation conversion is not as central to its design as it is to Marker’s. For a corpus that is mostly research papers, Marker’s LaTeX output is usually the more faithful result.
Verdict on equations: Marker for math-dense content; Docling is adequate but not its headline strength.
Layout and reading order
Both libraries run layout analysis to recover reading order, which is what keeps multi-column papers from coming out as interleaved nonsense.
- Docling produces a structured document tree, so headings, lists, captions, and section nesting survive into the output. If you need the hierarchy (for example, to chunk by section), Docling hands it to you directly.
- Marker reconstructs reading order and formatting well and is strong on inline formatting (bold, code, links). Its output is Markdown-first rather than a structured tree, so if you need an explicit document hierarchy you reconstruct it from the Markdown headings.
For RAG, structure-aware chunking tends to retrieve better than naive fixed-size chunking. If section-level structure is part of your strategy, Docling’s tree is convenient. See PDF to Markdown for RAG for why structure-preserving extraction matters to retrieval quality.
OCR (scanned PDFs)
Neither library can read pixels without an OCR step, and both support one.
Docling integrates with multiple OCR backends (EasyOCR by default, with options including Tesseract and RapidOCR) and auto-detects when a page needs OCR. You can force or disable it:
pipeline = PdfPipelineOptions()
pipeline.do_ocr = True # set False to skip OCR on born-digital PDFs and save time
Marker uses the Surya OCR model family and applies OCR where the text layer is missing or unreliable. Because Surya is GPU-accelerated, Marker’s OCR path benefits from the same hardware that speeds up the rest of the pipeline.
Verdict on OCR: Both handle scanned PDFs. Docling gives you more pluggable backend choice; Marker’s OCR rides on its GPU pipeline. For a deeper look at detecting scanned pages before wasting an extraction pass, the best open-source PDF extraction library breakdown covers the detection step.
Output formats
| Docling | Marker | |
|---|---|---|
| Markdown | Yes | Yes |
| HTML | Yes | Yes |
| JSON | Yes (DoclingDocument) | Yes |
| Structured document tree | Yes (native) | Reconstruct from Markdown |
| Image extraction | Yes | Yes |
Both cover the formats a RAG pipeline needs. Docling’s structured DoclingDocument is the differentiator if you want to operate on the parsed object before serializing.
License
This is often the quiet deal-breaker for commercial use.
- Docling is MIT licensed — permissive, commercial-friendly, no copyleft obligations.
- Marker ships under a license with a commercial-use revenue condition: it is free for research and for organizations under a revenue/funding threshold, but companies above that threshold need a paid commercial license. Read Marker’s current license terms directly before shipping it in a paid product — the threshold and terms can change between releases.
If you are building a commercial product and want zero licensing ambiguity, Docling’s MIT license is the safer default. If you qualify under Marker’s threshold or are happy to license it, that condition may not matter to you.
Verdict on license: Docling (MIT) is the cleaner choice for unrestricted commercial use; verify Marker’s terms against your company’s revenue before committing.
Comparison table
| Factor | Docling (IBM) | Marker (VikParuchuri) |
|---|---|---|
| Install | pip install docling | pip install marker-pdf |
| License | MIT (permissive) | Commercial-use revenue condition — verify |
| GPU required? | No (CPU-acceptable, GPU optional) | Recommended (built for GPU throughput) |
| Tables | Strong (TableFormer, structure-aware) | Good; optional LLM mode for hard tables |
| Equations | Adequate | Strong (LaTeX output) |
| Layout / reading order | Structured document tree | Markdown-first, good reading order |
| OCR | Pluggable backends (EasyOCR/Tesseract/RapidOCR) | Surya OCR (GPU-accelerated) |
| Output | Markdown, HTML, JSON, DoclingDocument | Markdown, HTML, JSON |
| Best for | CPU environments, complex tables, MIT requirement | GPU batch jobs, math-heavy docs |
When to pick each
Pick Docling when:
- You need a permissive MIT license for a commercial product.
- You are CPU-bound (laptop, CI runner, CPU-only server).
- Your documents have complex tables where cell structure matters.
- You want a structured document object to chunk by section, not just a Markdown string.
Pick Marker when:
- You have a GPU and large batches of documents to convert.
- Your corpus is equation-heavy (scientific papers, textbooks) and you need clean LaTeX.
- Throughput is your primary constraint and you qualify under, or are happy to pay for, its license.
Use both when: Some teams route equation-heavy scientific PDFs through Marker and structure-heavy reports or forms through Docling. That works, but it means maintaining two pipelines, two sets of model weights, and two failure modes. The cost is operational complexity, not extraction quality.
The managed option
Running either library yourself means owning the model downloads, GPU provisioning, OCR backends, version pins, and the routing logic to decide which document goes to which tool. That is reasonable if extraction is core to your product and you have the ops bandwidth.
If you would rather not run any of it, pdfmux is a managed API that handles routing across tools for you and returns clean Markdown or structured JSON without you provisioning GPUs or maintaining model dependencies. It is the hosted option when you want the outcome without the infrastructure. For a direct, like-for-like view, see pdfmux vs Docling and pdfmux vs Marker.
FAQ
Is Docling or Marker more accurate?
It depends on the document. Docling tends to win on complex table structure and gives you a faithful document tree. Marker tends to win on equations and on raw throughput when a GPU is available. For born-digital reports with hard tables, lean Docling; for equation-dense academic PDFs, lean Marker. Benchmark both on a representative sample of your own documents before committing — headline accuracy numbers rarely match your specific corpus.
Do I need a GPU for Docling or Marker?
Docling runs acceptably on CPU and uses a GPU only if one is available, so it is the better no-GPU choice. Marker is designed for GPU throughput; it runs on CPU but loses most of its speed advantage there. If you have no GPU and a deadline, start with Docling.
Which is better for RAG?
Both produce Markdown that chunks well. Docling’s structured output makes section-aware chunking easier, which often improves retrieval quality. Marker’s strength is fast, formatting-rich Markdown including good equation handling. Pick based on whether your retrieval strategy depends more on document structure (Docling) or on math fidelity and throughput (Marker). See PDF to Markdown for RAG for chunking guidance.
Can I use Marker in a commercial product?
Marker is free for research and for organizations under its revenue/funding threshold, but companies above that threshold need a paid commercial license. Always read Marker’s current license before shipping it commercially. Docling is MIT-licensed and has no such restriction, which is why it is the safer default for unrestricted commercial use.
Try pdfmux
If you would rather not run, provision, and maintain open-source extraction models yourself, pdfmux is the managed API that handles the routing and returns clean Markdown or structured JSON.
pip install pdfmux
Try it at pdfmux.com, or compare it head-to-head in pdfmux vs Docling, pdfmux vs Marker, and the best open-source PDF extraction library roundup.