Document parsing for RAG in 2026: revisit Docling, Unstructured and Marker before you feed another PDF to your AI pipeline

Most retrieval-augmented generation (RAG) projects start with a quick demo: load a few PDFs, split the text every 1,000 characters, push the chunks into a vector store and ask questions. The demo works. Then the real documents arrive: scanned KYC forms, two-column research papers, PowerPoint decks, Excel annexures and policy PDFs with tables that run across pages. The answers become vague or plainly wrong, and the team starts tuning prompts and embeddings when the real problem sits one step earlier. The parser never read the document properly.

In this post we revisit three active open-source document parsing projects, Docling, Unstructured and Marker, and look at history, licences, architecture, output formats, operations and security.

This is not a ranking. No benchmark or hands-on drill was run for this post; the facts come from each project’s own GitHub repository, README, LICENSE and release pages as of early November 2026. Where a project publishes accuracy numbers, we label them as that project’s own run. We also do not repeat neighbouring layers. For where the chunks go next, read our earlier post on vector search with pgvector, Qdrant, Milvus and Weaviate. For running the models yourself, see LLM inference serving with vLLM, SGLang and llama.cpp. For tracing the full RAG chain, see LLM observability with Langfuse, Arize Phoenix and OpenLIT. If you only need to archive and search scanned paperwork for humans, our post on Paperless-ngx, Mayan EDMS and Docspell covers that job.

Why revisit document parsing now

All three projects release often, and the recent releases are a good moment to check your assumptions:

• Docling v2.148.0 was released on 5 November 2026 (IST). The project has moved to the docling-project organisation on GitHub and is now hosted in the LF AI and Data Foundation. The code is MIT-licensed.
• Unstructured 0.27.36 (the open-source unstructured Python library) was released on 30 October 2026 (IST). The library is Apache-2.0. The README now states plainly that the library stays free, while the company’s newer models are offered through its hosted Transform API.
• Marker v2.1.0 was released on 29 October 2026 (IST). The code is Apache-2.0, but the model weights use a modified OpenRAIL-M licence with commercial limits. That split is the single most important thing to read before you adopt it.

Parsers changed a lot in two years. Many now run small vision language models (VLMs) for layout and OCR instead of only classic rules plus Tesseract. That improves quality on hard pages, but it also changes hardware needs, licences and where your data travels.

Shared concepts before you compare

Unlearn the idea that “PDF to text” is a solved utility. For RAG, a parser has several separate jobs:

• Text layer versus OCR. Born-digital PDFs carry a text layer you can extract directly. Scanned pages need OCR. Some digital PDFs carry broken or garbled text, so a good parser detects bad text and falls back to OCR only where needed.
• Layout and reading order. Two-column pages, headers, footers, sidebars and footnotes must be put in the right order, or chunks mix unrelated sentences.
• Tables. A table flattened into one line of numbers is nearly useless for retrieval. Check whether the tool keeps rows and columns (as Markdown, HTML or structured JSON).
• Structure and metadata. Headings, page numbers, element types and bounding boxes help you build better chunks and show citations back to the source page.
• Chunking. Structure-aware chunking (by heading or section) usually beats fixed character windows. Some parsers ship their own chunkers.
• Model weights and licences. The code licence and the model licence can differ. Your legal review must cover both.
• Data location. A parser that calls a hosted API or a hosted LLM sends your documents outside your network. Treat that like any other data transfer decision.

Compare these jobs on your own documents, not on the demo page.

Docling

Docling started at IBM Research (repository created 9 July 2024) and is now a project in the LF AI and Data Foundation. It is a Python library and CLI that converts many formats into a unified DoclingDocument representation, which you then export as Markdown, HTML, lossless JSON or DocTags.

What it does well

• Wide format coverage. The README lists PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, LaTeX, email formats, OpenDocument files, audio formats and more. One library for most of the files a company actually stores.
• Rich PDF understanding. Layout analysis, reading order, table structure, code, formulas and image classification are part of the standard pipeline, with several OCR options for scanned pages.
• Optional VLM pipeline. You can switch to a vision language model such as GraniteDocling (a small IBM model) through the CLI for hard pages.
• Local and air-gapped use. The project highlights local execution for sensitive data. Models can be downloaded ahead of time for offline machines.
• Ecosystem fit. Integrations exist for LangChain, LlamaIndex, Crew AI and Haystack. There is an API server (docling-serve) and an MCP server for agent use, plus built-in chunkers that respect document structure.

What to check before you commit

• Model licences. The Docling code is MIT, but the README says individual models follow their own licences. List every model your pipeline downloads and check each one.
• Resource use. Layout and table models run faster on a GPU. Measure pages per minute on your own hardware before you promise a backlog clearance date.
• Release pace. Version numbers move quickly. Pin versions in production and read release notes before upgrades, because output structure changes can alter your chunks and embeddings.

Unstructured

Unstructured is the oldest of the three (repository created 26 September 2022). The open-source unstructured library provides partition functions that turn files into a list of typed elements (titles, narrative text, list items, tables and so on), plus cleaning and chunking helpers. The company behind it also runs a commercial platform and API.

What it does well

• Element-based model. Each element carries a type and metadata such as page number and file name. This makes filtering (for example, dropping headers and footers) and citation simple.
• Many file types through one interface. Partition functions cover PDFs, images, HTML, email, Word, PowerPoint, plain text and more, with an auto partition that picks the right path.
• Partition strategies. For PDFs and images you choose between faster text-layer extraction and slower, model-based high-resolution or OCR paths, so you can trade speed for quality per document class.
• Chunking helpers. Built-in chunking can follow titles and sections instead of raw character counts.
• Container option. Official Docker images are published for x86_64 and Apple silicon, which helps keep system dependencies consistent across teams.

What to check before you commit

• System dependencies. Full document support needs packages such as poppler-utils, tesseract-ocr and libreoffice. Install only the extras you need (for example unstructured[docx,pptx]) to keep images small.
• Open-source versus hosted quality. The README itself says the hosted Transform API uses newer models and gives better table and text accuracy than the library. Those figures are the vendor’s own comparison. Decide early whether you will stay on the library or call the API, because calling the API sends documents to an external service.
• Upgrade discipline. The library is still on 0.x versions. Pin versions and run a small regression set of documents before each upgrade.

Marker

Marker is built by Datalab (repository created 30 October 2023). It converts PDFs, and with extra dependencies other document types, into Markdown, JSON, HTML or chunks. Its focus is high-quality output for books, papers and complex layouts, including tables, forms, equations and code blocks.

What it does well

• Quality modes. A fast mode is tuned for CPU and uses the PDF text layer with minimal VLM work. A balanced mode, best on a GPU, uses the Surya VLM for layout and re-runs OCR on pages with bad text. A --disable_ocr switch turns off all VLM calls for pure text-layer extraction.
• Local inference server. Layout, OCR and table recognition run through a local inference server that Marker can start for you (vLLM on NVIDIA GPUs, llama.cpp elsewhere), or you can point it at a server you already run.
• Optional LLM assist. A --use_llm flag adds an LLM for merging tables across pages, inline maths and form values. It supports hosted providers and local Ollama models.
• Published benchmark. The README reports scores on olmocr-bench, a third-party benchmark set from AllenAI, and says Marker balanced mode scores ahead of some other parsers. Treat this as the Marker team’s own run on that benchmark, and repeat a small version on your documents.

What to check before you commit

• Model weight licence. The README states the weights use a modified OpenRAIL-M licence that is free for research, personal use and startups under a funding or revenue limit, with commercial use beyond that through Datalab’s pricing. Many Indian mid-size companies will cross that limit. Get this cleared before you build on it.
• Default LLM is hosted. When --use_llm is on, the README says the default model is a hosted Gemini model. Switch to a local model or keep the flag off for confidential documents.
• GPU planning. Balanced mode is designed for a GPU. Size hardware and queue depth for your daily page volume.

Security and privacy

Documents fed into RAG are often the most sensitive files you have: contracts, salary letters, Aadhaar or PAN copies, audit reports and customer tickets.

• Keep parsing inside your network by default. All three can run locally. Any hosted API or hosted LLM call should be an explicit, reviewed choice, not a default.
• Isolate the parser. Parsers open untrusted files with complex libraries. Run them in containers with no outbound internet, limited memory and a time limit per document.
• Mask before you embed. Apply PII masking after parsing and before chunks reach the vector store or a prompt. Deleting a vector later does not remove copies in backups and logs.
• Keep provenance. Store file ID, page number and parser version with every chunk, so you can trace a wrong answer back to a page and re-parse when needed.

When to pick which

• Pick Docling when you want a permissive MIT code base under a neutral foundation, broad format coverage, structure-aware chunking and local or air-gapped runs.
• Pick Unstructured when your pipeline already thinks in typed elements, you need many file types with one interface, or you may later move heavy documents to the vendor’s hosted API.
• Pick Marker when output quality on complex PDFs (papers, books, equations, tables) is the main goal and you have cleared the model weight licence for your company size.
• Use more than one when document classes differ. A simple router by file type or source system is often better than forcing one parser on everything.

An example: a Vadodara insurance broker

Consider an invented insurance broker in Vadodara with around 120 staff. They want an internal assistant that answers questions from policy wordings, endorsements and claim circulars. About half the documents are born-digital PDFs from insurers; the rest are scanned letters and Excel annexures.

A sensible revisit would look like this:

• Learn. Collect 50 representative documents, including the worst scans and the longest tables.
• Unlearn. Drop fixed 1,000-character chunks as the default and stop blaming the embedding model first.
• Re-learn. Parse the same 50 documents with two candidate tools, read the Markdown by eye, and note table, reading-order and OCR errors.
• Practise. Build structure-aware chunks, run 30 real questions from claims staff, and compare answers with page citations.
• Apply. Pick the parser per document class, pin versions, keep everything local, and record parser version in chunk metadata.

The broker should also get a written opinion on model licences before production, since one weight licence alone can change the decision.

Practical checklist

• List your document types and estimate monthly page volume.
• Read both the code licence and every model licence your pipeline downloads.
• Confirm where documents travel: local only, hosted API, or hosted LLM.
• Test on your hardest 50 documents, not on sample papers.
• Check tables, reading order, headers and footers, and scanned pages separately.
• Use structure-aware chunking and store page numbers for citations.
• Run the parser in an isolated container with resource and time limits.
• Mask PII before embedding.
• Pin versions and keep a regression set for upgrades.
• Plan a re-parse path, because parsers will keep improving.

Closing thought

A RAG system cannot be better than the text it retrieves, and that text is decided by the parser. Docling, Unstructured and Marker all improved fast, but they differ in licences, hardware needs and where your data goes. Revisit the parsing step with your own documents, write down why you chose a tool, and re-test it at every upgrade. That small habit saves many weeks of prompt tuning later.