PDF para Markdown: por que a tabela quebra (7 PDFs testados)

Você converteu um PDF para Markdown e a tabela saiu errada. Normalmente isso não é culpa de como você fez a conversão: o próprio PDF não guarda a tabela visível como tabela. Este artigo explica o mecanismo, mostra o que realmente aconteceu em 7 documentos que medimos e o que fazer quando uma tabela sai quebrada.

A maioria dos PDFs não guarda a tabela visível como tabela

Um PDF descreve como pintar uma página, não como o documento está organizado. O conteúdo de cada página fica em um content stream, e o que existe ali é uma sequência de operadores de desenho com seus operandos: coloque este glifo nesta posição, trace uma linha aqui (capítulos de Graphics e Text da referência Adobe PDF 1.7Abre em uma nova aba). As linhas de uma tabela são instruções de traçado. O conteúdo das células são glifos posicionados perto dessas linhas. Nada padronizado liga as duas coisas.

Isso aparece com a mesma clareza no que as bibliotecas de leitura de PDF devolvem. Um TextItem do getTextContent() do pdf.js carrega str, transform, width, height, hasEOL e campos parecidos: nenhum índice de linha, nenhum índice de coluna, nenhuma identidade de célula (documentação da API do PDF.jsAbre em uma nova aba). O conversor precisa deduzir a grade a partir da posição dos glifos e das linhas.

Existe uma exceção. Um PDF marcado para acessibilidade pode carregar elementos de estrutura reais: um elemento Table, linhas TR e células TH ou TD, com os atributos RowSpan e ColSpan para células mescladas (técnica PDF6 do W3C: Using table elements for table markup in PDF DocumentsAbre em uma nova aba). Mas marcar é uma decisão de quem cria o arquivo. Nada garante que o PDF no seu disco esteja marcado, e sem as marcações o conversor volta a adivinhar.

Em 7 documentos, duas rotas de extração falharam em direções opostas

Para ver quanto custa adivinhar, passamos 7 documentos de características diferentes — dois artigos acadêmicos, um documento técnico governamental, um formulário fiscal, um relatório estatístico denso, uma apresentação e um relatório de banco central — por duas rotas que funcionam de formas distintas.

• Rota de extração de texto: pdf.js (pdfjs-dist 6.2.108) com pdf2md (@opendocsg/pdf2md 0.2.7). Não tem nenhuma etapa de montagem de tabelas.
• Rota de inferência de estrutura: pdf-inspector (@firecrawl/pdf-inspector-wasm 0.1.3). Deduz a estrutura da tabela a partir de retângulos, fontes e coordenadas.

Medição de 2026-08-02 em um Apple M5 Pro com macOS (Darwin 25.5.0) e Node v26.3.1. Os 7 documentos têm camada de texto; não há nenhum PDF digitalizado no conjunto. O script de download, o de medição e a saída bruta estão no repositório deste site, em scripts/benchmarks/pdf-table-extraction/.

Duas coisas chamam atenção. A rota de texto produziu zero linhas de tabela nos 7 documentos, ou seja, nunca constrói uma tabela. A rota de inferência sempre constrói uma, e a contagem de linhas não diz nada sobre ela estar certa.

O caso que prova isso é o seguinte. O relatório de banco central em várias colunas quebrou completamente — o título e o corpo do texto foram parar dentro de células — e mesmo assim as linhas de tabela representavam 0,43 da saída. O formulário fiscal, que tem tabelas de verdade, fica em 0,45. Nenhum limiar separa esses dois valores. Sair muita linha de tabela não é prova de que a tabela foi extraída corretamente.

Falha 1 — a tabela é abandonada e sobra texto corrido

No primeiro modo de falha a tabela nunca aparece como tabela. O texto das células é capturado, mas os limites de linha e coluna somem, então números e rótulos ficam emendados como frases comuns. Foi o que a rota de extração de texto fez: zero linhas de tabela em todos os documentos.

Essa falha tem um ponto a favor: dá para ver na hora. Uma tabela que simplesmente não está onde deveria haver uma tabela é impossível de passar batido, e isso facilita a decisão de voltar ao original.

Vale nomear um efeito colateral. Às vezes as linhas da tabela são promovidas a títulos. No relatório estatístico de vários níveis, a rota de texto gerou 1360 títulos; uma contagem manual coloca os títulos reais em torno de 4. Se o seu sumário de repente tem centenas de entradas, a causa é essa.

Falha 2 — sai uma tabela, mas as células ficam atribuídas errado

O segundo modo de falha produz uma tabela Markdown válida cujos valores estão nas células erradas. Foi o que a rota de inferência de estrutura fez. O relatório estatístico saiu como 405 linhas de tabela, com vários anos de números colapsados em uma única célula.

|15～ 64歳 6625 5878 6678 5893 6732 5912 …|15～ 24歳 595|25～ 34歳 1168|

Cada bloco dessa linha deveria ser uma linha com uma faixa etária e um número por ano. Na saída, seis números de anos diferentes ficaram dentro da mesma célula.

Essa é a falha perigosa. Os pipes e a linha separadora estão bem formados, então a tabela renderiza direito e é colada num documento sem revisão. Um valor deslocado uma coluna é invisível para quem não tem o original na frente. Está quebrado sem parecer quebrado, e por isso é um problema diferente da falha 1.

Diagramas e texto em várias colunas podem ser detectados como tabela

A inferência também dispara em coisas que não são tabelas. Das medições saíram dois casos concretos.

No NIST Cybersecurity Framework 2.0, o texto colocado dentro do diagrama circular do CSF Core (Fig. 1) foi emitido como tabela, e ainda perdeu as letras iniciais:

| Fig. 1. CSF Core structure |||
| --- | --- | --- |
| DENTIFY | ROTECT | ETECT ESPOND |

Os rótulos reais são IDENTIFY, PROTECT, DETECT e RESPOND. O texto disposto ao longo da curva do anel foi partido e o primeiro caractere de cada rótulo foi tratado como elemento separado, deixando palavras sem sentido.

O segundo caso é um documento inteiro virando tabela. No relatório de banco central em várias colunas, o título e o corpo do texto foram parar dentro de células:

|||||2025 年５月１日|
| --- | --- | --- | --- | --- |
||【基本的見解】|1|経済・物価情勢の展望（2025 年４月） ＜概要＞|日本銀行|

A rota de inferência produziu exatamente 1 título nesse documento. Um layout em várias colunas foi lido como uma única tabela com várias colunas.

Quais quebras mudam de método resolve e quais não

Se vale a pena tentar outro método de conversão depende da falha que apareceu.

O padrão é este: se a tabela aparece ou não muda conforme o método. Se a tabela que aparece está correta não muda, porque sem estrutura no PDF de origem todo método continua deduzindo.

O jeito confiável de descobrir qual falha atinge o seu arquivo é testar. O PDF para Markdown converte dentro do seu navegador, então dá para testar um arquivo que não pode sair da sua máquina.

Como corrigir uma tabela quebrada

Confira sempre o resultado contra o original

Quando um PDF contém tabelas, não use o Markdown convertido antes de compará-lo com a fonte. A falha 2 não dá nenhum sinal visual, então essa comparação é a única forma de detectá-la.

Uma ordem que funciona:

1. Conte linhas e colunas e confirme que batem com o original.
2. Verifique se os rótulos do cabeçalho aparecem na mesma ordem da fonte.
3. Compare a primeira e a última célula de cada linha com o original. O deslocamento aparece primeiro nas pontas.
4. Olhe uma a uma as regiões onde o original tinha células mescladas. Tabelas Markdown não conseguem expressar mesclagem, então essas regiões foram transformadas de alguma forma.

Refaça as tabelas numéricas em vez de remendá-las

Em tabelas onde um deslocamento de uma célula muda o significado — valores, totais, medições — refazer é mais rápido e mais seguro do que consertar. Copie a tabela do original, cole numa planilha, exporte como CSV e converta esse CSV em tabela Markdown. As relações entre células sobrevivem ao caminho.

Para a sintaxe em si — onde ficam os pipes, o que a linha separadora precisa ter, como funcionam os dois-pontos de alinhamento, como escapar um pipe dentro da célula — veja sintaxe de tabelas Markdown no GitHub. Vale lembrar que tabelas não fazem parte do CommonMark básico, e sim de uma extensão definida pelo GitHub Flavored Markdown (extensão de tabelas do GFMAbre em uma nova aba), então confirme que o destino onde você vai colar o resultado tem suporte a elas.

Como saber de antemão quais PDFs têm mais chance de sobreviver

Isto é uma lista de verificação para reduzir o risco, não uma garantia.

O que olhar antes de converter

• Dá para selecionar com o mouse o texto de dentro da tabela num leitor de PDF? Se não dá, não há camada de texto e não há o que converter.
• A tabela tem linhas de borda? Tabelas sem bordas oferecem menos pistas sobre onde as células terminam.
• A página tem uma coluna só? Layouts de duas e três colunas podem ser lidos como tabelas por conta própria.
• A tabela atravessa uma quebra de página? Tabelas que continuam em outra página costumam sair como tabelas separadas.
• Existem células mescladas? Markdown não tem equivalente, então essas regiões sempre são transformadas.
• Há diagramas ou ícones misturados dentro da tabela? O texto de uma figura pode ser puxado como célula.

Do que desconfiar depois

• Contagem de colunas que muda de uma linha para outra. É a inferência de limites oscilando entre linhas.
• Um número incomum de células vazias, ou linhas como ||||| que só contêm separadores.
• Uma contagem de títulos alta demais, sinal de que linhas de texto foram promovidas a títulos.
• Palavras que não são palavras: o caso DENTIFY acima é a cara de glifos partidos.
• Frases longas de texto corrido dentro de uma célula.

PDFs digitalizados não contêm texto, então não há o que converter

Um PDF feito digitalizando papel é uma imagem de cada página. Você lê os caracteres, mas o arquivo não os contém como texto. Nessa situação as tabelas não são o problema: não há nenhum texto extraível.

O que falta é transcrição (OCR), não conversão. A ferramenta de PDF do FormatArc não tem OCR, então ela informa que o arquivo não pode ser convertido em vez de devolver uma saída construída em cima de suposições. Saber que um arquivo não pode ser convertido é mais seguro do que receber conteúdo que pode estar errado.

Para verificar se o seu arquivo é digitalizado, tente arrastar o mouse sobre o texto num leitor. Se nada for selecionado, é uma imagem.

Perguntas frequentes

Outro conversor resolve a minha tabela?

Depende da falha. Se nenhuma tabela aparece, trocar para um método que infira estrutura pelo menos vai produzir tabelas. Se as células estão deslocadas, todo método continua deduzindo a partir de coordenadas enquanto o PDF de origem não trouxer estrutura, então não há garantia.

PDFs marcados evitam o problema?

Quando a marcação existe e está correta, dá para ler Table, TR, TH e TD diretamente em vez de deduzir. Mas a marcação é decidida por quem produziu o PDF, não por você, e até um arquivo marcado pode trazer uma estrutura que não corresponde ao que aparece na tela.

Posso converter um PDF digitalizado?

Com o FormatArc não. PDFs digitalizados não contêm texto e precisam de OCR, que esta ferramenta não oferece, então ela informa que o arquivo não é convertível em vez de tentar.

Existe um jeito de extrair só as tabelas?

Aqui não existe extração só de tabelas, mas copiar a tabela do original, passar por uma planilha como CSV e converter isso para Markdown preserva as relações entre células. Para tabelas numéricas esse é o caminho mais confiável.

Resumo

A tabela de um PDF quebra no Markdown porque a maioria dos PDFs não carrega a tabela visível como estrutura reutilizável, e o conversor precisa deduzir a grade a partir da posição de glifos e linhas. Nas nossas medições essa dedução falhou em duas direções: uma rota não produziu tabela nenhuma e a outra produziu tabelas bem formadas com as células atribuídas errado. A segunda é a que exige atenção, porque não parece quebrada — então sempre que um PDF contiver tabelas, compare a saída convertida com o original.

Para ver como o seu arquivo se comporta, passe ele pelo PDF para Markdown. O arquivo é processado no seu navegador e nunca é enviado para lugar nenhum.