AnyDoc & pdf-inspector: Firecrawl's Rust Markdown Parsers

AnyDoc and pdf-inspector are two Rust-based, MIT-licensed open-source libraries that Firecrawl — best known for its web scraping service — released on August 6, 2026. AnyDoc converts 14 file formats, including Word, Excel, and PowerPoint, into Markdown, while pdf-inspector classifies PDFs page by page as text-based, scanned, or image-based to determine whether OCR is actually needed. Both run entirely locally with no API key and no external service dependency, which makes them practical building blocks for RAG preprocessing or internal document pipelines that shouldn't rely on a third party.

The attention these two libraries are getting comes down to their origin: Firecrawl extracted them from the parser it runs in production. In April 2026 the company shipped Fire-PDF, a rewritten Rust PDF engine it claimed was 3.5x to 5.7x faster than its predecessor — and pdf-inspector is the component underneath it. Since the August 6 release, the repository has climbed into GitHub's weekly Trending list and passed 13,000 stars.

The two libraries split the problem cleanly. AnyDoc focuses on normalizing many different file formats into a single Markdown output, while pdf-inspector focuses narrowly on PDFs, determining page by page whether OCR is required and extracting text directly, without OCR, from pages that don't need it. AnyDoc even embeds pdf-inspector internally to handle PDF input, so the two tools are independent but complementary.

- AnyDoc: Converts 14 formats — Word, Excel, PowerPoint, OpenDocument, RTF, EPUB, CSV, and PDF — into GitHub-Flavored Markdown
- Robust format detection: Identifies formats by file signature (actual file content) rather than extension, so mislabeled or missing extensions aren't a problem
- Consistent output: Every format is first mapped onto a shared internal document model before rendering, keeping output structure stable across input types
- pdf-inspector: Classifies each PDF page into one of four types — text-based, scanned, image-based, or mixed — and returns a confidence score plus a list of pages that need OCR
- Multi-language bindings: Both ship for Rust, Node.js, and Python; AnyDoc also runs in the browser via WebAssembly
- Agent integration: AnyDoc is also distributed as an Agent Skill, callable directly from AI coding agents such as Claude Code or Cursor

AnyDoc's 14 supported formats fall into 8 categories. Embedded assets such as images are rendered as alt text in the Markdown output, with the raw bytes available separately if needed. pdf-inspector, meanwhile, shares a single PDF load across its detection and extraction phases, avoiding a redundant double parse. It also handles CID fonts (CMap decoding), multi-column layout detection, table recognition via both rectangle analysis and heuristic alignment checks, and automatic flagging of encoding anomalies.

Both libraries install directly through the standard Rust, Node.js, and Python package managers. AnyDoc is also distributed via pip, but pdf-inspector's Python bindings currently require a maturin build, which is worth knowing before you commit to a pipeline. Here's AnyDoc first.

And here's pdf-inspector. If you just want a standalone CLI, cargo install pdf-inspector covers that.

According to benchmarks Firecrawl published, AnyDoc leads libreoffice, unstructured, markitdown, pandoc, docling, and mammoth on format coverage, processing speed, and a composite quality score (completeness, structure, formatting, and cleanliness). The speed gap is especially large — roughly 250x faster than libreoffice and about 30x faster than markitdown.

pdf-inspector was benchmarked against liteparse, opendataloader, pymupdf4llm, and markitdown across 200 documents. It leads on both overall accuracy and speed, and the gap versus markitdown is stark: roughly 34x faster, with a table-recognition score about 3x higher.

It's worth noting that all of these figures come from Firecrawl's own published measurements. Results can vary with document mix and tool versions, so treat them as a reference point rather than a guarantee.

The most obvious use case is RAG preprocessing. If Word, Excel, PowerPoint, and PDF files scattered across an organization are all normalized to Markdown through AnyDoc, chunking and embedding pipelines no longer need format-specific handling. Pairing it with pdf-inspector adds a routing step: the classification pass (about 20ms) determines whether a PDF is text-based or scanned, text-based PDFs are extracted locally (about 150ms), and only scanned PDFs get sent to an external OCR service. Firecrawl's published figures suggest roughly 54% of PDFs turn out not to need OCR at all, which can meaningfully cut OCR API calls and cost. For IT teams weighing a Markdown conversion project for internal documents, or looking to trim an existing OCR pipeline's cost, this combination is worth evaluating.

A few caveats are worth keeping in mind. First, pdf-inspector is not an OCR engine — it only decides whether OCR is needed, so scanned PDFs still require a separate OCR engine or service to actually extract text. Second, the Python setup differs between the two: AnyDoc installs cleanly via pip, while pdf-inspector's Python bindings require a maturin build, which is one more step than AnyDoc needs. Third, since the benchmark numbers above are Firecrawl's own measurements, re-running them against your own document set is the safer approach before making a decision based on them. Finally, both libraries are freshly released, so their APIs may still change; pinning a specific version is the sensible default for anything going into production.