marker vs olmocr
Datalab's 39k-star PDF-to-Markdown/JSON converter: a layout pipeline plus an optional LLM pass for tables, forms and equations, with chunk output and form-value extraction built in. — versus — Open toolkit that linearizes messy PDFs — scans, tables, equations, handwriting — into clean ordered Markdown with a self-hosted vision-language model. Built for LLM training data and RAG ingestion.
olmOCR runs one vision-language model over every page; marker runs layout analysis first and calls a model only where needed — cheaper at corpus scale, weaker on truly messy scans.
| marker | olmocr | |
|---|---|---|
| Stars | 39k | 19k |
| Forks | 2.8k | 1.6k |
| Language | Python | Python |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | 17 days ago | 5 months ago |
| Topics | ocr, rag | rag, ocr |
| Curated connections | 7 | 12 |
marker — the curator's take
The default answer when you need a lot of documents turned into clean Markdown on your own hardware: fast per page, tuned by people who do this for a living, and it can call Gemini/Claude/OpenAI-compatible/Ollama models only on the blocks that need help. Two caveats before you ship it: the code is Apache-2.0 but the model weights are OpenRAIL-M (free for research, personal use and companies under $5M funding/revenue), and on genuinely nasty input — scans, handwriting, dense multi-column tables — Datalab's own VLM chandra beats it. Born-digital corpus and no appetite for model calls? Use a deterministic parser instead.
olmocr — the curator's take
Reach for olmocr when you have lots of messy PDFs to convert into high-quality text for a training corpus or RAG index and you have GPU to run the VLM. It is the parsing FRONT-END of a pipeline, not a RAG system itself — pair it with an indexer/retriever (LlamaIndex) and a vector store (Chroma). NOT worth it for clean, digital-native PDFs where a cheap text extractor does the job — running a vision-language model for those is overkill.