Firecrawl AnyDoc Review: 14 Formats to Markdown for AI Agents

Firecrawl AnyDoc is a fast local document-to-Markdown library for mixed Office files, not a complete document-intelligence platform. The open-source Rust project converts Word, PowerPoint, Excel, OpenDocument, RTF, EPUB and CSV files through one shared document model. It also passes text-based PDFs to pdf-inspector. For a team building RAG ingestion, an AI-agent upload feature or a knowledge-import pipeline, its appeal is simple: one dependency, consistent Markdown and no API call for routine files.

Our verdict after reviewing the code, benchmark method and alternatives on 10 August 2026: AnyDoc deserves a corpus-specific pilot when office documents dominate and local execution matters. It is a poor default when scans, handwriting, visual layout or typed field extraction dominate. This review targets the underserved buying question, AnyDoc versus Docling, MarkItDown or a managed parser, without competing with our separate PDF and OCR-routing coverage.

What is Firecrawl AnyDoc?

AnyDoc converts document bytes into a shared structural model and serializes that model as GitHub-Flavored Markdown. Its official repository and API reference list Rust, Node.js, Python, CLI and browser WebAssembly interfaces. Content-based detection reads file markers instead of trusting the extension, except for CSV, which has no signature and needs an extension or explicit format.

The boundary matters. Embedded assets remain available as bytes in the document model, while Markdown represents them with alt text or a reference. AnyDoc does not run OCR, interpret a chart, infer invoice fields, split text for embeddings or evaluate retrieval quality. It solves the conversion layer before those jobs.

What does the 4.4 ms benchmark actually prove?

Firecrawl reports a 4.4 ms median conversion time and an overall quality score of 81 for AnyDoc across its 14-format benchmark. The official AnyDoc launch and benchmark explanation says the comparison used 100 real-world documents and six alternatives. AnyDoc was the only tool in that test to cover all 14 formats.

Treat this as credible vendor evidence, not a universal speed record. Pin the AnyDoc version, hardware, warm-up method and sample. Measure p50 and p95, structure acceptance, missing content, correction minutes and failed documents. A parser that finishes in milliseconds but corrupts one financial table is not fast in business terms.

AnyDoc vs Docling vs MarkItDown vs Firecrawl Parse

The right alternative depends on what your files contain, not which repository has the strongest launch week.

Docling's current supported-format documentation includes PDF, Office, OpenDocument, EPUB, images, HTML, markup, audio and video, with OCR and structured export paths elsewhere in the toolkit. That breadth makes it a better candidate for layout-heavy or multimodal corpora, but not automatically a better lightweight Office converter.

Microsoft's MarkItDown documentation describes optional format dependencies, OCR through a plugin and billable Azure paths for higher-quality layout or structured extraction. It suits Python-centric products that value an extensible conversion toolkit. AnyDoc suits teams that want a narrow, local, multi-language binding around consistent office-to-Markdown conversion.

Firecrawl's managed Parse documentation adds OCR modes, summaries and schema-guided JSON. Choose it when managed exception handling is more valuable than keeping every byte and parser process inside your boundary. The local library and hosted API are not interchangeable products, even though AnyDoc powers part of the hosted path.

How should AnyDoc fit into an AI-agent or RAG pipeline?

1. Accept narrowly. Allow only required formats, enforce file and decompressed-size limits, replace user filenames and quarantine the upload.
2. Detect from bytes. Compare the claimed extension with AnyDoc's content-based result. Reject a mismatch unless the product has an explicit recovery path.
3. Parse in isolation. Bound CPU, memory, nesting and wall-clock time. Run public uploads away from the web process and credential store.
4. Preserve provenance. Store file hash, original format, parser version, extraction timestamp, headings, tables and asset references.
5. Validate the Markdown. Check required sections, character quality, row counts, totals, links and empty output before indexing.
6. Route exceptions. Send image-only PDFs and embedded scans to an approved OCR or vision path. Send encrypted, malformed or unsupported files to a controlled review or rejection queue.
7. Chunk after acceptance. Parsing creates source text. Chunking, metadata, permissions, embeddings, retrieval and answer citations remain separate responsibilities.
8. Measure accepted documents. Track end-to-end cost and reviewer time, not only parser milliseconds.

For PDFs specifically, use our pdf-inspector OCR-routing review. It owns native-text detection, mixed-page routing and the boundary where OCR begins. For what happens after accepted Markdown, the EU RAG production-readiness checklist owns permissions, retrieval evaluation and answer citations. Keeping those intents separate prevents the new AnyDoc page from cannibalizing either guide.

Node.js quick start with a production boundary

The library API is deliberately small. The surrounding checks are application responsibilities:

import { toMarkdownBytes } from "@firecrawl/anydoc"

export async function parseAcceptedUpload(file) {
  enforceUploadLimits(file)
  const bytes = new Uint8Array(await file.arrayBuffer())

  const markdown = await toMarkdownBytes(bytes, file.name)
  const result = validateDocument(markdown)

  if (!result.accepted) {
    return routeForReview(file, result.reasons)
  }

  return {
    markdown,
    sha256: await hash(bytes),
    parser: "anydoc@PINNED_VERSION",
    sourceName: safeDisplayName(file.name)
  }
}

enforceUploadLimits, validateDocument, routeForReview, hash and safeDisplayName are product code, not AnyDoc APIs. Keep that distinction visible in architecture estimates. Installing the parser is the smallest part of a reliable ingestion feature.

Where is AnyDoc a poor fit?

• Scanned or photographed documents: AnyDoc has no OCR model. Text-based PDF support does not change that limit.
• Visual meaning: charts, signatures, handwritten changes, spatial forms and images need a vision or document-understanding layer.
• Typed business fields: converting an invoice to Markdown is not the same as validating supplier, tax, line items and total against a schema.
• Perfect Office rendering: the goal is clean structured text, not pixel-identical reproduction of a workbook, slide deck or legacy Word file.
• Unbounded public upload: Rust and fixed library resource limits help, but do not replace sandboxing, malware controls, queue limits and patch ownership.
• Independent benchmark requirements: the published speed and quality evidence comes from the project team and a private corpus. Procurement may require your own blind evaluation.

OWASP's file-upload security guidance recommends defense in depth: allowlisted extensions, content-type and signature checks, renamed files, size limits, isolated storage, malware scanning and parser hardening. Local conversion reduces one data-transfer risk. It does not make an untrusted Office file safe.

A ten-day AnyDoc evaluation plan

1. Sample the real mix. Select at least 200 documents across every relevant format, language, age and source. Include malformed, encrypted, macro-enabled and oversized examples.
2. Define acceptance. Label required headings, notes, tables, merged cells, links, formulas, page references and assets for each document class.
3. Baseline the current path. Record accepted-document rate, p50, p95, infrastructure cost, reviewer minutes and fallback rate.
4. Run a pinned AnyDoc build. Measure the same outcomes. Separate warm parsing from process start and upload time.
5. Compare two alternatives. Use Docling on the hard visual subset and MarkItDown on the common formats, rather than copying a vendor-wide ranking.
6. Attack the boundary. Test mislabeled, compressed, nested and resource-intensive files in the intended sandbox.
7. Price the fallback. Count OCR calls, manual review, rejected uploads and failures that reach users.
8. Choose by accepted action. Ship only if quality and safety stay above the gate while total cost or latency improves.

Use our AI agent cost-per-action model to keep retries and human repair in the denominator. If document ingestion is becoming product infrastructure, Wavect's AI enablement service can benchmark the corpus, build the routing layer and connect it to retrieval or workflow automation. The Twinsoft AI case study shows our approach to traceable AI output, while the MVP technology-selection guide helps decide which parser layers to own.

Research boundary

Status checked 10 August 2026. Benchmark figures in this review are vendor-published results, not Wavect measurements. We reviewed the public repository, benchmark notes and official alternative documentation, but did not receive the private AnyDoc corpus or conduct a security audit. Versions, formats, hosted limits and pricing can change. Pin and verify them before procurement.