AnyDoc vs Unstructured vs Docling vs MarkItDown: which document parser for your AI agent stack (August 2026)

The number making the rounds since early August is that Firecrawl's new AnyDoc converts documents about 100x faster than Docling, per its published benchmark. It is real, and it is the wrong thing to shop on, because AnyDoc and Docling barely do the same job.

Here is the verdict before you scroll. For high-volume Office file ingestion, meaning Word, Excel, PowerPoint, EPUB, and text-based PDF, AnyDoc is the pick and it isn't close. For scanned PDFs, academic papers, and anything where the text lives inside a page image, Docling wins, because it runs the layout-aware OCR that AnyDoc flatly refuses to do. For a RAG pipeline that needs each chunk tagged by element type (title, table, list item), Unstructured earns its slower runtime. MarkItDown is the middle option: a Python shop that wants one lightweight dependency and can live with narrower format coverage.

The four tools get lumped into one benchmark table, so they read like a race. They aren't. Pick the lane first, then the tool.

The benchmark everyone is quoting, and its one honest caveat

Firecrawl designed and ran the benchmark being cited across the launch coverage: seven converters, 100 real-world documents spanning 14 formats, quality graded blind by Claude Sonnet 5 on completeness, structure, formatting, and cleanliness, per the AnyDoc README. Say this once and move on: it is the vendor's own benchmark and the document corpus is not published, so you cannot reproduce the exact scores. The methodology and the full per-format breakdown are in the repo, which is more than most vendor benchmarks show, and the shape of the result matches what each tool is built to do.

Parser	Formats	Median speed	Overall score (0-100)	Source
AnyDoc	14/14	4.4 ms	81	Firecrawl
MarkItDown	6/14	134.8 ms	65	Firecrawl
Unstructured	8/14	572.9 ms	63	Firecrawl
Docling	4/14	513.6 ms	57	Firecrawl

Source: Firecrawl AnyDoc benchmark, 100 documents, Claude Sonnet 5 judge, retrieved August 28, 2026. Speeds are median time to convert one document.

One asterisk on the "81 vs 70" line you will see repeated: the next-highest overall score, a 70, belongs to mammoth, which parses docx and nothing else. Each tool's score averages only the formats it supports, so a single-format library gets an easy average. Read the per-format column instead, where AnyDoc leads on every format it was scored against. The takeaway is not that AnyDoc is 26% better than Docling at Docling's job. It is that these tools cover different formats at wildly different speeds, and the overlap is smaller than the table suggests.

AnyDoc: the Office-format speed play

AnyDoc is a from-scratch Rust library that turns 14 document formats into GitHub-Flavored Markdown with a single call, no API key, no system dependencies, per Firecrawl's launch post. It covers the Word, Excel, PowerPoint, OpenDocument, RTF, EPUB, and CSV families, plus text-based PDF, which it routes through its sibling library pdf-inspector under the hood. The repo is MIT-licensed and sitting at roughly 18,900 GitHub stars a little over three weeks after its August 3 launch, per the GitHub repo on August 28, 2026.

The speed comes from a design choice, not a model. A technical teardown by SnackOnAI (August 7, 2026) walks the dependency list and finds nine Rust crates and zero AI: no torch, no ONNX runtime, no model weights. A .docx is a ZIP of XML that already declares its tables and lists; a legacy .doc is a compound file with style data baked in. AnyDoc reads the structure the file states about itself rather than inferring it from a rendered page, which is why the median lands at 4.4 ms while OCR-based tools spend hundreds of milliseconds rediscovering layout the office format already spelled out.

The candid con is the same teardown's most useful finding. AnyDoc does not process scanned documents at all. Hand it a rasterized page and it fails in single-digit milliseconds with an explicit "OCR is required" error and the page count, per SnackOnAI's local run. That is the correct behavior for a cheap first stage in a router, but it means AnyDoc is not a scanned-PDF tool, full stop. Second con for RAG builders: on a table with a merged header cell, AnyDoc keeps the grid honest but renders the covered slot blank, so the header association is lost. Docling makes the opposite call.

Docling: the one that actually reads the page

Docling is the pick the moment a page is a scan. It runs layout-aware OCR, using an object-detection model over the page bitmap to find tables, headings, and reading order, per the Docling technical report. That is why it sits at 513.6 ms median in the benchmark and covers only 4 of the 14 formats: it is doing computer vision, not XML parsing.

The tradeoff is right there in the numbers. If your inputs are clean Office files, you are paying a 100x latency tax for OCR you don't need, and Docling scored below MarkItDown on the mixed corpus. But for the job it is built for, it does something AnyDoc cannot. On a spanning header, the Docling report repeats the header value across each column it covers, so a table chunked into a vector index stays self-describing. For scanned contracts, research PDFs, and complex table layouts, Docling is the tool. Pick based on whether a human or a retriever reads the output.

Unstructured: the RAG-native option

Unstructured lands in the middle of the same Firecrawl benchmark at 8 of 14 formats, a 572.9 ms median, and a 63 overall score. On raw markdown quality per format, it does not beat AnyDoc. What the benchmark does not measure is the reason people reach for it: Unstructured partitions a document into typed elements (title, narrative text, list item, table) rather than emitting one flat markdown string, and it supports OCR for scanned pages through its higher-resolution strategy.

For a retrieval pipeline, that element typing is the whole point. You can chunk on real semantic boundaries and filter by element type before embedding. The candid con is cost in both senses: it is the slowest of the four on Office files, and its managed API and heavier dependency footprint are more machinery than a straight file-to-markdown job needs. Want only clean text out? Unstructured is overkill. Need structured elements in? It earns the runtime.

MarkItDown: the lightweight Python default

Microsoft's MarkItDown scored 65 overall on 6 of 14 formats at a 134.8 ms median in the same benchmark, making it the fastest of the three non-AnyDoc tools here and the best-scoring alternative on the mixed corpus. It is a small, Python-native dependency that handles the common Office formats and a broad grab-bag of others, which is exactly what a lot of teams actually want.

Where it breaks down is coverage and ceiling. Six of 14 formats, per Firecrawl's benchmark, means the older and OpenDocument variants fall to something else, and MarkItDown does not do layout-aware OCR for scanned PDFs. For a Python service processing a moderate volume of ordinary documents, it is a sensible default. Push into legacy formats or high throughput and AnyDoc's 14/14 coverage and Rust speed pull ahead.

Use-case picks

Office file batch ingestion at volume. AnyDoc. Fourteen formats in one dependency-free binary at a 4.4 ms median, no GPU, per the Firecrawl benchmark. Nothing else here is in the same speed class, and the format coverage means you stop stitching libraries together.

Scanned PDFs and image-heavy documents. Docling. It is the only tool in this group built to read a page image, with a documented approach to preserving table semantics for downstream retrieval. AnyDoc will hand these straight back with an OCR-required error, by design.

RAG chunking that needs typed elements. Unstructured, if you want element typing and OCR in one tool and can absorb the latency. When you only need clean text to chunk and your inputs are Office files, AnyDoc plus your own splitter is faster and cheaper.

When to reach for Firecrawl /parse instead

Self-hosting AnyDoc is free under MIT, and for a pure Office-format pipeline that is often all you need. The wall you hit is scanned PDFs: AnyDoc classifies them and stops, so someone still has to run OCR. That is the seam Firecrawl's hosted /parse fills. It classifies each page first, routes text pages to the same fast local path, and sends only the scanned pages to a GPU-backed OCR engine, per Firecrawl's launch post. If you already send documents to Firecrawl's /parse or /scrape, you are running AnyDoc and pdf-inspector today with no config change.

Pricing is metered on Firecrawl's standard credit plans, not a separate parsing SKU: a free tier at 1,000 credits per month, then Hobby (5,000), Standard (100,000), Growth (500,000), Scale (1,000,000 credits at $599 per month billed yearly), and a custom Enterprise tier, per the Firecrawl pricing page as of August 2026. Scrape and parse calls consume roughly one credit per page, so the managed option makes sense once the OCR routing and the "one API for everything" convenience outweigh running your own GPU stage.

For a mixed pipeline where half the PDFs are scanned, you can start on Firecrawl's free tier and let it route text pages to AnyDoc and scanned pages to OCR through the same call. Full transparency: Firecrawl runs an affiliate program and Pondero may earn a commission if you sign up through that link, which does not change the picks above.

The decision matrix

Tool	Formats	Speed (median)	OCR / scanned PDFs	Best for	Source
AnyDoc	14/14	4.4 ms	No (flags scanned pages, routes text PDF to pdf-inspector)	High-volume Office file ingestion, no GPU needed	Firecrawl
Unstructured	8/14	572.9 ms	Yes (OCR strategy)	RAG pipelines needing typed element extraction (title, table, list)	Firecrawl
MarkItDown	6/14	134.8 ms	No	Python-centric workflows, broad format mix at moderate volume	Firecrawl
Docling	4/14	513.6 ms	Yes (layout-aware)	Scanned PDFs, academic papers, complex table layouts	Firecrawl

Source: Firecrawl AnyDoc benchmark (100 documents, Claude Sonnet 5 judge, August 2026); OCR and use-case detail from the Firecrawl launch post, the Docling technical report, and SnackOnAI's teardown. The benchmark corpus is Firecrawl's own and is not redistributable.

Take one thing away from this: stop treating it as a speed contest. Route your documents by type first. Office files go to AnyDoc, scans go to Docling or a hosted OCR router, and RAG-with-element-typing goes to Unstructured. The 100x number is true and mostly irrelevant to which tool you should run.