O MarkItDown costuma ser colocado no mesmo saco que web scrapers, mas essa classificação está errada. Ele não tem crawler, não executa JavaScript e não oferece nenhum mecanismo para acessar uma URL e remover o conteúdo de navegação, rodapé e outros elementos repetitivos. O que ele faz é pegar bytes que você já tem — um PDF, um documento Word, uma planilha, um deck de slides — e transformar tudo em Markdown legível por um modelo de linguagem.
Passei algumas semanas testando o MarkItDown da Microsoft com um conjunto de documentos reais em um único Mac, verificando cada tabela contra um manifesto que preparei antes dos testes e cronometrando cada conversão. Resumindo: com entrada limpa, ele é rápido e fiel; no empacotamento, esconde um runtime de machine learning de 73 MB que você não pediu; e suas tabelas quebram de um jeito que passa no teste de "o texto sobreviveu?" e falha no de "os dados ficaram na coluna certa?". A seguir, o panorama completo, com números.
O que o MarkItDown realmente é
O MarkItDown é uma ferramenta em Python da Microsoft que converte arquivos e documentos do Office em Markdown otimizado para LLMs. Aponte para um PDF, .docx, .xlsx, .pptx, imagem, arquivo HTML ou alguns outros formatos, e ele devolve Markdown. Há três formas de usá-lo: pela CLI (markitdown file.pdf -o out.md, ou com entrada via stdin), pela API em Python (MarkItDown().convert(...)) e, opcionalmente, por um servidor MCP para fluxos com agentes.
A distinção mais importante é justamente o que ele não faz, porque isso não aparece como promessa no README e eu confirmei nos testes: não faz crawling, não renderiza JS, não segue links, não navega por paginação e não realiza extração do conteúdo principal no estilo Readability. Ele converte o documento inteiro. Você entra com os bytes; ele padroniza o conteúdo. Essa diferença, sozinha, define se a ferramenta entra ou não na sua stack — por isso vou retomar esse ponto várias vezes.
O repositório também chama atenção pelos números brutos do GitHub — 165.282 estrelas e 11.790 forks em meados de julho de 2026, licença MIT, com a versão mais recente (v0.1.6) lançada em 2026-05-26. Mas esse volume de estrelas reflete mais o entusiasmo geral com ferramentas para LLMs e o peso do nome Microsoft do que maturidade real da parte de conversão. Há também 833 issues abertas, e algumas delas importam para você antes da instalação (já chego nisso).
HTML para Markdown: rápido, completo, com o boilerplate junto
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 converteram com a instalação principal, sem extras, e todas as amostras do conteúdo principal sobreviveram. O artigo da Wikipedia sobre "Web scraping" (226 KB) saiu com a árvore de títulos espelhada — um h1, sete h2s e doze h3s, correspondendo à estrutura real da página — e 418 links preservados corretamente como [texto](url). A tabela de estatísticas de hóquei 26×9 da página Scrape This Site forms virou uma tabela GFM limpa com 27 linhas (cabeçalho + separador + 26 linhas de dados), inclusive células vazias. A velocidade não foi problema nesses casos: mediana de 48 ms para a página curta de citações e 352 ms para a Wikipedia de 226 KB.
Mas aqui está o detalhe, e ele é uma decisão de design, não um bug. O MarkItDown não remove boilerplate. Ele converte o conteúdo inteiro de <body>, então elementos de interface do site vêm junto — e esse resíduo cresce conforme o site tem mais “casca”.
| Página | Caracteres de saída | Títulos (h1/h2/h3) | Links | Linhas de interface 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 Books, quase sem elementos de interface, 0,6% das linhas de saída são chrome. Na Wikipedia, esse índice sobe para 12,4% — 42 das 338 linhas não vazias são coisas como "ir para o conteúdo", "alternar o sumário", "22 idiomas", "obtido de", cookies e rodapés de licença. Aqueles avisos de manutenção da Wikipedia ("Este artigo precisa de citações adicionais") até são renderizados fielmente como tabelas pipe de duas colunas, o que explica nove linhas de tabela em uma página sem nenhuma tabela de dados real.
Nada disso significa que o MarkItDown esteja errado. Ele é um conversor de documento inteiro, não um extrator de conteúdo limpo: converter HTML fielmente para Markdown é um trabalho diferente de extrair um artigo enxuto. Ferramentas como Trafilatura ou Firecrawl buscam retornar só o conteúdo principal; o MarkItDown devolve a página. Internamente, o _html_converter.py remove <script> e <style> e depois entrega o <body> inteiro para a biblioteca markdownify — sem heurística de conteúdo principal em nenhuma etapa. Se o que você quer é só o artigo, essa é a camada errada.
Seu habitat natural: PDF, DOCX, XLSX, PPTX
Documentos é para isso que o MarkItDown foi feito. Testei com arquivos públicos reais — um paper do arXiv com camada de texto, o whitepaper do Bitcoin, um PDF escaneado apenas em imagem que eu 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 (warm) | título, "Transformer", "BLEU", "References" presentes |
| Whitepaper do Bitcoin (PDF de 9 págs.) | 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 incorporados sobrevivem |
| 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 Office perdeu sequer um UUID sentinela, então não houve perda silenciosa de conteúdo nos fixtures de regressão dos mantenedores. Um ponto forte 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ê passa documentos Word cheios de fórmulas para um LLM, isso é uma vantagem concreta, ainda que nichada, e eu não vi isso documentado com clareza em outro lugar.
Dois achados nesse território merecem destaque próprio, porque são os que mais provavelmente vão te pegar desprevenido.
O PDF escaneado que simplesmente some
Passe um PDF apenas com imagem, sem camada de texto, para o MarkItDown, e ele devolve uma string vazia. Zero caracteres, sem exceção, sem aviso — convertido em cerca de 15 ms porque não há 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 na instalação principal nem em nenhum extra via pip.
Isso importa em lote. Um desenvolvedor que envia uma pasta de PDFs com alguns escaneados recebe resultados vazios silenciosamente para esses arquivos, sem nenhum sinal de que algo foi ignorado. Eu confirmei que o fixture não estava quebrado executando o extract_text do pdfminer diretamente nele — zero caracteres, nenhuma camada textual, confirmado — então a saída vazia é realmente o comportamento do MarkItDown em um PDF escaneado de verdade. Isso reproduz uma lacuna de fallback de OCR já antiga #1268, acompanhada há bastante tempo no upstream. O caminho documentado é o backend opcional Azure Document Intelligence ou um plugin; nenhum deles vem na instalação padrão.
PDFs saem como texto plano, não como estrutura
Nos dois PDFs com camada de texto, o MarkItDown produziu zero marcadores de título em Markdown. Um PDF não carrega tags semânticas de heading, e o MarkItDown não infere isso pelo tamanho da fonte, então cada linha cai no nível do corpo do texto. A recuperação textual é alta; a estrutura é plana.
Isso não é só meu resultado. Benchmarks públicos de terceiros colocam a hierarquia de títulos em PDFs do MarkItDown em algo próximo de 0,0 e a fidelidade de tabelas em cerca 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 esse comportamento, o que fortalece a evidência — meus números batem com uma fonte externa. O trade-off relatado pelos mesmos benchmarks é que o MarkItDown roda cerca de 100× mais rápido que o Docling, o que 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 de PDF limpo e rápido; não entrega a estrutura do PDF. Se títulos e tabelas precisarem sobreviver, uma ferramenta de layout como Docling ou Marker é a camada certa.
Tabelas: o conteúdo sempre sobrevive, a estrutura nem sempre
Tabelas são o ponto em que “o texto sobreviveu?” e “os dados ainda são utilizáveis?” deixam de ser a mesma pergunta, então montei uma matriz com 13 casos — uma <table> por caso, cada uma comparada com um manifesto escrito antes da execução — para mapear exatamente quais formatos seguram e quais quebram.
O resultado principal: o MarkItDown nunca perdeu o conteúdo de nenhuma tabela. Nos 13 casos, todos mantiveram 100% dos tokens pré-registrados. Já a fidelidade estrutural se dividiu em três grupos. Sete de 13 geraram uma grade GFM bem formada (simples, cabeçalho com colspan, 24 colunas, sem cabeçalho, células vazias, bloco dentro da célula e árabe da direita para a esquerda). Quatro ficaram bagunçadas, porque Markdown não tem conceito de célula mesclada, então rowspan, colspan e fontes malformadas geram linhas curtas. E duas quebraram de forma clara.
Vale nomear as duas falhas. Uma tabela aninhada (uma <table> dentro de um <td>) é achatada inline, jogando seus próprios pipes e sua própria linha separadora dentro da célula pai e produzindo uma linha lixo de 14 “colunas”. E um caractere literal | dentro da 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 emitir linhas com duas, três e quatro colunas, e qualquer parser de Markdown posterior lê os limites errados. Curiosamente, asteriscos e crases dentro da célula 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 a subclasse personalizada sobrescreve links, imagens e títulos, mas não células de tabela. A mesma classe de bug de escape de pipe é uma issue aberta para o conversor CSV (#2019), embora essa correção não afete o caminho HTML que eu testei.
O caso mais sutil — e o que eu mais gostaria que um engenheiro de dados visse — é o rowspan. O caso t03 não apenas fica torto; ele desalinha dados sem avisar. Um rótulo com rowspan=2 ("Fruit") aparece uma única 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. Todo token está lá. Um consumidor ingênuo que leia “a segunda coluna” pega o valor errado. É o tipo de erro que passa em checagem de sobrevivência de texto e corrompe silenciosamente um dataset.
A limitação de spans em si já é conhecida e acompanha o design (#1211, #1248) — uma grade GFM plana realmente não consegue representar spans ou aninhamento, então o conversor troca estrutura por completude de conteúdo. Há também comportamentos bons no conjunto: tabelas sem cabeçalho recebem uma linha de cabeçalho vazia 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 custo que uma “utilidade leve” não avisa
Nada aqui me surpreendeu mais, e é onde o enquadramento de "utilidade Python leve" exagera sem dizer.
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 — e eu reproduzi isso ao vivo em um venv limpo. Fixar a versão deixa claro o motivo: pip install 'markitdown[all]==0.1.6' falha porque o extra [all] prende youtube-transcript-api~=1.0.0, e no PyPI atual toda build nessa faixa exige Python <3.14, enquanto as únicas compatíveis com 3.14 ficam fora do pin. Assim, o resolvedor recua até a última versão cujas dependências consegue satisfazer. Isso bate com uma issue aberta no upstream (#2179). A solução é simples — fixe a versão e instale os extras individualmente: pip install 'markitdown==0.1.6', depois pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Cada um desses resolve sem problemas; o único pacote contaminado é o [all]. (Esse problema depende da versão do Python — no Python 3.13 ou anterior a trava pode não acontecer, então o [all] pode resolver de forma diferente.)
Segundo: a pegada. A instalação principal ocupa 161 MB (um venv vazio de 13 MB mais 148 MB). Desse total, onnxruntime (73 MB) e numpy (34 MB) somam 107 MB — 66% de toda a pegada principal — e ambos entram por uma única dependência obrigatória: magika, o detector de tipo de arquivo por ML do Google. Ou seja, um conversor de texto já vem com um runtime de inferência ONNX de 73 MB na instalação base, antes mesmo de você adicionar qualquer extra de documento. Com os extras de documentos, o venv chega a 310 MB. Isso é muito mais leve que uma stack com navegador headless, mas se você esperava uma ferramenta "instala e pronto" em estilo microutilitário, saiba que um runtime ONNX vem no pacote.
Terceiro — e este é o único achado de todo o meu conjunto que passou em todos os testes de novidade que rodei — mesmo após uma instalação limpa, import markitdown custa cerca de 3,35 segundos nesta máquina. O custo está quase todo no momento do import: markitdown._markitdown importa de forma antecipada todo o registro de conversores (2,56 s acumulados, 76% do total), o que puxa pandas (594 ms, via o conversor XLSX), python-pptx (427 ms), magika (354 ms) e requests (270 ms) — mesmo que você nunca converta esses formatos. Para 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 em serverless, é um imposto real por processo que a etiqueta de "utilidade leve" não faz você esperar. (Caveat justo: esta é uma única execução perfilada, tratada como uma observação, não uma distribuição com múltiplas medições.)
Escala: não trava, mas reserve CPU para PDFs e RAM para planilhas
Empurrei quatro casos grandes, cada um em seu próprio processo para que o pico de memória não fosse contaminado por execuções anteriores. Nada travou. Mas o perfil de custo é bem desequilibrado.
| Assunto | Entrada | Caracteres de saída | Tempo mediano | Variação de RSS no pico |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF de 492 páginas) | 5,9 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 do NIST com 492 páginas levou uma mediana de 192,5 segundos — cerca de 3,2 minutos, ou 0,39 s/página — porque o pdfplumber roda detecção de formulários e posição de palavras em cada página. O RSS máximo ficou em +40 MB, então o gargalo é CPU, não memória. Até o PDF do arXiv de 15 páginas levou 12,6 segundos em um processo isolado, cerca de 3,4× os 3,7 segundos que o mesmo arquivo mostrou em estado warm dentro da minha suíte de documentos. Essa diferença é o custo do processo frio e confirma que o trabalho por página, e não o tamanho bruto do arquivo, é o fator dominante. Se você quiser um número único e transferível para esse PDF, use os 12,6 s isolados.
O caminho de planilhas inverte o gargalo. Um XLSX de 2,1 MB com 50.000 linhas explodiu para +374 MB de RSS no pico (e 3,7 milhões de caracteres na saída) porque o conversor carrega a planilha inteira e monta uma única string grande de Markdown. Então a orientação prática é direta: PDFs grandes pedem minutos de CPU; planilhas grandes pedem centenas de MB de RAM. Esses números são de uma máquina única, em macOS arm64 e Python 3.14, e as constantes por página e por linha dependem da plataforma — mas o padrão geral (PDF é lento e consome CPU, XLSX é pesado em memória, nada trava) é transferível.
Onde o Thunderbit entra — e onde não entra
Experimente o Thunderbit para extração de dados da web
Esta é a comparação em que seria fácil exagerar, então vou delimitar com cuidado. MarkItDown e Thunderbit resolvem problemas próximos, mas não o mesmo problema.
O MarkItDown converte arquivos que você já possui. 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 não consegue tratar — e o endpoint /extract devolve JSON estruturado compatível com esquema, não apenas Markdown bruto. Para desenvolvedores, isso aparece como API (POST /distill / POST /extract), servidor MCP e CLI (npx @thunderbit/thunderbit-cli), tudo sobre o mesmo motor de IA, o mesmo por trás da extensão com mais de 100.000 usuários.
Então eles se sobrepõem em um único ponto — ambos podem gerar “Markdown pronto para LLM” — mas o domínio de entrada é diferente: o distill do Thunderbit trabalha com uma URL na web aberta, enquanto o MarkItDown trabalha com um arquivo local. Eles não são equivalentes plug-and-play, e eu não vou fingir que são. A pilha realista usa os dois: você coleta e rastreia a web com Thunderbit (ou um serviço no estilo Firecrawl) e depois normaliza os documentos locais mistos que você também tem — PDFs, apresentações e planilhas — com o MarkItDown. Um cuida da rede; o outro cuida da gaveta de arquivos.
Prós e contras
Pontos fortes
- Recuperação completa do corpo em HTML limpo (4/4 páginas), com árvores de títulos e links preservados com fidelidade
- Alta recuperação de texto em PDF/DOCX (probes 7/7 no arXiv, 6/6 no Bitcoin) e sem perda silenciosa de conteúdo nos fixtures Office dos mantenedores
- Equações do Office Math preservadas como LaTeX — uma vitória real, embora de nicho
- Não travou em nenhum teste de escala, até um PDF de 492 páginas e um XLSX com 50 mil linhas
- Muito simples de chamar: CLI,
convert(), pipe via stdin e servidor MCP opcional - Licença MIT, mantido ativamente pela Microsoft, tracker de issues responsivo
Pontos fracos
- Mantém boilerplate — até 12,4% de linhas de interface na Wikipedia; não é um extrator de artigo
- Tabelas quebram com spans, aninhamento e pipes dentro de células (2/13 quebradas, 4/13 irregulares), e rowspan desalinha dados silenciosamente
- PDFs escaneados/sem camada de texto retornam saída vazia, sem OCR e sem erro
- Saída de PDF sem nenhuma estrutura de títulos (em linha com benchmarks públicos)
- Instalação principal de 161 MB carregando um runtime ONNX de 73 MB; import frio de ~3,35 s
- O extra
[all]pode recuar silenciosamente para a versão 0.0.2, antiga, no Python 3.14
Quem deve usar, e quem não deve
Vale a pena usar o MarkItDown se você estiver padronizando um conjunto de documentos locais mistos — Word, Excel, PowerPoint, PDFs com camada de texto — em Markdown para um pipeline com LLM, e se você valoriza mais completude textual do que preservação de estrutura. Como conversor de última milha em um job em lote, alimentando texto limpo para um modelo, ele é rápido, fiel e gratuito.
Evite-o, ou combine com outra ferramenta, se o seu trabalho for qualquer um destes: você quer apenas o artigo principal de uma página web (use uma ferramenta de readability ou no estilo Firecrawl); você precisa que títulos e tabelas de um PDF sobrevivam intactos (isso é território de Docling ou Marker); ou suas entradas incluem documentos escaneados que precisam de OCR (você vai precisar do backend Azure ou de outra ferramenta por completo). E se você achava que estava comprando um scraper — algo que busca e rastreia páginas — isso definitivamente não é o caso.
A pontuação provisória que eu rodei, em uma rubrica moldada para scraper, coloca o MarkItDown em 60/100, e esse total baixo é um artefato de avaliar um conversor com um teste de crawler. No seu terreno, os scores de fidelidade textual são altos; os pontos fracos são estruturais (tabelas, títulos em PDF) e de empacotamento (pegada, importação, a armadilha do [all]), não de qualidade do texto. Julgue-o pelo que ele é — um conversor de arquivo para Markdown — e você tem uma ferramenta sólida, bem mantida, com algumas arestas que vale conhecer antes de colocá-la 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 nem faz paginação. Ele converte arquivos e documentos que você já tem — PDF, DOCX, XLSX, PPTX, imagens, HTML — em Markdown. Se você precisa buscar e rastrear páginas web ao vivo, use uma ferramenta de scraping como Thunderbit ou Firecrawl; o MarkItDown entra depois, transformando arquivos locais ou já coletados 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 versões dessa faixa são limitadas a Python abaixo de 3.14. Como o resolver não consegue satisfazer esse pin, ele recua silenciosamente para o markitdown 0.0.2, uma versão de dois anos atrás. A correção é fixar a versão e instalar os extras separadamente: pip install 'markitdown==0.1.6', depois adicionar 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Isso está sendo acompanhado 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 apenas com imagem e sem camada textual retorna string vazia — sem erro, sem aviso. OCR exige o backend opcional Azure Document Intelligence ou um plugin, e nenhum deles vem por padrão. Essa é uma lacuna antiga issue #1268.
Quão bem o MarkItDown lida com tabelas?
Em termos de conteúdo, muito bem — no meu teste com 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 desalinha 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 plano de tabela do Markdown simplesmente não consegue representar spans ou aninhamento.
O MarkItDown é rápido o suficiente para documentos grandes?
Ele não trava com arquivos grandes, mas o uso de recursos depende do tipo. Um PDF de 492 páginas levou cerca de 3,2 minutos (aproximadamente 0,39 s/página) porque faz detecção de formulários por página, então é limitado por CPU. Uma planilha com 50.000 linhas terminou em cerca de um minuto, mas consumiu +374 MB de RAM porque monta uma string grande de Markdown 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
