O MarkItDown costuma ser colocado no mesmo grupo dos web scrapers, mas isso não faz sentido. Ele não tem crawler, não tem motor JavaScript e não consegue buscar uma URL para remover o conteúdo de navegação e outros elementos de página. O que ele faz é pegar bytes que você já tem — um PDF, um documento do Word, uma planilha, um conjunto de slides — e transformar tudo em Markdown, pronto para ser lido por um modelo de linguagem.
Passei algumas semanas executando o MarkItDown da Microsoft em uma bateria de documentos reais em um único Mac, atribuindo notas a cada tabela com base em um manifesto que criei antes do teste e cronometrando cada conversão. Resumindo: com entrada limpa, ele é rápido e fiel; o empacotamento esconde um runtime de machine learning de 73 MB que você talvez nem quisesse; e suas tabelas quebram de um jeito que passa no teste “o texto sobreviveu?” e falha no teste “os dados ficaram na coluna certa?”. Abaixo está o panorama completo, com números.
O que o MarkItDown realmente é
O MarkItDown é um utilitário em Python da Microsoft que converte arquivos e documentos do Office em Markdown otimizado para LLMs. Aponte para um PDF, .docx, .xlsx, .pptx, uma imagem, um arquivo HTML ou alguns outros formatos, e ele devolve Markdown. Ele pode ser usado de três formas: pela CLI (markitdown file.pdf -o out.md, ou recebendo dados via stdin), pela API em Python (MarkItDown().convert(...)) e por um servidor MCP opcional para fluxos de trabalho com agentes.
O ponto mais importante é o que ele não faz, porque o README não promete isso e eu confirmei nos testes: não há crawling, não há renderização de JS, não há acompanhamento de links, não há paginação e não existe extração do conteúdo principal no estilo de ferramentas de legibilidade. Ele converte o documento inteiro. Você fornece os bytes; ele os padroniza. Essa única diferença define se a ferramenta entra ou não no seu stack, então vou voltar a esse ponto várias vezes.
O próprio repositório é pesado pelos critérios de popularidade do GitHub — 165.282 estrelas e 11.790 forks em meados de julho de 2026, sob licença MIT, com a versão mais recente (v0.1.6) lançada em 26/05/2026. Mas esse número de estrelas reflete um repositório da Microsoft surfando o interesse geral por ferramentas de LLM, e não necessariamente maturidade do núcleo de conversão. Também há 833 issues abertas, e algumas delas são importantes antes da instalação (mais sobre isso abaixo).
HTML para Markdown: rápido, completo e com boilerplate incluso
Como o restante da minha série de análises de scrapers usa os mesmos quatro fixtures da web, alimentei o MarkItDown com os mesmos arquivos HTML locais — não para avaliá-lo como scraper, mas para ver quão boa é a conversão de HTML para Markdown. Em páginas bem estruturadas, ele é realmente bom.
As quatro páginas foram convertidas com a instalação principal, sem extras, e todas as verificações do corpo do conteúdo foram preservadas. O artigo “Web scraping” da Wikipedia (226 KB) saiu com a árvore de títulos espelhada — um h1, sete h2s e doze h3s, correspondendo à estrutura real do artigo — e 418 links preservados corretamente como [texto](url). A tabela de estatísticas de hóquei 25×9 da página Scrape This Site forms virou uma tabela GFM limpa de 27 linhas (cabeçalho + separador + 26 linhas de dados), inclusive com células vazias. A velocidade também não foi problema nesses casos: mediana de 48 ms na página pequena de citações até 352 ms na página da Wikipedia de 226 KB.
Mas aqui está o detalhe, e ele é uma escolha de design, não um bug. O MarkItDown não remove boilerplate. Ele converte o <body> inteiro, então elementos de navegação e layout vêm junto — e o resíduo cresce conforme a página tem mais chrome.
| Página | Caracteres de saída | Títulos (h1/h2/h3) | Links | Linhas de chrome do site |
|---|---|---|---|---|
| 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) |
Na página inicial do Books, quase sem chrome, 0,6% das linhas de saída são chrome. Na Wikipedia, isso sobe para 12,4% — 42 de 338 linhas não vazias são coisas como “pular para o conteúdo”, “alternar o sumário”, “22 idiomas”, “obtido de”, além de rodapés de cookies e licença. Até banners de manutenção da Wikipedia (“Este artigo precisa de mais citações”) são renderizados fielmente em tabelas pipe de duas colunas, o que explica nove linhas de tabela em uma página que não tem nenhuma tabela de dados real.
Nada disso é o MarkItDown fazendo algo errado. Ele é um conversor de documento inteiro, não um extrator de legibilidade: HTML para Markdown com fidelidade é um trabalho diferente de extrair apenas o artigo limpo. Ferramentas como Trafilatura e Firecrawl tentam devolver só o conteúdo principal; o MarkItDown devolve a página. Por baixo dos panos, o _html_converter.py remove <script> e <style>, depois passa o <body> inteiro para a biblioteca markdownify — sem heurística de conteúdo principal em lugar nenhum do caminho. Se o objetivo é só o artigo, esse não é o nível certo de processamento.
O território natural: PDF, DOCX, XLSX, PPTX
Documentos são o que o MarkItDown faz melhor. Testei com arquivos públicos reais — um paper do arXiv com camada de texto, o whitepaper do Bitcoin, um PDF escaneado apenas com imagem que renderizei sem texto algum, e os arquivos DOCX/XLSX/PPTX da própria suíte de testes do MarkItDown (com UUIDs inseridos para detectar perda silenciosa de conteúdo).
| Documento | Entrada | Caracteres de saída | Probes | Tempo mediano | Observações |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF com camada de texto) | 2,2 MB | 40.174 | 7/7 | 3,7 s (quente) | título, “Transformer”, “BLEU” e “References” presentes |
| Whitepaper do Bitcoin (PDF de 9 páginas) | 184 KB | 22.485 | 6/6 | 1,4 s | “Satoshi Nakamoto”, “proof-of-work”, “Conclusion” presentes |
| PDF escaneado (sem camada de texto) | 89 KB | 0 | 0/4 | 15 ms | saída vazia, sem erro, sem OCR |
| DOCX (test.docx) | 136 KB | 4.651 | — | 70 ms | títulos + tabela GFM; UUIDs embutidos preservados |
| DOCX com equações | 15 KB | 240 | — | 101 ms | Office Math preservado como LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | cada planilha → ## NomeDaPlanilha + tabela GFM |
| PPTX (test.pptx) | 278 KB | 2.047 | — | 52 ms | marcadores de número do slide, tabelas, gráfico → tabela |
A recuperação de texto nos PDFs com camada textual foi excelente — 7 de 7 probes pré-registrados no paper do arXiv “Attention Is All You Need”, 6 de 6 no whitepaper do Bitcoin — e nenhum dos arquivos do Office perdeu um único UUID sentinela. Ou seja: sem perda silenciosa de conteúdo nos fixtures de regressão da própria equipe. Um ponto positivo bem específico: o caminho de DOCX (via mammoth) preserva equações do Office Math como LaTeX, convertendo equations.docx em matemática real com $$...$$. Se você estiver alimentando documentos Word pesados em matemática para um LLM, isso é uma força real, embora bem específica, que eu não encontrei documentada em outro lugar.
Dois achados nesse terreno merecem atenção própria, porque são os mais propensos a te pegar desprevenido.
O PDF escaneado que desaparece
Se você entregar ao MarkItDown um PDF só com imagem, sem camada de texto, ele retorna uma string vazia. Zero caracteres, sem exceção, sem aviso — convertido em cerca de 15 ms porque não havia nada a extrair. O caminho de PDF do MarkItDown faz apenas extração de texto (com pdfminer e pdfplumber por baixo), e não inclui OCR nem na instalação principal nem em qualquer extra do pip.
Isso importa em lote. Um desenvolvedor que processa uma pasta de PDFs com alguns escaneados terá resultados vazios silenciosos nesses arquivos, sem sinal de que algo foi ignorado. Verifiquei que o fixture não estava quebrado rodando extract_text do pdfminer diretamente nele — zero caracteres limpos, sem camada de texto, confirmado — então a saída vazia é o comportamento real do MarkItDown em um PDF escaneado de verdade. Isso reproduz uma lacuna de OCR aberta há bastante tempo (#1268), já acompanhada upstream faz um bom tempo. O caminho documentado é usar o backend opcional Azure Document Intelligence ou um plugin; nenhum dos dois vem na instalação padrão.
PDFs saem como texto plano, sem estrutura
Nos dois PDFs com camada de texto, o MarkItDown produziu zero marcadores de heading em Markdown. Um PDF não traz tags semânticas de título, e o MarkItDown não infere isso pelo tamanho da fonte, então cada linha acaba no nível do corpo. A recuperação do texto é alta; a estrutura é plana.
Isso não é só o meu resultado. Benchmarks públicos de terceiros mostram a hierarquia de headings em PDF do MarkItDown em cerca de 0,0 e a fidelidade de tabelas em torno de 0,27, bem abaixo do 0,88 do Docling com TableFormer (veja a comparação MarkItDown vs Docling vs Marker e o benchmark READoc). Meus fixtures reproduzem esses resultados, o que fortalece a evidência — meus números batem com uma fonte externa. O mesmo benchmark também indica que o MarkItDown roda cerca de 100× mais rápido que o Docling, e isso combina com meus tempos em segundos, e não minutos, em documentos que uma ferramenta baseada em modelo de layout leva minutos para processar. A conclusão: o MarkItDown entrega texto limpo e rápido de PDF; ele não entrega a estrutura do PDF. Se headings e tabelas precisam sobreviver, a camada certa é uma ferramenta com modelo de layout, como Docling ou Marker.
Tabelas: o conteúdo sempre sobrevive, mas a estrutura nem sempre
É nas tabelas que “o texto sobreviveu?” e “os dados continuam utilizáveis?” se separam, então montei uma matriz de 13 casos — uma <table> por caso, cada uma avaliada contra um manifesto criado antes da execução — para mapear exatamente quais formatos aguentam e quais quebram.
O resumo principal: o MarkItDown nunca perdeu conteúdo de tabela. Todos os 13 casos preservaram 100% dos tokens pré-registrados. Já a fidelidade estrutural se dividiu em três grupos. Sete de treze produziram uma grade GFM bem formada (tabela simples, header-colspan, 24 colunas, sem cabeçalho, células vazias, bloco dentro da célula e árabe da direita para a esquerda). Quatro ficaram irregulares, porque Markdown não tem conceito de célula expandida, então rowspan, colspan e fontes malformadas geram linhas curtas. E duas quebraram de verdade.
As duas que quebram merecem ser nomeadas. Uma tabela aninhada (uma <table> dentro de uma <td>) é achatada inline, despejando seus próprios pipes e a linha separadora na célula pai e gerando uma linha lixo de 14 “colunas”. E um | literal dentro de uma célula não é escapado — o texto a | b vira duas colunas, x || y vira três — então uma tabela de duas colunas passa a produzir linhas de duas, três e quatro colunas, e qualquer parser de Markdown a jusante interpreta os limites errados. Curiosamente, asteriscos e backticks dentro das células são escapados; pipes, não. A causa raiz é que o caminho HTML do MarkItDown usa o tratamento padrão de tabelas do markdownify, e sua subclasse personalizada sobrescreve links, imagens e headings, mas não células de tabela. A mesma classe de bug de escape de pipe aparece em uma issue aberta para o conversor CSV (#2019), embora essa correção não atinja o caminho HTML que eu testei.
O ponto mais sutil — e o que eu mais gostaria que um engenheiro de dados visse — é o rowspan. O caso t03 não fica apenas irregular; ele desalinha os dados silenciosamente. Um rótulo com rowspan=2 (“Fruit”) é emitido uma vez, e a linha abaixo vira uma linha curta de duas colunas (| Banana | 8 |), então “Banana” cai sob a coluna Group em vez de Item. Todos os tokens estão lá. Um consumidor ingênuo que “lê a segunda coluna” vai pegar o valor errado. Esse é o tipo de bug que passa em uma verificação de sobrevivência de texto e corrompe o conjunto de dados sem fazer barulho.
A própria limitação de spans é uma restrição de design conhecida e já acompanhada (#1211, #1248) — uma grade GFM plana realmente não consegue representar spans nem aninhamento, então o conversor troca estrutura por completude de conteúdo. Mas também há comportamentos bons no meio disso: tabelas sem cabeçalho recebem uma linha de cabeçalho em branco sintetizada (assim nenhum dado é promovido silenciosamente a cabeçalho), células vazias são preservadas e <caption> sobrevive como uma linha de texto acima da tabela.
Instalação e inicialização: o preço que um “utilitário leve” não avisa
Nada aqui me surpreendeu mais, e é onde a imagem de “utilitário Python leve” promete mais do que entrega.
Primeiro, não rode pip install 'markitdown[all]'. No Python 3.14, isso faz o resolver voltar silenciosamente para o markitdown 0.0.2 — uma versão de dois anos atrás —, o que eu reproduzi ao vivo em um virtualenv limpo. Fixar a versão mostra o motivo: pip install 'markitdown[all]==0.1.6' falha porque o extra [all] fixa youtube-transcript-api~=1.0.0, e no PyPI atual cada build nessa faixa exige Python <3.14, enquanto as únicas builds compatíveis com 3.14 ficam fora da restrição. Então o resolvedor retrocede até a última release cujas dependências consegue satisfazer. Isso bate com uma issue aberta upstream (#2179). A correção é simples — fixe a versão e instale os extras separadamente: pip install 'markitdown==0.1.6', depois pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Cada um deles resolve normalmente; o problema está só no pacote combinado [all]. (Esse armadilha depende da versão do Python — no Python 3.13 ou anterior, talvez o bloqueio não apareça e o [all] resolva de outro jeito.)
Segundo, a pegada. A instalação principal ocupa 161 MB (um virtualenv vazio de 13 MB mais 148 MB). Desse total, onnxruntime (73 MB) e numpy (34 MB) somam 107 MB — 66% da pegada total do core — e ambos entram por causa de uma única dependência obrigatória: magika, o detector de tipo de arquivo com ML do Google. Ou seja: um conversor de texto já traz um runtime ONNX de inferência de 73 MB na instalação base, antes mesmo de você adicionar qualquer extra de documento. Com os extras de documentos instalados, o virtualenv chega a 310 MB. Isso é bem mais leve do que um stack com navegador headless, mas se você esperava um micro-utilitário “instalou e pronto”, saiba que um runtime ONNX vem junto.
Terceiro — e este é o único achado do conjunto que passou em todos os testes de novidade que executei — mesmo após uma instalação limpa, import markitdown custa cerca de 3,35 segundos neste computador. O custo acontece quase todo no import: markitdown._markitdown carrega de forma antecipada todo o registro de conversores (2,56 s acumulados, 76% do total), o que puxa pandas (1,21 s, via o conversor XLSX), python-pptx (427 ms), magika (354 ms) e requests (270 ms) — mesmo que você nunca converta esses formatos. Em um serviço de longa duração, esse custo se dilui e não importa muito. Para uma chamada de CLI ou um cold start serverless, porém, é um imposto real por processo, algo que o rótulo “utilitário leve” não faz você esperar. (Observação justa: este foi um único perfil de execução, tratado como uma observação isolada, não como distribuição de múltiplas execuções.)
Escala: não quebra, mas reserve CPU para PDFs e RAM para planilhas
Passei quatro casos grandes por ele, cada um em um processo separado para que o pico de memória não fosse contaminado por execuções anteriores. Nada travou. Mas o perfil de custo é bem desigual.
| Sujeito | Entrada | Caracteres de saída | Tempo mediano | Δ RSS máximo |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF de 492 páginas) | 6,07 MB | 1.625.365 | 192,5 s | +40 MB |
| XLSX 50.000 linhas × 8 colunas | 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 linhas × 64 colunas | 46 KB | 120.129 | 2,9 s | +22 MB |
O PDF de 492 páginas do NIST levou mediana de 192,5 segundos — cerca de 3,2 minutos, ou 0,39 s/página — porque o pdfplumber faz detecção de formulários e posições das palavras em cada página. O RSS máximo ficou em +40 MB, então o gargalo é CPU, não memória. Até mesmo o PDF do arXiv com 15 páginas levou 12,6 segundos em processo isolado, cerca de 3,4× os 3,7 segundos que o mesmo arquivo mostrou “quente” dentro da minha suíte de documentos. Essa diferença é o custo do processo frio, e confirma que o trabalho por página é o que manda, não o tamanho bruto do arquivo. Se você quiser um número único para esse PDF, use os 12,6 s isolados.
O caminho das planilhas inverte o gargalo. Um XLSX de 2,1 MB com 50.000 linhas explodiu para +374 MB de RSS máximo (e 3,7 milhões de caracteres de saída), porque o conversor carrega a planilha inteira e monta uma única string gigante em Markdown. Então a orientação prática é direta: PDFs grandes exigem minutos de CPU; planilhas grandes exigem centenas de MB de RAM. Esses números foram obtidos em uma máquina única, no macOS arm64 e Python 3.14, então as constantes por página e por linha são específicas da plataforma — mas a forma geral do resultado (PDF é lento e consome CPU; XLSX pesa na memória; nada quebra) é o que realmente se transfere.
Onde o Thunderbit entra — e onde não entra
Experimente o Thunderbit para extração de dados da web
Essa é a comparação em que seria fácil exagerar, então vou delimitar com cuidado. MarkItDown e Thunderbit resolvem problemas vizinhos, não o mesmo problema.
O MarkItDown converte arquivos que você já tem. O Thunderbit busca a página primeiro. O endpoint /distill do Thunderbit transforma uma página web ao vivo em Markdown limpo, pronto para LLM — lidando com renderização JS, anti-bot e conteúdo dinâmico que o MarkItDown simplesmente não sabe processar — e o endpoint /extract devolve JSON estruturado e compatível com schema, não apenas Markdown bruto. Para desenvolvedores, isso fica disponível como API (POST /distill / POST /extract), servidor MCP e CLI (npx @thunderbit/thunderbit-cli) em cima de um único mecanismo de IA, o mesmo por trás da extensão com mais de 100.000 usuários.
Então há uma sobreposição em uma única coisa — ambos podem emitir “Markdown pronto para LLM” —, mas o domínio de entrada é diferente: o distill do Thunderbit recebe uma URL da web aberta, enquanto o MarkItDown recebe um arquivo local. Eles não são equivalentes plug-and-play, e eu não vou fingir que são. O stack realista usa os dois: buscar e fazer crawling da web com Thunderbit (ou um serviço no estilo Firecrawl), e depois normalizar os documentos locais mistos que você também tem — PDFs, apresentações e planilhas — com o MarkItDown. Um lida com a rede; o outro lida com a gaveta de arquivos.
Prós e contras
Pontos fortes
- Recuperação completa do corpo em HTML limpo (4/4 páginas), com árvore de headings e links preservados com fidelidade
- Alta recuperação de texto em PDF/DOCX (arXiv 7/7 probes, Bitcoin 6/6) e sem perda silenciosa de conteúdo nos fixtures de Office da própria equipe
- Equações do Office Math preservadas como LaTeX — uma vitória de nicho, mas real
- Não travou em nenhum teste de escala, até um PDF de 492 páginas e um XLSX de 50 mil linhas
- Muito fácil de usar: CLI,
convert(), pipeline via stdin e servidor MCP opcional - Licença MIT, manutenção ativa pela Microsoft e tracker de issues responsivo
Pontos fracos
- Mantém boilerplate — até 12,4% de linhas de chrome na Wikipedia; não é extrator de artigos
- Tabelas quebram com spans, aninhamento e pipes dentro da célula (2/13 quebradas, 4/13 irregulares), e rowspan pode desalinha dados silenciosamente
- PDFs escaneados ou só de imagem retornam saída vazia, sem OCR e sem erro
- A saída de PDF não preserva estrutura de headings (em linha com benchmarks públicos)
- Instalação principal de 161 MB, carregando um runtime ONNX de 73 MB; import inicial de ~3,35 s
- O extra
[all]regride silenciosamente para uma versão 0.0.2 de dois anos atrás no Python 3.14
Quem deve usar e quem não deve
Vale a pena usar o MarkItDown se você quer padronizar um conjunto de documentos locais mistos — Word, Excel, PowerPoint, PDFs com camada de texto — em Markdown para um pipeline com LLM, e se você se importa mais com completude do texto do que com preservação da estrutura. Como conversor final de um processo em lote, alimentando um modelo com texto limpo, ele é rápido, fiel e gratuito.
Evite-o, ou combine com outra ferramenta, se o seu trabalho for qualquer um destes: você precisa apenas do artigo principal de uma página web (use uma ferramenta de legibilidade ou algo no estilo Firecrawl); você precisa que headings e tabelas de um PDF sobrevivam intactos (aí é território de Docling ou Marker); ou suas entradas incluem documentos escaneados que exigem OCR (você vai precisar do backend Azure ou de outra ferramenta). E, se você achava que estava procurando um scraper — algo que busca e faz crawling —, isso definitivamente não é.
A pontuação provisória que eu atribuí, usando uma rubrica no estilo de scraper, coloca o MarkItDown em 60/100, e esse número baixo é um artefato de avaliar um conversor com um teste feito para crawler. No seu próprio terreno, os scores de fidelidade de texto são altos; os pontos fracos são estruturais (tabelas, headings de PDF) e de empacotamento (pegada, import, armadilha do [all]), não de qualidade textual. Julgue-o pelo que ele é — um conversor de arquivo para Markdown — e você terá uma ferramenta sólida, bem mantida, com algumas arestas que é bom conhecer antes de colocar em produção.
Perguntas frequentes
O MarkItDown é um web scraper?
Não. Ele não tem crawler, não renderiza JavaScript, não segue links e não faz paginação. Ele converte arquivos e documentos que você já possui — PDF, DOCX, XLSX, PPTX, imagens, HTML — em Markdown. Se você precisa buscar e rastrear páginas ao vivo, precisa de uma ferramenta de scraping como Thunderbit ou Firecrawl; o MarkItDown é a etapa seguinte, convertendo arquivos obtidos ou locais em Markdown limpo.
Por que pip install markitdown[all] instala uma versão antiga?
No Python 3.14, o extra [all] fixa youtube-transcript-api~=1.0.0, e todas as builds nessa faixa exigem versões de Python abaixo de 3.14. Como o resolvedor não consegue satisfazer essa restrição, ele retrocede silenciosamente para o markitdown 0.0.2, uma versão de dois anos atrás. A solução é fixar a versão e instalar os extras individualmente: pip install 'markitdown==0.1.6', depois adicionar 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Isso está registrado na issue #2179.
O MarkItDown faz OCR em PDFs escaneados?
Não na instalação padrão. O caminho de PDF faz apenas extração de texto, então um PDF só de imagem, sem camada textual, retorna uma string vazia — sem erro e sem aviso. OCR exige o backend opcional Azure Document Intelligence ou um plugin, nenhum dos quais vem por padrão. Essa lacuna já é acompanhada há bastante tempo (issue #1268).
Como o MarkItDown lida com tabelas?
Em termos de conteúdo, muito bem — no meu teste de 13 casos, ele preservou 100% do conteúdo das tabelas em todos os cenários. Estruturalmente, depende do formato: tabelas simples, largas, sem cabeçalho e com células vazias saem como grades GFM limpas, mas rowspan e colspan ficam irregulares (e rowspan pode deslocar dados silenciosamente para a coluna errada), tabelas aninhadas são achatadas em linhas lixo e caracteres pipe literais dentro das células não são escapados. O formato de tabela do Markdown é plano demais para representar spans ou aninhamento.
O MarkItDown é rápido o suficiente para documentos grandes?
Ele não trava com arquivos grandes, mas você precisa planejar os recursos conforme o tipo de documento. Um PDF de 492 páginas levou cerca de 3,2 minutos (aprox. 0,39 s/página) porque faz detecção por página, então é limitado por CPU. Uma planilha com 50.000 linhas terminou em cerca de um minuto, mas usou +374 MB de RAM porque constrói uma string Markdown enorme na memória. Para PDFs grandes, planeje minutos de CPU; para planilhas grandes, planeje centenas de MB de RAM.
Experimente o Thunderbit para extração de dados da web Get Started Free
