Firecrawl ha publicado anydoc, una librería open source escrita en Rust que convierte documentos Word, Excel, PowerPoint, OpenDocument, RTF, EPUB, CSV y PDF en Markdown preparado para integrarse en pipelines de IA, RAG, automatización y agentes. Su mayor atractivo para desarrolladores y administradores de sistemas no está solo en la velocidad, sino en que puede ejecutarse localmente, desde CLI, Node.js, Python o WebAssembly, sin depender obligatoriamente de un servicio externo.
Las claves de anydoc en 20 segundos
- Convierte documentos de oficina a Markdown desde CLI o código.
- Está escrito en Rust y ofrece bindings para Node.js, Python y navegador.
- Soporta formatos modernos y antiguos como
.doc,.xlso.ppt. - Puede integrarse en agentes como Claude Code, Codex, Cursor u OpenCode.
- No incorpora OCR, por lo que los PDF escaneados requieren una etapa adicional.
Para quien administra pipelines documentales, el problema es conocido. Una aplicación de IA rara vez recibe únicamente texto plano. En entornos reales aparecen .docx, hojas Excel, presentaciones, PDFs, archivos antiguos de Office o documentación en OpenDocument.
Antes de indexar esos datos, introducirlos en una base vectorial o entregarlos a un modelo, hay que normalizarlos.
Markdown se está convirtiendo en una de las capas intermedias más utilizadas para hacerlo porque conserva estructura suficiente, encabezados, listas, tablas, enlaces o bloques de código, sin arrastrar toda la complejidad visual del documento original.
Un único CLI para Word, Excel, PowerPoint y PDF
La utilización básica de anydoc es sencilla.
Puede instalarse y ejecutarse directamente con npx:
npx @firecrawl/anydoc report.docxLenguaje del código: CSS (css)Para guardar el resultado:
npx @firecrawl/anydoc slides.pptx -o slides.mdLenguaje del código: CSS (css)También acepta datos desde stdin:
cat data.csv | npx @firecrawl/anydoc - --format csvEsto lo hace especialmente interesante para integrarlo en scripts.
Un pipeline sencillo podría ser:
find ./documents -type f -name "*.docx" -print0 |
while IFS= read -r -d '' file; do
npx @firecrawl/anydoc "$file" -o "${file%.docx}.md"
doneLenguaje del código: JavaScript (javascript)A partir de ahí los Markdown generados pueden enviarse a una fase de chunking, indexación o inferencia.
La ventaja frente a utilizar una suite ofimática completa para cada conversión es evidente en servidores, contenedores y runners de CI, donde instalar LibreOffice únicamente para extraer texto puede introducir bastante peso adicional.
Por qué Rust importa en este caso
anydoc utiliza Rust como núcleo y expone después diferentes interfaces.
Eso permite que la misma lógica de parsing pueda reutilizarse desde varios entornos:
anydoc core
Rust
│
┌─────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Node.js Python WASM
│ │ │
Backend Scripts BrowserLenguaje del código: CSS (css)Para un desarrollador Node.js:
import { toMarkdown } from '@firecrawl/anydoc';
const markdown = await toMarkdown('report.docx');Lenguaje del código: JavaScript (javascript)Desde Python:
import anydoc
markdown = anydoc.to_markdown("report.docx")Lenguaje del código: JavaScript (javascript)Y mediante WebAssembly puede ejecutarse directamente en navegador.
Esta última modalidad tiene implicaciones interesantes para datos sensibles. En determinados diseños el documento puede transformarse localmente en el navegador antes de decidir qué parte se envía posteriormente a un backend o a un modelo.
No elimina automáticamente todos los problemas de privacidad, pero permite arquitecturas en las que la conversión documental no requiere subir primero el archivo completo a un servicio externo.
La detección del formato no depende solamente del nombre
Otra característica relevante para automatización es que anydoc intenta detectar el formato a partir del contenido binario.
Esto evita depender únicamente de:
document.docxLenguaje del código: JavaScript (javascript)porque en sistemas reales pueden aparecer extensiones equivocadas, archivos renombrados o datos recibidos desde APIs sin un nombre fiable.
El parser examina firmas y estructuras características de cada formato antes de elegir el mecanismo de conversión.
Esto resulta útil en procesos de ingestión donde se reciben documentos de usuarios:
upload
│
▼
detección binaria
│
├── DOCX
├── XLS
├── PPT
├── PDF
└── ODT
│
▼
parser
│
▼
MarkdownCSV es una excepción lógica porque no dispone de una firma binaria equivalente y puede requerir una indicación explícita.
El modelo intermedio facilita resultados más consistentes
Un detalle técnico especialmente interesante es que los parsers de anydoc no escriben Markdown directamente.
Primero construyen una representación interna común del documento.
Esa representación puede contener elementos como:
- párrafos;
- títulos;
- elementos inline;
- listas;
- tablas;
- enlaces;
- notas al pie;
- recursos.
Después un único serializador genera Markdown.
La arquitectura tiene una ventaja mantenible: si se corrige un problema en el tratamiento de una tabla o una lista, la mejora puede beneficiar a múltiples formatos en vez de tener lógica de renderizado diferente en cada parser.
Para quienes mantienen software de ingestión documental esto puede ser más importante que la propia velocidad.
Soporta también formatos antiguos de Office
Un punto práctico que suele olvidarse en proyectos de IA es el legado documental.
Las empresas no tienen únicamente .docx, .xlsx y .pptx.
También existen:
.doc
.xls
.ppt
.pps
.pot
.rtfLenguaje del código: CSS (css)y años de documentación guardada en servidores de archivos.
anydoc declara soporte actualmente para:
| Familia | Formatos |
|---|---|
| Word | .doc, .docx, .docm |
| PowerPoint | .ppt, .pps, .pot, .pptx, .pptm, .ppsx, .ppsm |
| Excel | .xls, .xlsx, .xlsm, .xlsb |
| OpenDocument | .odt, .ods, .odp |
| Otros | .rtf, .epub, .csv, .pdf |
Para una migración documental o la creación de un RAG corporativo, soportar .doc y .xls puede ser mucho más útil que añadir compatibilidad con un formato nuevo y poco utilizado.
anydoc frente a MarkItDown, Docling y Pandoc
Aunque suelen aparecer comparados, los proyectos no resuelven exactamente el mismo problema.
| Herramienta | Mejor encaje |
|---|---|
| anydoc | conversión rápida y local de documentos a Markdown |
| MarkItDown | extracción sencilla de múltiples formatos para LLM |
| Docling | comprensión documental avanzada y PDF complejo |
| Pandoc | conversión general entre muchos formatos |
| Unstructured | pipelines de ingestión, particionado y chunking |
Anydoc pone el foco en parsing tradicional y velocidad.
Docling trabaja mucho más sobre la comprensión estructural de documentos complejos. Puede analizar layout, tablas, fórmulas y diferentes componentes visuales, por lo que su coste computacional es necesariamente distinto.
Pandoc tampoco debería considerarse únicamente un competidor para IA. Es un conversor documental general capaz de transformar contenido entre una enorme cantidad de formatos.
Un ejemplo sencillo:
pandoc document.docx -t gfm -o document.mdLenguaje del código: JavaScript (javascript)sigue siendo perfectamente válido.
La cuestión es qué dependencias, formatos, velocidad e integración necesita cada pipeline.
El benchmark promete milisegundos, pero hay que leer la letra pequeña
Firecrawl ha publicado una comparativa realizada con 100 documentos reales y 14 formatos.
Según esos datos, anydoc obtuvo una mediana de 4,4 ms por documento, frente a resultados superiores para otras alternativas.
La cifra resulta llamativa, pero conviene no convertirla en una verdad universal.
El benchmark procede del propio proyecto, cada herramienta soportó una cantidad diferente de formatos y algunas soluciones realizan mucho más trabajo que una conversión directa a Markdown.
Además, comparar una librería Rust embebida con procesos externos o herramientas que cargan modelos puede penalizar especialmente el tiempo de arranque de estas últimas.
Para un sysadmin, la conclusión más útil no debería ser que «anydoc siempre es X veces más rápido», sino que su arquitectura es suficientemente ligera para plantearse conversiones masivas dentro de procesos locales o pipelines de CI.
Qué ocurre con los PDF escaneados
Este es actualmente uno de sus límites más importantes.
Anydoc no integra OCR.
Si un PDF contiene texto real:
PDF
└── text layer
└── anydocpuede procesarlo.
Si el PDF es básicamente una colección de imágenes escaneadas:
PDF
└── images
└── OCR necesariohace falta añadir otra herramienta.
Esto obliga a diseñar correctamente un pipeline documental.
Por ejemplo:
PDF
│
detectar contenido
┌─────┴─────┐
│ │
texto escaneado
│ │
anydoc OCR
│ │
└─────┬─────┘
▼
Markdown
│
▼
chunking
│
▼
RAGEs probablemente una arquitectura más eficiente que enviar todos los documentos a OCR, incluso cuando el 90 % ya contiene texto perfectamente extraíble.
Un buen componente para contenedores y CI/CD
Para administradores de sistemas, uno de los escenarios más interesantes está en los workers de procesamiento documental.
Un servicio podría recibir documentos desde un bucket, NAS o cola de mensajes:
S3 / NAS / Upload
│
▼
Worker ARM/x86
│
anydoc
│
▼
Markdown
│
├── Elasticsearch
├── vector DB
├── LLM
└── almacenamientoAl no necesitar una GPU ni un modelo para la conversión convencional, estos workers pueden ejecutarse en instancias relativamente pequeñas.
También pueden escalar horizontalmente:
Queue
│
├── worker-01 ── anydoc
├── worker-02 ── anydoc
├── worker-03 ── anydoc
└── worker-04 ── anydocPara grandes repositorios documentales esto puede ser bastante más sencillo que mantener una instancia pesada con escritorio virtual y LibreOffice.
Agentes de IA que convierten documentos por sí mismos
Anydoc incorpora también una habilidad para agentes.
La instalación indicada es:
npx skills add firecrawl/anydocEsto permite integrarlo con herramientas como Claude Code, Codex, Cursor u OpenCode.
El interés aquí no está solamente en ahorrar un comando manual.
Un agente puede encontrarse con un archivo:
quarterly-report.xlsxLenguaje del código: CSS (css)determinar que necesita leerlo, utilizar anydoc y continuar trabajando sobre:
quarterly-report.mdLenguaje del código: CSS (css)sin que el usuario tenga que realizar manualmente la conversión.
Es una pequeña pieza dentro de una tendencia mayor: los agentes empiezan a necesitar herramientas de sistema fiables para interactuar con formatos que los modelos no deberían procesar directamente en bruto.
Convertir documentos localmente también tiene ventajas operativas
En infraestructura empresarial existen al menos tres razones para realizar esta fase localmente.
La primera es privacidad. Un documento puede contener información confidencial y quizá no sea necesario enviarlo completo a ningún proveedor simplemente para convertirlo.
La segunda es coste.
Si se procesan millones de documentos, realizar el parsing convencional dentro de la propia infraestructura puede evitar pagar llamadas externas por archivos que no necesitan IA.
Y la tercera es reproducibilidad.
Un pipeline con una versión fijada:
anydoc 1.xLenguaje del código: CSS (css)puede ejecutarse de la misma forma en desarrollo, integración continua y producción.
Esto ayuda a controlar cambios en la forma en que se generan los documentos Markdown utilizados posteriormente por un RAG.
La conversión documental parece una etapa secundaria hasta que un cambio en el parser modifica encabezados, tablas o separaciones y altera cientos de miles de chunks ya indexados.
Por eso versionar también esta parte del pipeline tiene sentido.
Anydoc no sustituye todas las herramientas documentales
Ser ligero tiene una contrapartida.
Si una aplicación necesita entender un gráfico incrustado, interpretar visualmente una factura escaneada, reconstruir tablas complejas desde una imagen o identificar fórmulas matemáticas representadas gráficamente, hará falta algo más.
Ahí entran herramientas basadas en OCR, visión o modelos especializados.
Pero muchas organizaciones tienen otro problema mucho más sencillo: millones de documentos digitales perfectamente estructurados que únicamente necesitan convertirse a un formato cómodo para máquinas.
En ese escenario, añadir modelos de visión a cada archivo puede ser innecesariamente caro y lento.
Anydoc intenta ocupar precisamente ese espacio: parsing rápido cuando el contenido ya está presente en el propio documento y herramientas más pesadas únicamente cuando hagan falta.
Preguntas frecuentes
¿Qué es anydoc?
anydoc es una librería open source de Firecrawl escrita en Rust para convertir formatos de oficina, OpenDocument, EPUB, CSV y PDF a Markdown.
¿Puede ejecutarse sin conexión a Internet?
La conversión puede realizarse localmente. El proyecto ofrece CLI y bindings para Node.js, Python y WebAssembly, por lo que no necesita obligatoriamente una API externa para los formatos soportados.
¿Puede utilizarse para construir un sistema RAG?
Sí. Puede ocupar la fase de extracción y normalización documental antes del chunking, generación de embeddings e indexación.
¿Procesa documentos PDF escaneados?
No incorpora OCR. Un PDF basado únicamente en imágenes necesita primero un motor OCR o un parser visual adicional.
