A MarkItDown suele meterlo en el mismo saco que a los web scrapers, y eso es un error. No tiene crawler, no tiene motor de JavaScript y tampoco puede ir a buscar una URL para limpiarle el HTML sobrante. Lo que sí hace es tomar bytes que ya tienes —un PDF, un documento de Word, una hoja de cálculo, una presentación— y convertir todo eso en Markdown legible para un modelo de lenguaje.
Me pasé un par de semanas probando MarkItDown de Microsoft con una tanda de documentos reales en un solo Mac, puntuando cada tabla frente a un manifiesto que escribí antes de empezar y midiendo el tiempo de cada conversión. La conclusión rápida: con entradas limpias va rápido y es fiel, su empaquetado esconde un runtime de machine learning de 73 MB que no pediste, y sus tablas se rompen de formas que pasan un chequeo de "¿sobrevivió el texto?" y fallan un chequeo de "¿está cada dato en la columna correcta?". Aquí va el panorama completo, con números.
Qué es realmente MarkItDown
MarkItDown es una utilidad en Python de Microsoft que convierte archivos y documentos de Office en Markdown optimizado para LLMs. Si le pasas un PDF, un .docx, un .xlsx, un .pptx, una imagen, un archivo HTML o algunos otros formatos, te devuelve Markdown. Se puede usar de tres maneras: por CLI (markitdown file.pdf -o out.md, o canalizando desde stdin), mediante la API de Python (MarkItDown().convert(...)) y con un servidor MCP opcional para flujos de trabajo con agentes.
Lo más importante no es lo que hace, sino lo que no hace, porque el README tampoco lo promete y yo lo confirmé en las pruebas: no rastrea, no renderiza JS, no sigue enlaces, no pagina y no extrae el contenido principal al estilo de las herramientas de legibilidad. Es un convertidor de documento completo. Tú aportas los bytes; él los normaliza. Esa diferencia decide si esta herramienta encaja o no en tu stack, así que volveré sobre ella varias veces.
El repositorio, además, impresiona por los números de GitHub —165.282 estrellas y 11.790 forks a mediados de julio de 2026, licencia MIT, con la versión más reciente (v0.1.6) publicada el 2026-05-26. Pero ese conteo de estrellas refleja el entusiasmo general por las herramientas de LLM en un repo de Microsoft, no necesariamente la madurez de su núcleo de conversión. También hay 833 issues abiertos, y algunos te importan antes de instalarlo (más abajo hablo de eso).
HTML a Markdown: rápido, completo y con boilerplate incluido
Como el resto de mi serie de reseñas de scrapers usa las mismas cuatro páginas web de prueba, alimenté a MarkItDown con esos mismos HTML locales, no para calificarlo como scraper, sino para ver qué tan buena es su conversión de HTML a Markdown. En páginas bien estructuradas, de verdad funciona muy bien.
Las cuatro páginas se convirtieron con la instalación base, sin extras, y todas conservaron el contenido principal. El artículo de Wikipedia sobre "Web scraping" (226 KB) salió con su árbol de encabezados reflejado —un h1, siete h2 y doce h3, exactamente como la estructura real del artículo— y 418 enlaces conservados como [texto](url). La tabla de estadísticas de hockey 25×9 de la página Scrape This Site forms se convirtió en una tabla GFM limpia de 27 filas (encabezado + separador + 26 filas de datos), con celdas vacías incluidas. La velocidad no fue problema: una mediana de 48 ms para la página pequeña de citas hasta 352 ms para la página de Wikipedia de 226 KB.
Pero aquí está el detalle, y no es un fallo sino una decisión de diseño. MarkItDown no quita el boilerplate. Convierte todo el <body>, así que el chrome del sitio se queda y el residuo crece según cuánta interfaz tenga la página.
| Página | Caracteres de salida | Encabezados (h1/h2/h3) | Enlaces | Líneas de interfaz del sitio |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0.6% (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1.2% (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6.7% (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12.4% (42/338) |
En la página principal de Books, casi libre de chrome, solo el 0,6% de las líneas de salida son interfaz. En Wikipedia, esa cifra sube al 12,4%: 42 de 338 líneas no vacías son cosas como "jump to content", "toggle the table of contents", "22 languages", "retrieved from", y pies de página de cookies y licencia. Incluso los banners de mantenimiento de Wikipedia ("This article needs additional citations") se representan fielmente en tablas de dos columnas, de donde salen nueve filas de tabla en una página que no tiene ninguna tabla de datos real.
Nada de eso significa que MarkItDown esté haciendo algo mal. Es un convertidor de documento completo, no un extractor de legibilidad: convertir HTML a Markdown con fidelidad no es lo mismo que extraer un artículo limpio. Trafilatura y herramientas al estilo Firecrawl intentan devolver solo el contenido principal; MarkItDown devuelve la página entera. Por dentro, su _html_converter.py elimina <script> y <style>, y luego pasa todo el body a la librería markdownify; no hay ningún heurístico de contenido principal en ese flujo. Si lo que quieres es solo el artículo, esta no es la capa correcta.
Su terreno natural: PDF, DOCX, XLSX, PPTX
Los documentos son para lo que MarkItDown fue creado. Lo probé con archivos públicos reales: un paper de arXiv con capa de texto, el whitepaper de Bitcoin, un PDF escaneado solo con imágenes al que le quité cualquier texto al renderizarlo, y los archivos DOCX/XLSX/PPTX de la propia suite de pruebas de MarkItDown (sembrados con UUIDs para detectar pérdida silenciosa de contenido).
| Documento | Entrada | Caracteres de salida | Probes | Tiempo mediano | Notas |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF con capa de texto) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | título, "Transformer", "BLEU", "References" presentes |
| Bitcoin whitepaper (PDF de 9 páginas) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" presentes |
| PDF escaneado (sin capa de texto) | 89 KB | 0 | 0/4 | 15 ms | salida vacía, sin error, sin OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | encabezados + tabla GFM; los UUID incrustados sobreviven |
| DOCX con ecuaciones | 15 KB | 240 | — | 101 ms | Office Math conservado como LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | cada hoja → ## SheetName + tabla GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | marcadores de número de diapositiva, tablas, gráfico → tabla |
La recuperación de texto en los PDFs con capa de texto fue excelente —7 de 7 probes predefinidos en el paper de arXiv "Attention Is All You Need", 6 de 6 en el whitepaper de Bitcoin— y ninguno de los archivos de Office perdió un solo UUID centinela, así que no hubo pérdida silenciosa de contenido en los fixtures de regresión de los mantenedores. Un acierto puntual muy interesante: la ruta de DOCX (vía mammoth) conserva ecuaciones de Office Math como LaTeX, convirtiendo equations.docx en matemáticas reales $$...$$. Si le pasas documentos de Word cargados de matemáticas a un LLM, eso es una ventaja muy concreta que no vi documentada en otros sitios.
Hay dos hallazgos en este terreno que merecen atención propia, porque son los que más probablemente te afecten.
El PDF escaneado que desaparece
Si le das a MarkItDown un PDF solo de imágenes, sin capa de texto, te devuelve una cadena vacía. Cero caracteres, sin excepción, sin aviso: convertido en unos 15 ms porque no hay nada que extraer. La ruta PDF de MarkItDown solo extrae texto (por debajo usa pdfminer y pdfplumber), y no incluye OCR ni en la instalación base ni en ningún extra de pip.
Eso importa mucho en procesos por lotes. Un desarrollador que le pasa una carpeta de PDFs donde algunos son escaneos obtiene resultados vacíos para esos archivos, sin señal de que algo se haya saltado. Verifiqué que el fixture no estuviera roto ejecutando extract_text de pdfminer directamente sobre ese archivo —cero caracteres limpios, sin capa de texto, confirmado— así que la salida vacía es el comportamiento real de MarkItDown ante un escaneo real. Esto reproduce un vacío de OCR fallback (#1268) que lleva tiempo abierto upstream. La ruta documentada es el backend opcional de Azure Document Intelligence o un plugin; ninguno viene en la instalación por defecto.
Los PDFs salen como texto plano, no como estructura
En ambos PDFs con capa de texto, MarkItDown no generó ningún marcador de encabezado en Markdown. Un PDF no trae etiquetas semánticas de encabezado, y MarkItDown no las infiere por tamaño de fuente, así que cada línea cae al nivel del cuerpo. La recuperación de texto es alta; la estructura, plana.
Y esto no es solo mi resultado. Benchmarks públicos de terceros puntúan la jerarquía de encabezados PDF de MarkItDown cerca de 0.0 y la fidelidad de sus tablas alrededor de 0.27, muy por debajo de 0.88 de Docling con TableFormer (ver la comparativa MarkItDown vs Docling vs Marker y el benchmark READoc). Mis fixtures reproducen esos resultados, lo cual refuerza la evidencia: mis números coinciden con una fuente externa. El intercambio que reportan esos mismos benchmarks es que MarkItDown corre unas 100 veces más rápido que Docling, algo que encaja con mis tiempos en segundos, no minutos, frente a una herramienta de modelo de layout que tarda minutos. La conclusión: MarkItDown te da texto de PDF limpio y rápido; no te da la estructura del PDF. Si necesitas que sobrevivan encabezados y tablas, una herramienta de modelo de layout como Docling o Marker es la capa adecuada.
Tablas: el contenido siempre sobrevive; la estructura, no siempre
Las tablas son el punto donde "¿sobrevivió el texto?" y "¿el dato sigue siendo utilizable?" se separan, así que armé una matriz de 13 casos —una <table> por caso, cada una puntuada contra un manifiesto escrito antes de la prueba— para mapear exactamente qué formas aguantan y cuáles se rompen.
La idea principal: MarkItDown nunca perdió contenido de tabla. Los 13 casos conservaron el 100% de sus tokens predefinidos. Pero la fidelidad estructural se dividió en tres grupos. Siete de trece produjeron una cuadrícula GFM bien formada: tablas simples, con colspan en encabezado, de 24 columnas de ancho, sin encabezado, con celdas vacías, con bloques dentro de celdas y en árabe de derecha a izquierda. Cuatro quedaron deshilachadas, porque Markdown no tiene noción de celda combinada, así que rowspan, colspan y fuentes mal formadas generan filas cortas. Y dos quedaron rotas del todo.
Conviene nombrar esas dos roturas. Una tabla anidada (una <table> dentro de un <td>) se aplana en línea, volcando sus propios pipes y su fila separadora dentro de la celda padre y produciendo una fila basura de 14 "columnas". Y un | literal dentro de una celda no se escapa: el texto a | b se convierte en dos columnas, x || y en tres; así, una tabla de dos columnas acaba emitiendo filas de dos, tres y cuatro columnas, y cualquier parser de Markdown posterior lee límites equivocados. Curiosamente, los asteriscos y los backticks dentro de celdas sí se escapan; los pipes no. La causa raíz es que la ruta HTML de MarkItDown usa el manejo de tablas por defecto de markdownify, y su subclase personalizada sobreescribe enlaces, imágenes y encabezados, pero no las celdas de tabla. La misma clase de bug de escape de pipes es un issue abierto para el convertidor CSV (#2019), aunque ese arreglo no toca la ruta HTML que yo probé.
El problema más sutil —el hallazgo que más me gustaría que viera un ingeniero de datos— es rowspan. El caso t03 no solo queda deshilachado; desalineada datos en silencio. Una etiqueta rowspan=2 ("Fruit") se emite una sola vez, y la fila de debajo se convierte en una fila corta de dos columnas (| Banana | 8 |), así que "Banana" termina bajo la columna Group en vez de Item. Todos los tokens están ahí. Un consumidor ingenuo que haga "lee la segunda columna" obtiene el valor incorrecto. Ese es el tipo de bug que pasa un control de supervivencia de texto y corrompe una dataset sin hacer ruido.
La limitación de spans en sí es una restricción de diseño conocida y ya registrada (#1211, #1248): una cuadrícula plana de tubos GFM simplemente no puede representar spans ni anidación, así que el convertidor intercambia estructura por completitud de contenido. También hay comportamientos buenos: las tablas sin encabezado reciben una fila de encabezado vacía sintetizada (así ningún dato se promueve silenciosamente a encabezado), las celdas vacías se conservan y <caption> sobrevive como una línea de texto encima de la tabla.
Instalación y arranque: el peaje que una "utilidad ligera" no te advierte
Nada de esto me sorprendió más, y es donde la idea de "utilidad ligera en Python" promete un poco de más.
Primero, no instales pip install 'markitdown[all]'. En Python 3.14, hace un backtracking silencioso a markitdown 0.0.2, una versión de hace dos años, y lo reproduje en vivo en un venv limpio. Al fijarlo se ve por qué: pip install 'markitdown[all]==0.1.6' falla porque el extra [all] fija youtube-transcript-api~=1.0.0, y en PyPI actual cada build de ese rango está limitada a Python <3.14, mientras que las únicas builds compatibles con 3.14 quedan fuera de ese pin. Así que el resolver retrocede hasta la última versión cuyas dependencias sí puede satisfacer. Esto coincide con un issue abierto upstream (#2179). La solución es sencilla: fijar la versión e instalar los extras por separado: pip install 'markitdown==0.1.6', y luego pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Cada uno resuelve bien; solo el paquete combinado [all] arrastra ese pin problemático. (Esta trampa depende de la versión de Python: en Python 3.13 o anterior la restricción puede no afectar, así que [all] podría resolverse de otra manera.)
Segundo, el tamaño. La instalación base ocupa 161 MB (un venv vacío de 13 MB más 148 MB). De eso, onnxruntime (73 MB) y numpy (34 MB) suman 107 MB —el 66% de toda la huella base—, y ambos llegan por una sola dependencia dura: magika, el detector de tipo de archivo con ML de Google. O sea, un convertidor de texto trae de serie un runtime de inferencia ONNX de 73 MB antes de que añadas un solo extra de documentos. Si sumas los extras de documentos, el venv llega a 310 MB. Eso sigue siendo mucho más liviano que una pila con navegador sin interfaz gráfica, pero si esperabas una microutilidad de "instalar y listo", conviene saber que un runtime ONNX viene incluido.
Tercero —y este es el único hallazgo de todo mi conjunto que superó todas las pruebas de novedad que hice—, incluso tras una instalación limpia, import markitdown cuesta unos 3,35 segundos en esta máquina. El coste se concentra casi por completo en el momento del import: markitdown._markitdown importa de forma eager todo el registro de convertidores (2,56 s acumulados, 76% del total), lo que arrastra pandas (1,21 s, vía el convertidor XLSX), python-pptx (427 ms), magika (354 ms) y requests (270 ms), conviertas o no esos formatos. Para un servicio de larga duración, ese coste se amortiza y da igual. Para una invocación CLI o un cold start serverless, es un peaje real por proceso que la etiqueta de "utilidad ligera" no te hace esperar. (Matiz justo: esta es una sola ejecución perfilada, tratada como una observación, no una distribución de múltiples corridas.)
Escala: no se cae, pero reserva CPU para PDFs y RAM para hojas de cálculo
Pasé cuatro sujetos grandes por el sistema, cada uno en su propio proceso para que la memoria pico no quedara contaminada por una ejecución anterior. Nada se cayó. Pero el perfil de coste es desigual.
| Sujeto | Entrada | Caracteres de salida | Tiempo mediano | Δ RSS pico |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF de 492 páginas) | 6.07 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50,000 filas × 8 columnas | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15 páginas) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 filas × 64 columnas | 46 KB | 120,129 | 2.9 s | +22 MB |
El PDF NIST de 492 páginas tardó una mediana de 192,5 segundos —unos 3,2 minutos, o 0,39 s por página— porque pdfplumber ejecuta detección de formularios basada en la posición de las palabras en cada página. El RSS pico se quedó en +40 MB, así que el cuello de botella es CPU, no memoria. Incluso el PDF de arXiv de 15 páginas tardó 12,6 segundos en su propio proceso aislado, aproximadamente 3,4 veces más que los 3,7 segundos que mostró el mismo archivo en frío dentro de mi suite de documentos. Esa diferencia es el coste del proceso en frío, y confirma que el trabajo por página es lo que manda, no el tamaño bruto del archivo. Si necesitas un único número transferible para ese PDF, usa los 12,6 s aislados.
La ruta de hojas de cálculo invierte el cuello de botella. Un XLSX de 2,1 MB y 50.000 filas se disparó a +374 MB de RSS pico (y 3,7 millones de caracteres de salida) porque el convertidor carga toda la hoja y construye una única cadena Markdown gigantesca. Así que la guía práctica es directa: para PDFs grandes, reserva minutos de CPU; para hojas de cálculo grandes, reserva cientos de MB de RAM. Estos números son de una sola máquina en macOS arm64 y Python 3.14, y las constantes por página y por fila dependen de la plataforma, pero la forma del resultado —PDF lento y dependiente de CPU, XLSX pesado en memoria, nada se cae— sí se traslada.
Dónde encaja Thunderbit — y dónde no
Prueba Thunderbit para extraer datos web
Esta es la comparación en la que sería fácil exagerar, así que voy a marcar la línea con cuidado. MarkItDown y Thunderbit resuelven problemas vecinos, no el mismo.
MarkItDown convierte archivos que ya tienes. Thunderbit primero va y trae la página. El endpoint /distill de Thunderbit convierte una página web en vivo en Markdown limpio y listo para LLMs —manejando el renderizado JS, las protecciones anti-bot y el contenido dinámico para lo que MarkItDown no tiene mecanismos— y su endpoint /extract devuelve JSON estructurado que coincide con un esquema, no solo Markdown en bruto. Para desarrolladores, eso se expone como una API (POST /distill / POST /extract), un servidor MCP y una CLI (npx @thunderbit/thunderbit-cli) sobre un solo motor de IA, el mismo que está detrás de la extensión con más de 100.000 usuarios.
Así que coinciden en una sola cosa: ambos pueden emitir "Markdown listo para LLM". Pero el dominio de entrada es distinto: el distill de Thunderbit toma una URL de la web abierta, mientras que MarkItDown toma un archivo local. No son equivalentes intercambiables, y no voy a fingir que lo sean. La pila real usa ambos: rastreas y extraes la web con Thunderbit (o un servicio al estilo Firecrawl), y luego normalizas los documentos locales mixtos que también tienes —PDFs, presentaciones y hojas de cálculo— con MarkItDown. Uno maneja la red; el otro, la carpeta de archivos.
Pros y contras
Fortalezas
- Recuperación completa del body en HTML limpio (4/4 páginas), con árboles de encabezados y enlaces fielmente conservados
- Alta recuperación de texto en PDF/DOCX (probes arXiv 7/7, Bitcoin 6/6) y sin pérdida silenciosa de contenido en los fixtures de Office de los mantenedores
- Las ecuaciones de Office Math se conservan como LaTeX: una ventaja real de nicho
- No se cayó en ningún caso de escala, incluso con un PDF de 492 páginas y un XLSX de 50k filas
- Muy fácil de usar: CLI,
convert(), entrada por stdin y servidor MCP opcional - Licencia MIT, mantenimiento activo por Microsoft y tracker de issues receptivo
Debilidades
- Conserva el boilerplate: hasta 12,4% de líneas de interfaz en Wikipedia; no es un extractor de artículos
- Las tablas se rompen con spans, anidación y pipes dentro de celdas (2/13 rotas, 4/13 deshilachadas), y rowspan puede desalinear datos en silencio
- Los PDFs escaneados o solo imagen devuelven salida vacía, sin OCR y sin error
- La salida PDF tiene estructura de encabezados nula (coincide con benchmarks públicos)
- Instalación base de 161 MB con un runtime ONNX de 73 MB; import en frío de ~3,35 s
- El extra
[all]puede retroceder silenciosamente a una 0.0.2 de hace dos años en Python 3.14
Quién debería usarlo, y quién no
Usa MarkItDown si quieres estandarizar un montón de documentos locales mixtos —Word, Excel, PowerPoint, PDFs con capa de texto— en Markdown para un pipeline de LLM, y te importa más tener todo el texto que conservar la estructura original. Como convertidor de última milla en un trabajo por lotes, alimentando texto limpio a un modelo, es rápido, fiel y gratuito.
Sáltatelo, o combínalo con otra herramienta, si tu trabajo es cualquiera de estos: solo necesitas el artículo principal de una página web (usa una herramienta de legibilidad o estilo Firecrawl); necesitas que los encabezados y tablas de un PDF sobrevivan intactos (eso es territorio de Docling o Marker); o tus entradas incluyen documentos escaneados que requieren OCR (necesitarás el backend de Azure o directamente otra herramienta). Y si pensabas que estabas comprando un scraper —algo que trae y rastrea páginas—, esto no es eso en absoluto.
La puntuación provisional que obtuve, usando una rúbrica pensada para scrapers, deja a MarkItDown en 60/100, y ese total bajo es un artefacto de calificar un convertidor con una prueba de crawler. En su propio terreno, sus puntuaciones de fidelidad textual son altas; sus puntos débiles son estructurales (tablas, encabezados de PDF) y de empaquetado (huella, import, la trampa del [all]), no de calidad textual. Júzgalo por lo que es —un convertidor de archivos a Markdown— y verás que es una herramienta sólida y bien mantenida, con algunos bordes afilados que conviene conocer antes de llevarla a producción.
Preguntas frecuentes
¿MarkItDown es un web scraper?
No. No tiene crawler, no renderiza JavaScript, no sigue enlaces y no pagina. Convierte archivos y documentos que ya tienes —PDF, DOCX, XLSX, PPTX, imágenes, HTML— a Markdown. Si necesitas traer y rastrear páginas web en vivo, necesitas una herramienta de scraping como Thunderbit o Firecrawl; MarkItDown es el paso posterior, el que transforma archivos locales o ya obtenidos en Markdown limpio.
¿Por qué pip install markitdown[all] instala una versión antigua?
En Python 3.14, el extra [all] fija youtube-transcript-api~=1.0.0, y todas las versiones de ese rango están limitadas a Python por debajo de 3.14. El resolver no puede satisfacer ese pin, así que retrocede en silencio hasta markitdown 0.0.2, una versión de hace dos años. La solución es fijar la versión e instalar los extras por separado: pip install 'markitdown==0.1.6', y luego añadir 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Esto está registrado como issue #2179.
¿MarkItDown hace OCR en PDFs escaneados?
No en la instalación por defecto. Su ruta PDF solo extrae texto, así que un PDF solo de imágenes, sin capa de texto, devuelve una cadena vacía: sin error y sin aviso. El OCR requiere el backend opcional de Azure Document Intelligence o un plugin, ninguno incluido por defecto. Es una carencia que lleva tiempo documentada (issue #1268).
¿Qué tan bien maneja MarkItDown las tablas?
En cuanto al contenido, muy bien: en mi prueba de 13 casos conservó el 100% del contenido de las tablas en todos los casos. Estructuralmente, depende de la forma: las tablas simples, anchas, sin encabezado y con celdas vacías salen como cuadrículas GFM limpias, pero rowspan y colspan se deshilachan (y rowspan puede desalinear datos en la columna equivocada), las tablas anidadas se aplastan en filas basura y los pipes literales dentro de celdas no se escapan. El formato plano de tablas de Markdown simplemente no puede representar spans ni anidación.
¿MarkItDown es lo bastante rápido para documentos grandes?
No se cae con archivos grandes, pero reserva recursos según el tipo. Un PDF de 492 páginas tardó unos 3,2 minutos (aprox. 0,39 s por página) porque hace detección de formularios por página, y el cuello de botella es CPU. Una hoja de cálculo de 50.000 filas terminó en alrededor de un minuto, pero consumió +374 MB de RAM porque construye una única cadena Markdown enorme en memoria. Para PDFs grandes, calcula minutos de CPU; para hojas de cálculo grandes, calcula cientos de MB de RAM.
Prueba Thunderbit para extraer datos web Get Started Free
