What Is AnyDoc? Inside Firecrawl's Open-Source Document-to-Markdown Engine
AnyDoc is an open source Rust library from Firecrawl, first published on August 4, 2026, that converts office documents (Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV and PDFs with a real text layer) into clean GitHub-Flavored Markdown, with official bindings for Node.js, Python and the browser under an MIT license. It doesn't run OCR on your machine. Since version 0.2.4 (August 27, 2026), though, it tells you exactly which PDF pages are scanned images instead of quietly dropping them, and it can send just those files to Firecrawl's hosted OCR if you opt in. Its job is simple: take a real office file and hand back structured text an LLM can actually use. As of October 7, 2026, the GitHub repo shows more than 22,000 stars.
If you're building RAG pipelines, agents that need to read contracts and reports, or you've just been stuck cleaning up a folder full of .docx and .pptx files before feeding them into a model, this is worth ten minutes of your time. For the full map of this ecosystem, start with our AI tools for developers guide. Let's get into what it does, what it doesn't, how to run it, and when to reach for something else.
What problem is AnyDoc actually solving?
Anyone who has shipped a retrieval augmented generation (RAG) system has hit the same wall. LLMs handle Markdown and plain text well, but the real world produces .docx, .pptx, .xlsx, .odt and PDFs built on twenty year old formatting conventions. Turning that mess into something a model can index, without losing tables, headings and lists, is harder than it sounds. Every format has its own internal document model, and nobody wants to write a custom parser for each one twice.
Firecrawl, the company already known for its web scraping API that turns websites into clean context for AI agents, applied the same idea to desktop documents. AnyDoc detects the format from content markers rather than the file extension, so a mislabeled file still gets parsed correctly. It routes everything through one shared internal document model and outputs GitHub-Flavored Markdown that keeps tables, footnotes, headings and lists consistent across formats. It's the unglamorous piece every document AI pipeline eventually needs. Until now, most teams cobbled it together by hand with python-docx, openpyxl and duct tape.
How does it work under the hood?
The core is written in Rust, which explains most of its speed: Firecrawl's own benchmark reports a 4.4 ms median conversion time per document. On top of that core sit official bindings for:
- Node.js / TypeScript, published to npm as
@firecrawl/anydoc. - Python, published to PyPI as
firecrawl-anydocand imported asanydoc. - Browser, via WebAssembly (
@firecrawl/anydoc-wasm). - CLI, a runnable binary that ships in the same npm package.
- Native Rust, as a crate (
cargo add anydoc), for teams that want it inside their own binary without touching Node or Python.
Sharing one document model across every format is the interesting engineering call here. An Excel table and a table inside a Word doc come out the same way. No converter gets to invent its own table format.
Which formats does it support, and which does it not?
The supported extensions, as listed on PyPI for version 0.2.4:
- Word:
.doc,.docx,.docm. - PowerPoint:
.ppt,.pps,.pot,.pptx,.pptm,.ppsx,.ppsm. - Excel:
.xls,.xlsx,.xlsm,.xlsb. - OpenDocument:
.odt,.ods,.odp. - Rich Text Format:
.rtf. - EPUB:
.epub. - CSV:
.csv. - PDF:
.pdf, as long as the pages carry a real text layer. AnyDoc runs these through pdf-inspector, Firecrawl's PDF engine.
Firecrawl's own launch post (August 6, 2026) counts 14 formats in one binary, plus text based PDFs handled through pdf-inspector.
What AnyDoc still doesn't do locally is OCR, the step that reads text out of an image. A scanned PDF or a photo of a contract has no text to extract, just pixels. What changed in version 0.2.4 is how it handles that case. It used to skip scanned pages without telling you. Now the conversion stops and names the pages that need OCR: NeedsOcrError in Python, a needsOcr error in Node and the browser build, and exit code 3 on the CLI. If you opt in with ocr="hosted" (or --ocr hosted on the CLI), AnyDoc sends only the PDFs that fail that way to Firecrawl Parse, Firecrawl's hosted document API. No account is needed for that, and setting a FIRECRAWL_API_KEY raises the limits. So the short version is still true: AnyDoc parses digital documents, it doesn't digitize paper on your machine.
How do you actually install and use it?
As a CLI, no install required (npx pulls the prebuilt binary on first run):
npx @firecrawl/anydoc report.docx
npx @firecrawl/anydoc slides.pptx -o slides.md
cat data.csv | npx @firecrawl/anydoc - --format csv
npx @firecrawl/anydoc scan.pdf --ocr hostedThat last line is the opt in for scanned pages. Leave the flag off and nothing leaves your machine.
Global install if you'll be using it daily:
npm install -g @firecrawl/anydocIn Node.js / TypeScript:
import { toMarkdown } from '@firecrawl/anydoc';
const markdown = await toMarkdown('report.docx');In Python, install the package first. It installs as firecrawl-anydoc but imports as anydoc:
pip install firecrawl-anydocimport anydoc
markdown = anydoc.to_markdown("report.docx")
# Opt in to hosted OCR for scanned PDFs:
scanned = anydoc.to_markdown("scan.pdf", ocr="hosted")And if your stack is already pure Rust:
cargo add anydocThe README also documents toMarkdownBytes() for buffers held in memory, handy if the document arrives over HTTP and you don't want to touch disk. There's also toDocument(), which returns the structured document model instead of final Markdown, useful if you need to post process before writing it out. In Python those are to_markdown_bytes() and to_document().
How does AnyDoc relate to pdf-inspector and Firecrawl Parse?
This is where people get confused, so let's clear it up. Firecrawl introduced AnyDoc and pdf-inspector together in one launch post on August 6, 2026, as two sibling engines with a clean split of jobs. pdf-inspector is the Rust library for PDFs: it checks each page, extracts the text when it's there and flags the pages that need OCR. AnyDoc covers the office formats, OpenDocument, RTF, EPUB and CSV, and hands text based PDFs to pdf-inspector. Both engines power Firecrawl Parse (the /parse endpoint), the hosted API that adds OCR models and orchestration on top.
Here's the trade, stated plainly. Run the open source libraries yourself and you get full control and zero cost per page, but only as long as hosted OCR stays off. The moment you turn on ocr="hosted", the scanned document is uploaded to Firecrawl for processing. That's fine for public filings or old manuals. For confidential contracts, think about it first. Firecrawl's Parse page lists 1 credit per page and a free plan with 1,000 credits a month (as of October 7, 2026).
How does it stack up against LlamaParse, Docling, Unstructured, and MarkItDown?
| Tool | Engine / language | License | Cost | Strength | Weakness |
|---|---|---|---|---|---|
| AnyDoc (Firecrawl) | Rust | MIT, open source | Free (self-hosted) | Speed (4.4 ms median), one shared document model across formats | No local OCR; scanned PDF pages raise NeedsOcr unless you opt in to hosted OCR |
| pdf-inspector (Firecrawl) | Rust | MIT, open source | Free (self-hosted) | Specialized PDF classification/extraction | PDF only, no Office formats |
| LlamaParse (LlamaIndex) | Cloud API | Commercial | Credit-based (Fast tier from 1 credit/page) | Strong on complex PDFs with dense tables and layouts | Cost scales poorly at high volume |
| Docling (IBM / LF AI & Data) | Python, open source | Open / Linux Foundation | Free (self-hosted), compute only | Structure quality without per-page fees | Heavier to deploy than a single Rust binary |
| Unstructured | Library + API | Apache 2.0 (library) / commercial (API) | From ~$10/mo for 20K pages via API | Very wide format coverage, built for RAG pipelines | Structure quality drops on very complex layouts |
| MarkItDown (Microsoft) | Python, open source | Open source | Free | Simplicity, fast Markdown conversion | Less "document AI" depth than LlamaParse or Docling |
The short read: if your bottleneck is speed and office formats (Word, PowerPoint, Excel) and you want to self host without per page fees, AnyDoc is one of the fastest options right now. Is your real problem scanned PDFs or brutal layouts, like nested tables or multi column papers? Then LlamaParse still serves you better. So does AnyDoc paired with your own OCR step, or AnyDoc with hosted OCR turned on, if uploading those files is acceptable.
Who's actually building this? A quick look at Firecrawl
Firecrawl is the company behind a widely used API for turning websites into clean, LLM ready data. It came out of Y Combinator's S22 batch, according to its own site. Its founders are Caleb Peffer, Eric Ciarla and Nicolas Silberstein Camara, known on X as @nickscamara_, the account that announced AnyDoc. On August 19, 2025, the company announced a $14.5M Series A led by Nexus Venture Partners, with Y Combinator and angel investors including Tobias Lütke (founder of Shopify) and Abhinav Asthana (founder of Postman). On September 22, 2026, it announced a $75M Series B led by Smash Capital. AnyDoc isn't a weekend side project. It's open infrastructure that also powers Firecrawl's own paid document API.
Who should actually use AnyDoc, and who shouldn't?
It's a strong fit if you already build AI pipelines in Node, Python or Rust and need to turn office documents into Markdown without depending on a paid API. Think internal RAG systems, document analysis tools, or agents that process contracts and reports arriving as Word or Excel files. It also makes sense if you already use Firecrawl for web scraping and want the same "clean context for the LLM" idea applied to local files.
Scanned PDFs are now a judgment call rather than a dead end. If your pile is mostly photographed invoices or digitized paper contracts, AnyDoc will at least tell you which pages it couldn't read. From there you have two honest options. Turn on hosted OCR and accept that those files go to Firecrawl, or keep everything local and pair AnyDoc with Tesseract or a vision model you run yourself. It's also not the strongest pick for extremely complex layouts, like magazine style PDFs or multi column documents. Vision oriented tools like LlamaParse still lead on quality there, even at a higher cost per page. And if your team doesn't touch Node, Python or Rust and needs something no code, this isn't for you either: it's a developer library, not a SaaS with a UI.
The real risk is how young it is. The project is about two months old and ships fast: PyPI lists 14 releases between August 4 and August 27, 2026. Before wiring it into anything mission critical, write your own tests against your actual documents. Don't assume the README covers every edge case you'll hit in production.
Want to build exactly this kind of infrastructure, from data pipelines for AI to RAG and agents that read real world documents? That's the territory of AI Engineering for Devs at 4Geeks, where you work on shipping production AI systems, not just demos. You can see what that role involves in our AI Engineer guide, which maps out what it takes to work at this layer of the stack.
If your interest sits more on the data science side, structuring and modeling what comes out of a pipeline like this, Data Science & Machine Learning covers that next layer. Building coding agents that sometimes need to read a spec or a Word doc first? Our best coding agents in 2026 comparison helps you pick one. Still deciding which 4Geeks path fits where you're starting from? Our program comparison lays them out side by side.
For more of our coverage on developer facing AI tools like this one, see the AI Tools hub.
