Docling

Docling is a document-processing library from IBM Research’s Deep Search team, now hosted under the LF AI & Data Foundation, that converts a wide range of file formats into a single unified representation called DoclingDocument. It handles PDF (with advanced layout analysis, reading-order detection, and table-structure recognition), Office formats (DOCX, PPTX, XLSX), web formats (HTML, Markdown), OpenDocument files, e-books, email, LaTeX, images, and even audio/video via ASR transcription.

Instead of returning raw text, Docling produces a structured, lossless representation that can be exported to Markdown, HTML, DocTags, or JSON, which makes it especially well suited as the ingestion layer for retrieval-augmented generation (RAG) and other LLM-powered applications. It ships plug-and-play integrations with LangChain, LlamaIndex, Crew AI, and Haystack, a built-in MCP server so agents can call it as a tool, and an optional API server (docling-serve) for running it as a standalone service.

What You Get

• A DocumentConverter Python API and a docling CLI that convert dozens of input formats to a single DoclingDocument representation
• Advanced PDF understanding: page layout, reading order, table structure, formula and code recognition, and image classification
• Export to Markdown, HTML, WebVTT, DocTags, or lossless JSON, with schema support for USPTO patents, JATS articles, and XBRL financial reports
• Local, fully offline execution suitable for sensitive data and air-gapped environments — no cloud dependency required
• Ready-made integrations with LangChain, LlamaIndex, Crew AI, and Haystack, plus a built-in MCP server for agent tool-calling
• Pluggable OCR, VLM (including GraniteDocling), and ASR backends selectable per pipeline for scanned documents, images, and audio/video

Common Use Cases

• Building the ingestion layer of a RAG pipeline that needs clean Markdown or chunked JSON from heterogeneous source documents
• Extracting structured tables and figures from scientific papers, financial reports, or technical PDFs for downstream analysis
• Running fully local, offline document conversion in regulated or air-gapped environments where cloud OCR/parsing APIs are not an option
• Wiring document parsing into an LLM agent via the built-in MCP server or the docling-serve API for on-demand conversion requests
• Batch-converting large mixed-format document sets (PDF, DOCX, PPTX, HTML, email, ODF) into a single consistent schema for search indexing

Under The Hood

Architecture Docling is organized around a DocumentConverter that dispatches each input to a FormatOption pairing a document backend (in docling/backend/, one per format — PDF, DOCX, HTML, email, ODF, XML dialects like JATS/XBRL, etc.) with a pipeline class (in docling/pipeline/: SimplePipeline for straightforward formats, StandardPdfPipeline/ThreadedStandardPdfPipeline for layout-heavy PDF processing, plus dedicated AsrPipeline, VlmPipeline, and VideoPipeline). Backends parse a source into an intermediate representation; pipelines run a sequence of models (layout, OCR, table structure, picture description) over that representation and assemble the unified DoclingDocument. Model selection is not hardcoded — OCR engines, layout models, table models, and picture-description models are registered through a plugin/factory system (docling/models/factories/, docling/models/plugins/) using Python entry points, so third parties can register additional engines without modifying Docling’s core. If the core DoclingDocument schema changed, every backend and every export path (Markdown/HTML/JSON/DocTags) would need to change with it, since it’s the single representation all formats converge on.

Tech Stack Docling is a Python 3.10+ package built with hatchling, structured as a monorepo (packages/docling, packages/docling-slim, packages/docling-client) where the published docling package is a thin meta-package pinning docling-slim[standard], which contains the actual docling module. Core dependencies are Pydantic v2 (data models), docling-core (the DoclingDocument schema itself), and docling-parse plus pypdfium2 for PDF backends; format support is split into granular optional extras (format-pdf, format-docx, format-pptx, format-html, format-email, etc.) so consumers only install what they need. OCR/VLM/ASR are pluggable via extras for EasyOCR, Tesseract, RapidOCR, and Whisper-family models. Tooling includes uv for dependency management, ruff for linting/formatting, and ty for type checking, all wired through pre-commit hooks.

Code Quality The repository has over 140 test files under tests/, covering individual backends (test_backend_html.py, test_backend_docx.py, etc.), pipelines, ASR engines, and API scaffolding, run through GitHub Actions across multiple CI workflows (ci.yml, ci-main.yml, ci-heavy-examples.yml, pr-fast-checks.yml). Pre-commit enforces ruff linting and formatting, a license-header check on every Python file, and ty static type checking configured to warn on all rule categories. Pydantic models are used extensively for both public data structures and internal pipeline options, giving strong runtime validation and type safety throughout.

API Design The public surface centers on one entry point — DocumentConverter().convert(source) — that accepts a local path, URL, or in-memory stream and returns a ConversionResult wrapping the unified DoclingDocument, from which callers call .export_to_markdown() or similar. This single-converter, single-document-model design keeps the common case to two lines of code while pipeline options, format options, and backend options remain available for advanced configuration. The same conversion path is exposed identically through the docling CLI, the MCP server, and the optional docling-serve API, so users pick an interface without learning a different mental model for each.