What Is AnyDoc? Inside Firecrawl's Open Source Document to Markdown Engine AnyDoc is an open source Rust library from Firecrawl, released on August 4, 2026, that converts office documents, Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and text based PDFs, into clean, GitHub Flavored Markdown, with official bindings for Node.js, Python, and the browser under an MIT license. It is not an OCR engine and it won't turn a scanned photo into text on its own; its job is to take a real office file and hand back structured text an LLM can actually use. In its first week alone it went from zero to roughly 11, 900 GitHub stars, making it one of the most talked about developer tool launches of August 2026. If you're building RAG pipelines, agents that need to read contracts and reports, or you've just been stuck normalizing a folder full of and 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 . Let's get into what it actually does, what it doesn't, how to run it, and when to reach for something else instead. 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 reasonably well, but the real world produces , , , , and PDFs built on twenty year old formatting conventions. Turning that mess into something a model can index, without losing tables, headings, and lists along the way, is harder than it sounds, because every format has its own internal document model, and nobody wants to write a bespoke 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 philosophy to desktop documents. AnyDoc detects file format from content markers rather than the file extension , so a renamed to still gets parsed correctly, routes it through a shared internal document model, and outputs GitHub Flavored Markdown that preserves tables, footnotes, headings, and lists consistently across formats. It's the unglamorous but necessary infrastructure piece every document AI pipeline eventually needs, and until now most teams cobbled it together by hand with , , 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 . Python , the module. Browser , via WASM. CLI , the same npm package ships a runnable binary. Native Rust , as a crate ( ), for teams that want it baked directly into their own binary without touching Node or Python. The decision to share one document model across every format is the interesting engineering call here: an Excel table and a table embedded in a Word doc both end up represented the same way in the output Markdown, instead of each converter inventing its own serialization logic for tables. Which formats does it support, and which does it not? Confirmed formats from the repo and official docs: Microsoft Office : Word ( / ), PowerPoint ( / ), Excel ( / ). OpenDocument : , , . RTF . EPUB . CSV . Text based PDFs (with a selectable text layer), routed partly through Firecrawl's PDF engine. A third party breakdown (Wavect) puts the total at 14 supported formats once you count variants. What AnyDoc does not do on its own is OCR: feed it a scanned PDF or a photo of a document with no text layer, and there's nothing to extract, because there's no text to begin with, just pixels. For that case, Firecrawl routes through OCR inside its hosted API. That distinction matters if you're describing this tool internally: it parses digital documents, it doesn't digitize paper. How do you actually install and use it? As a CLI, no install required (npx pulls the prebuilt binary on first run): Global install if you'll be using it daily: In Node.js / TypeScript: In Python: And if your stack is already pure Rust: The README also documents for working directly with in memory buffers, handy if the document arrives over HTTP and you don't want to touch disk, and , which returns the structured document model instead of final Markdown, useful if you need to post process before serializing. How does AnyDoc relate to pdf inspector and /parse? This is where people get confused, so it's worth clearing up: Firecrawl shipped AnyDoc and pdf inspector on the same day (August 4, 2026), as two sibling engines with a clean split of responsibilities. pdf inspector is the dedicated Rust library for classifying and extracting text from PDFs (distinguishing text based PDFs from scanned ones). AnyDoc covers everything else, Office formats, OpenDocument, RTF, EPUB, CSV, and hands off text based PDF handling to pdf inspector. Both engines power Firecrawl's hosted endpoint, which layers OCR and orchestration on top for teams that would rather n