chunkr vs olmocr
Document intelligence API in Rust: layout analysis, OCR with bounding boxes, and semantic chunking that turn PDFs, PPTs and Word docs into RAG-ready structured chunks. — 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.
Both parse hard documents for AI consumption; olmocr bets on a VLM end-to-end, Chunkr on a layout-analysis pipeline with structured outputs and citations.
| chunkr | olmocr | |
|---|---|---|
| Stars | 4.0k | 19k |
| Forks | 263 | 1.6k |
| Language | Rust | Python |
| License | AGPL-3.0 | Apache-2.0 |
| Last activity | 3 months ago | 3 months ago |
| Topics | ocr, rag | rag, ocr |
| Curated connections | 5 | 8 |
chunkr — the curator's take
The RAG-ingestion specialist: where OCR tools stop at text, Chunkr does layout analysis and SEMANTIC chunking — the chunks arrive respecting document structure, with bounding boxes for citation-grounding. Self-hosted via Docker Compose. Read the split carefully though: the AGPL open-source version runs community models while the paid cloud runs proprietary ones — the README says plainly the accuracy differs; benchmark the OSS tier on YOUR documents before committing. Also ~3 months quiet at review time, and AGPL matters if you embed.
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.