MinerU vs pdf-inspector
Heavyweight document-to-markdown/JSON parser — PDFs plus Office (docx/pptx/xlsx) through layout analysis and OCR into LLM-ready output for RAG and agentic pipelines. 73k stars, self-hostable. — versus — Firecrawl's Rust PDF triage: classifies text-based vs scanned in ~10-50ms, extracts positioned text and clean Markdown without OCR — routing the ~54% of PDFs that never needed a model.
Same PDF-to-Markdown slot, opposite weight: MinerU runs full layout analysis and OCR on everything; pdf-inspector is the 200ms no-ML path for documents that don't need it. Many pipelines should front MinerU with exactly this triage.
| MinerU | pdf-inspector | |
|---|---|---|
| Stars | 76k | 1.6k |
| Forks | 6.3k | 149 |
| Language | Python | Rust |
| License | NOASSERTION | MIT |
| Last activity | today | 6 days ago |
| Topics | ocr, rag | ocr, rag |
| Curated connections | 8 | 3 |
MinerU — the curator's take
The incumbent when document variety is the problem: beyond PDFs it handles Office formats, with mature layout analysis (reading order, tables, formulas) and a huge user base shaking out edge cases. NOT the lightest option — it's a full pipeline with model downloads and real hardware appetite; for a handful of clean PDFs a smaller tool is faster to stand up. Check the license (NOASSERTION on GitHub — AGPL-family, matters for commercial use).
pdf-inspector — the curator's take
The router your document pipeline is missing: most stacks OCR everything, but ~54% of PDFs are text-based — this classifies in tens of milliseconds (with confidence and per-page routing), extracts locally in under 200ms, and only the genuinely scanned pages go to an expensive OCR model. Pure Rust, one dependency, bindings for Python, Node and browser WASM. NOT an OCR engine and NOT a layout-analysis heavyweight: scanned documents still need a model downstream, and complex-layout fidelity trails ML parsers — its job is knowing when you don't need them.