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 .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 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 .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 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 .doc renamed to .txt 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 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, the anydoc module.
• Browser, via WASM.
• CLI, the same npm package ships a runnable binary.
• Native Rust, as a crate (cargo add anydoc), 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 (.doc/.docx), PowerPoint (.ppt/.pptx), Excel (.xls/.xlsx).
• OpenDocument: .odt, .ods, .odp.
• 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 /parse 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):

npx @firecrawl/anydoc report.docx
npx @firecrawl/anydoc slides.pptx -o slides.md
npx @firecrawl/anydoc - --format csv < data.csv

Global install if you'll be using it daily:

npm install -g @firecrawl/anydoc

In Node.js / TypeScript:

import { toMarkdown } from '@firecrawl/anydoc';
 
const markdown = await toMarkdown('report.docx');

In Python:

import anydoc
 
markdown = anydoc.to_markdown("report.docx")

And if your stack is already pure Rust:

cargo add anydoc

The README also documents toMarkdownBytes() for working directly with in-memory buffers, handy if the document arrives over HTTP and you don't want to touch disk, and toDocument(), 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 /parse endpoint, which layers OCR and orchestration on top for teams that would rather not build their own parsing infrastructure.

In other words: if you want full control and zero cost per page, you run the open-source libraries yourself (AnyDoc + pdf-inspector). If you'd rather not think about it, including OCR for scanned files, you pay for /parse.

How does it stack up against LlamaParse, Docling, Unstructured, and MarkItDown?

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 currently one of the fastest options out there. If your real problem is scanned PDFs or brutal layouts, nested tables, multi-column academic papers, you're still better served by LlamaParse, or by pairing AnyDoc with a separate OCR step.

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, and is founded by 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 participation from Y Combinator and angel investors including Tobias Lütke (founder of Shopify) and Abhinav Asthana (founder of Postman); Firecrawl states $16.2M in total funding to date. AnyDoc isn't a weekend side project, it's infrastructure backing a Series A-funded company that has already shown real traction in the "web data for AI" space.

Who should actually use AnyDoc, and who shouldn't?

It's a strong fit if you're already building AI pipelines in Node, Python, or Rust and need to normalize office documents into Markdown without depending on a paid API: internal RAG systems, document-analysis tools, agents processing contracts or reports that arrive 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" philosophy applied to local files.

It's not the right tool if your core problem is scanned PDFs, photographed invoices, digitized paper contracts. That requires OCR, and AnyDoc doesn't ship it out of the box; you'll need to pair it with Tesseract, a vision model, or pay for /parse. It's also not the strongest pick for extremely complex layouts (magazine-style PDFs, multi-column documents with crossed content flows), vision-oriented tools like LlamaParse still lead on quality there, even at a higher per-page cost. 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, as with any project that jumps from zero to 12, 000 stars in a week, is immaturity: this is a days-old project, not a years-old one. 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.

If you're training to build exactly this kind of infrastructure, data pipelines for AI, RAG, agents that consume real-world documents, this is precisely the territory covered in a program like AI Engineering for Devs at 4Geeks, where you work with the full stack of shipping production AI systems, not just demos. And you can see the depth of that curriculum in our AI Engineer hub, which maps out what it actually 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. And for anyone building coding agents that occasionally need to read a spec or a Word doc before writing a single line, it's worth knowing which agent to reach for: we cover that in our best coding agents in 2026 comparison. Still deciding which 4Geeks path fits where you're starting from? Our program comparison breaks it down side by side.

For more of our coverage on developer-facing AI tools like this one, see the AI Tools hub.