markitdown vs anydoc - Document-to-Markdown Compared
markitdown and anydoc are the two open-source "document-to-Markdown" tools most often compared — one from Microsoft, one from Firecrawl, both free, both promising clean text for LLMs. But when you actually run a batch of real documents through them, the gap is an order of magnitude.
This page is based on Firecrawl's official benchmark (100 real documents across 14 formats, seven tools compared head-to-head). Data first, then conclusions — no hype on either side.
Key metrics at a glance
| Metric | anydoc | markitdown | Notes |
|---|---|---|---|
| Made by | Firecrawl (open-source Rust library) | Microsoft (open-source Python library) | Different ecosystems |
| Format coverage | 14/14 | 6/14 | Measured in the official benchmark |
| Median conversion time | 4.4ms | 134.8ms | 30x+ faster |
| Overall score (out of 100) | 81 | 33 | Completeness / structure / fidelity / cleanliness |
| Completeness (information kept) | 87 | 65 | The metric that matters most for LLM input |
| Cleanliness | 81 | 60 | Noise removal |
| Structure | 79 | 78 | Roughly even |
| Fidelity | 78 | 66 | anydoc ahead |
| Language bindings | Rust / Node / Python / WASM / CLI | Python (plus CLI and .NET ports) | anydoc: five bindings |
| Agent integration | One command (Agent Skill) | DIY wrapping | anydoc is plug-and-play |
| Conversion method | Fully local, no dependencies (no LibreOffice/OCR/ML) | Python ecosystem, extensible plugins | Different deployment complexity |
Source: official anydoc benchmark (100 real documents, 14 formats).
The short version
- Want every format supported, converted fast and clean, and LLM-ready → choose anydoc. Full format coverage, an order-of-magnitude speed lead, and higher quality across the board, with five bindings plus Agent Skill support for AI workflows.
- Already living in a Python project and only need Office's big three (docx/xlsx/pptx) with Microsoft-ecosystem tooling → markitdown still works — mature community, rich plugins — but accept the 6/14 coverage and the 30x speed gap.
What each one really is
markitdown
Open-sourced by Microsoft (github.com/microsoft/markitdown) as a "Python library + CLI" that converts common formats to Markdown for LLM consumption. Its strengths:
- Mature ecosystem: high community traction since its 2024 release, familiar to Python developers, plenty of docs and third-party integrations
- Extensible: plugin system for additional formats (e.g. OCR plugins for image-based PDFs)
- Microsoft backing: used inside Microsoft tooling (e.g. Copilot-adjacent workflows)
Its measured costs:
- 6/14 format coverage: Word, PPT, Excel, PDF, CSV, EPUB and more are covered, but OpenDocument (odt/ods/odp), RTF, xlsb and others are missing
- 134.8ms median — an order of magnitude slower than anydoc, noticeable in batch pipelines
- Overall score 33, with completeness at 65 (higher information loss — a real problem when feeding LLMs)
- Python runtime required; some formats call online services (e.g. image description), needing network access
anydoc
Open-sourced by Firecrawl (github.com/firecrawl/anydoc) as a "Rust conversion engine + five bindings", and the engine behind Firecrawl Parse. Its strengths:
- Full 14/14 format coverage — the only converter in the benchmark that handles every format
- Millisecond speed: 4.4ms median, pure local Rust parsing — no LibreOffice, no OCR service, no ML models
- Best-in-class quality: a completeness score of 87 means minimal information loss — exactly what "document → LLM" needs
- Five bindings: Rust / Node.js / Python / browser (WebAssembly) / CLI, one API everywhere
- Agent-ready:
npx skills add firecrawl/anydocand Claude Code / Codex / Cursor read office documents directly
Deep dive, point by point
1. Format coverage: 14 vs 6
| Format | anydoc | markitdown |
|---|---|---|
| Word (.doc/.docx/.docm) | ✅ | ✅ |
| PowerPoint (7 variants incl. .ppt/.pptx) | ✅ | ✅ |
| Excel (.xls/.xlsx/.xlsm/.xlsb) | ✅ | ✅ |
| OpenDocument (.odt/.ods/.odp) | ✅ | ❌ |
| RTF | ✅ | ❌ |
| EPUB | ✅ | ✅ |
| CSV | ✅ | ✅ |
| PDF (text-based) | ✅ | ✅ |
If you only touch the Office big three, both work. The moment OpenDocument, RTF, or xlsb shows up, markitdown simply doesn't support it — anydoc handles the whole set on one code path.
2. Speed: 4.4ms vs 134.8ms
Why the 30x gap:
- anydoc is pure native Rust — no interpreter overhead, no process boundaries
- Every format parses into one unified document model with one serializer — no format-to-format conversions
- Headers, footers, and page numbers are stripped by design — no wasted work
In real-time parsing, batch pipelines, and agent loops, this is the difference between "works" and "painfully slow".
3. Quality: 81 vs 33 — completeness is the problem
Four benchmark dimensions (out of 100):
| Dimension | anydoc | markitdown |
|---|---|---|
| Completeness | 87 | 65 |
| Structure | 79 | 78 |
| Fidelity | 78 | 66 |
| Cleanliness | 81 | 60 |
| Overall | 81 | 33 |
A 22-point completeness gap means the Markdown you feed an LLM systematically loses information — merged cells, nested lists, footnotes, and speaker notes drop out more often. The structure scores are close (79 vs 78), so both tools do well on the formats they support; the overall gap comes from coverage shortfalls and information retention.
4. Ecosystem & integration
- markitdown: Python-only ecosystem; CLI + library; plugins; Microsoft-maintained; lots of community tutorials
- anydoc: Rust native plus Node/Python/WASM/CLI ports; browser builds convert fully locally — files never leave the device; Agent Skill in one command for Claude Code / Codex / Cursor; MIT-licensed like markitdown, so commercial use is free
5. LLM / Agent workflows
- anydoc is designed for LLM consumption ("completeness first, noise stripped") and ships an Agent Skill
- markitdown needs DIY wrapping as a tool function, and its completeness shortfall grows on long documents
Which one should you pick?
| Your scenario | Recommendation | Why |
|---|---|---|
| Any format, including ODF/RTF/xlsb | anydoc | 14/14 coverage |
| Batch pipelines / real-time / high throughput | anydoc | 30x faster |
| Feeding LLMs / agents for document understanding | anydoc | Completeness 87 + Agent Skill |
| Sensitive documents, files must never leave the device | anydoc | Browser WASM converts locally |
| Python project, Office big three only | either | markitdown feels familiar; anydoc is faster and more complete |
| Scanned PDFs needing OCR | neither alone → Firecrawl Parse | same engine as anydoc + OCR |
FAQ
Can I use both?
Yes. Let anydoc handle the Office/PDF/ODF family, and use markitdown's plugin ecosystem for edge cases (e.g. HTML cleanup). Both are MIT, so mixing is fine.
Does markitdown handle scanned PDFs?
Not natively — it needs OCR/LLM-description plugins. anydoc explicitly returns Unsupported for image-only PDFs; if you need OCR, Firecrawl Parse layers it onto the same conversion pipeline.
Which is faster to get started?
For "one command and go": anydoc's CLI (npx @firecrawl/anydoc report.docx) and Agent Skill are the fastest. markitdown needs pip install markitdown plus a Python environment. For Python familiarity, markitdown feels more natural to Python developers.
Can I trust the benchmark numbers?
Two cross-checks: the Firecrawl benchmark is public and reproducible (the bench harness ships in the repo), and the 4.4ms vs 134.8ms gap matches the engineering reality (native Rust vs interpreted Python). You can also run your own document set — anydoc's repo includes the benchmark tooling.
Next steps
- Feel the speed first: convert a document online
- Integrate it: install for your language
- See all seven tools: back to the benchmark