anydoc: Parse Word Docs, PDFs, and Slides to Markdown in One Call

Most teams feeding documents into an AI pipeline eventually hit the same wall: PDFs are one format, but Word docs, slide decks, spreadsheets, and old .doc files are all different problems with different failure modes. anydoc, an open-source Rust library from Firecrawl, is built to solve the whole category at once. It takes 14 document formats, Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF, and converts every one of them to clean Markdown through the same code path. As of today, the GitHub repository sits at 15,006 stars and 798 forks, with the repo created August 3, 2026, so this is a genuinely new but fast-growing project, not an established one.

What anydoc actually does

The pitch is one function call: anydoc::to_markdown("file.docx") in, clean Markdown out, no API key and no external services required. Firecrawl's own benchmark, run against six other converters on 100 real-world documents spanning the 14 formats, reports a median conversion time of 4.4 milliseconds, against a range of 52ms to 1,130ms for the competitors it tested. anydoc was also the only library in that benchmark to handle all 14 formats; the next-best option, LibreOffice's conversion path, covered 12.

That speed comes from a specific design choice: every format gets parsed into the same internal document model, then rendered through one shared Markdown serializer. That is also why table structure, nested lists, and heading levels come out consistent whether the source is a .doc file from 2003 or a .pptx exported yesterday, rather than each format handler producing its own slightly different flavor of Markdown.

Format detection reads content markers inside the file rather than trusting the file extension, so a renamed or mislabeled file still converts correctly, a small but real detail for anyone who has dealt with a batch of documents where the extensions do not match the actual format.

Open source, and what that means for PDFs specifically

anydoc is MIT licensed and self-hostable: install via npm install @firecrawl/anydoc, pip install firecrawl-anydoc, or cargo add anydoc, and it runs entirely locally with no calls out to Firecrawl's infrastructure. That matters more than it might sound like it does. A team that wants document parsing without sending files to a third-party API, or without a per-document usage bill, can run this on their own machines from day one.

For PDFs specifically, anydoc embeds pdf-inspector, Firecrawl's earlier, narrower Rust library, to handle the text-based case locally. pdf-inspector's whole job is deciding, in milliseconds, whether a PDF is text-based or scanned, then extracting the text-based ones itself. anydoc calls that same logic as one format handler among 14, rather than reimplementing PDF parsing from scratch. What neither tool does on its own is OCR: a scanned PDF still needs to go somewhere else, which is where Firecrawl's hosted /parse endpoint comes in, adding OCR on top of the same open-source conversion for the pages that need it.

anydoc vs pdf-inspector: which one to reach for

pdf-inspector's own article on this site already covers the split from its side, worth reading if PDFs specifically are the bottleneck. The short version from anydoc's side: pdf-inspector is a PDF specialist, classify scanned versus text-based, then extract and route accordingly. anydoc is a format generalist that happens to include PDF support by calling pdf-inspector internally. If a pipeline only ever touches PDFs, pdf-inspector alone covers it. If a pipeline also has to ingest Word docs, PowerPoint decks, or Excel exports, which is the normal case for anything pulling from email attachments, shared drives, or a document management system, anydoc is the tool that covers the full intake surface without stitching together separate libraries per format.

Quality, not just speed

Firecrawl also ran an LLM-judged quality comparison, using Claude Sonnet 5 to score completeness, structure, formatting, and cleanliness against the same 100-document set. anydoc scored 81 overall against 70 for the next-best option, and led on every individual format tested. That is Firecrawl grading its own tool with an AI judge, which is worth naming plainly. It is not an independent audit, and a team evaluating this for a production pipeline should run their own sample of real documents through it rather than taking a vendor's benchmark as the final word, the same caution that applies to any self-reported speed or quality claim.

Fitting it into a document pipeline

The practical case for anydoc is the intake step ahead of anything that reads documents into an LLM or an agent: chatbots answering questions from an internal knowledge base, retrieval pipelines indexing a mixed folder of file types, or an agent skill that needs to read whatever a user drops in. It is also available as an Agent Skill for Claude Code, Cursor, and similar tools, so a coding agent can call it directly to read a document a developer references mid-conversation, rather than the developer manually converting the file first.

Because it runs locally with no API key, the setup cost is close to zero: install the package, call the function, and there is nothing else to configure until a scanned PDF shows up and OCR becomes necessary. That is also its honest limit. anydoc converts what is already digital text inside a document; it does not read text out of an image the way a full OCR service does, and Firecrawl's own hosted /parse endpoint exists specifically because that gap has to be filled by something.

Getting started

The fastest way to see whether the output quality holds up on real documents is the CLI: npx @firecrawl/anydoc report.docx -o output.md against a handful of files that are actually representative of what a pipeline receives, mixed formats, real formatting quirks, not a clean sample file. A WebAssembly build is also available to try conversions directly in a browser without installing anything, useful for a first look before committing to wiring it into code.

Limitations worth knowing before adopting

The project is ten days old as of this writing, created August 3, 2026, with 55 open issues at last check. That is not unusual for a fast-moving open-source launch, but it means the format coverage that looks complete on paper has not had years of edge cases thrown at it yet. The benchmark numbers, both speed and quality, come from Firecrawl's own test set and its own LLM judge, not a neutral third party, so treat them as a strong signal to try the tool, not as a guarantee it will outperform every alternative on a specific pipeline's actual documents. And OCR is still a separate concern entirely: anydoc plus pdf-inspector covers digital-text extraction across 14 formats, but a folder full of scanned contracts or faxed forms still needs an OCR step from somewhere else, whether that is Firecrawl's hosted /parse or a different service.