Gerador de tabelas Markdown
Construa tabelas Markdown visualmente com um editor tipo planilha.
Clique em L / C / R abaixo de cada cabeçalho de coluna para definir o alinhamento (esquerda, centro, direita).
Saída Markdown
Sobre as tabelas Markdown
As tabelas Markdown usam barras verticais (|) e traços (-) para criar dados tabulares estruturados em texto simples. São suportadas pelo GitHub, GitLab, Reddit e pela maioria dos renderizadores Markdown. A linha de alinhamento usa dois-pontos para indicar alinhamento à esquerda, ao centro ou à direita em cada coluna.
Escrever tabelas Markdown à mão pode ser tedioso e sujeito a erros. Este editor visual permite inserir dados em uma grade tipo planilha e gera Markdown corretamente formatado em tempo real. Todo o processamento é feito no seu navegador.
A sintaxe pipe-table, mecanicamente
Uma tabela GFM consiste em três partes: uma linha de cabeçalho com células separadas por pipes (|), uma linha delimitadora logo abaixo com traços (---) para cada coluna, e zero ou mais linhas de dados com a mesma estrutura separada por pipes. Pipes no início e no fim de cada linha são opcionais mas convencionalmente incluídos para legibilidade. O alinhamento de coluna é especificado por dois-pontos na linha delimitadora: :--- para alinhar à esquerda (o padrão), :---: para centralizar, ---: para alinhar à direita. A tabela mínima viável fica assim na fonte: | Header | Header | na linha 1, | --- | --- | na linha 2, | Cell | Cell | na linha 3 em diante. O conteúdo das células pode incluir qualquer formatação Markdown inline (negrito, itálico, links, code spans, imagens) mas não pode incluir elementos de nível bloco (listas, blocos de código, citações). Quebras de linha dentro de uma célula precisam ser codificadas como tags <br> em vez de quebras de linha literais, pois quebras literais quebrariam a estrutura da tabela. Caracteres pipe dentro do conteúdo da célula devem ser escapados como \|, caso contrário o parser os trata como separadores de coluna e a contagem de colunas da linha sai errada. A maioria dos parsers tolera larguras de coluna desalinhadas; a fonte | a | b | e | aaa | b | renderizam idênticas, mesmo que a segunda pareça mais «correta» na fonte. Esta ferramenta sempre emite fonte com largura alinhada por legibilidade, mas renderiza igual à fonte compacta.
Onde tabelas renderizam e onde não
Renderiza corretamente: GitHub (issues, pull requests, READMEs, páginas de wiki, discussões, code reviews, comentários em todo lugar), GitLab (mesmas superfícies), Bitbucket, Stack Overflow, Reddit (quando GFM está habilitado no subreddit, o que é o caso da maioria), Discord (apenas em contexto de bloco de código, tabelas GFM completas não renderizam em mensagens de chat mas markdown-it as processa na superfície de docs), Notion (com sua própria importação de tabela), Obsidian, Logseq, Bear, a maioria dos geradores de site estático (Hugo, Jekyll, Eleventy, Astro com o plugin remark-gfm, Next.js MDX), pré-visualização do VS Code, GitHub Pages, Read the Docs (dependendo da configuração). Não renderiza corretamente: CommonMark estrito (Pandoc com o reader commonmark e sem extensões, parser C Discount sem o flag pipe-tables), Slack (renderiza um subconjunto de Markdown mas não tabelas), a maioria dos clientes de email (o HTML renderizado em email é estruturalmente correto mas com estilos inline, não Markdown), instalações de WordPress mais antigas sem plugin de Markdown. A regra geral: se seu destino é uma plataforma orientada a desenvolvedor (família GitHub, documentação técnica), as tabelas GFM funcionam. Se seu destino é uma plataforma de audiência geral (Slack, email, Twitter), presuma que as tabelas não renderizarão e ou pré-renderize como imagem ou reescreva como lista.
Sintaxes alternativas de tabelas Markdown
O formato pipe-table domina por causa do alcance do GitHub, mas não é a única sintaxe de tabelas Markdown. As tabelas simples do Pandoc usam separadores de linha-em-branco-e-traços e alinham colunas por posição visual em vez de pipes, muito mais legíveis para tabelas estreitas mas mais difíceis de escrever à mão. As tabelas multi-linha do Pandoc suportam células que abrangem múltiplas linhas, importante para conteúdo descritivo longo que não cabe em uma linha. As tabelas grid do Pandoc usam bordas ASCII (+---+---+) que parecem dolorosas de manter à mão mas são fáceis de emitir por ferramentas. reStructuredText (Sphinx) usa tabelas grid exclusivamente, a documentação de qualquer projeto Python é escrita assim. AsciiDoc usa uma sintaxe pipe-prefixo diferente (|===) otimizada para escrita de livros técnicos. HTML em Markdown está sempre disponível como saída de emergência: qualquer processador Markdown deixa passar HTML cru, então quando pipe tables não bastam você pode jogar uma <table> real com spanning completo de linha/coluna, marcação semântica e estilo CSS. A sintaxe pipe-table que esta ferramenta gera é estilo GFM, a escolha mais compatível para o ecossistema de desenvolvimento moderno.
Usos comuns
- Arquivos README do GitHub. Tabelas comparativas («nossa biblioteca vs. alternativas»), matrizes de funcionalidades, listas de versões suportadas, listas de contribuidores, cartões de referência de comandos. Provavelmente o uso de produção individual mais comum das tabelas GFM.
- Documentação e wikis. Tabelas de referência de API (nome de parâmetro / tipo / descrição / padrão), tabelas de opções de configuração, referências de código de erro, matrizes de tradução de idiomas. Read the Docs, MkDocs, Docusaurus, GitBook todos suportam tabelas GFM.
- Posts comparativos de blog. Artigos «Framework X vs Framework Y», comparações de specs de hardware, decomposições de níveis de preço. O formato pipe-table é muito mais legível que parágrafos ad hoc e renderiza limpo no Medium, dev.to, Substack e blogs pessoais.
- Páginas de preços. Tabelas de níveis SaaS (Free / Pro / Enterprise através de linhas de funcionalidades) funcionam bem em formato pipe-table para mockups rápidos de versão rascunho antes que designers comerciais façam a versão HTML polida.
- Templates de issues do GitHub. Templates de relatório de bug frequentemente incluem passos de reprodução em forma de tabela (Passo / Esperado / Real / Captura). Tabelas de status de quadro de projeto para acompanhar progresso de sprint.
- Notas de reunião e planos de projeto. Tabelas de itens de ação (Dono / Ação / Data de vencimento / Status) em documentos de notas compartilhadas. Registros de decisões. Registros de riscos.
- Importação CSV. Muitos geradores de tabela oferecem importação CSV-para-Markdown, cole um CSV, obtenha uma tabela Markdown. O inverso (Markdown para CSV) também é comum ao extrair dados estruturados de documentação de volta para formato de planilha.
O problema da largura e outras restrições
Pipe tables têm várias limitações inerentes que vale a pena conhecer. A largura de coluna é restringida pelo conteúdo de célula mais longo, uma URL longa ou um parágrafo descritivo em uma célula força toda a coluna a se alargar, o que pode produzir tabelas inadministráveis que não cabem em larguras de página de documentação padrão. A solução é ou truncar o conteúdo longo (linkando em outro lugar para detalhe) ou usar HTML inline se precisar de células que se enrolem. Sem spanning de linha ou coluna, cada célula ocupa exatamente uma linha e uma coluna. Tabelas complexas com células fundidas precisam de HTML <table> real com atributos rowspan / colspan. Sem tabelas aninhadas, você não pode colocar uma tabela dentro da célula de outra tabela em Markdown. Sem conteúdo de nível bloco em células, sem listas, sem blocos de código, sem citações dentro de uma célula. Conteúdo inline (negrito, itálico, code spans, links, imagens) está ok mas qualquer coisa multi-linha precisa de tags <br>. A linha de cabeçalho é obrigatória em GFM, não há sintaxe de tabela sem cabeçalho. Se quiser uma tabela sem cabeçalho visível, deixe as células de cabeçalho vazias mas a linha ainda tem que estar presente. Alinhamento aplica por coluna a toda a coluna, você não pode ter alinhamento diferente para células diferentes na mesma coluna. Para layouts de tabela sofisticados que excedam essas restrições, a ferramenta correta é HTML na sua fonte Markdown, não Markdown em si.
Conversão CSV ↔ Markdown
A maioria dos dados tabulares do mundo real vive em arquivos CSV (exports de planilha, respostas de API, saída de análise de logs), converter de e para Markdown é um workflow comum. CSV → Markdown: parseia o CSV (lidando com campos entre aspas com vírgulas embutidas, aspas escapadas, quebras de linha dentro de campos), depois formata cada linha como | valor | valor | com as linhas de cabeçalho e delimitadora apropriadas. A maioria dos geradores de tabela incluindo este oferece importação CSV; para conversões pontuais você pode também usar a ferramenta de linha de comando csvlook do csvkit que produz uma saída em formato pipe similar. Markdown → CSV: re-parseia a tabela GFM em linhas e colunas, depois emite CSV com quoting apropriado. Útil ao extrair dados estruturados de documentação de volta para forma de planilha para análise. A direção Markdown-para-CSV é oferecida por ferramentas como pandoc (com a combinação correta de reader/writer), tableconvert.com e várias utilidades de linha de comando. A ida e volta é com perda em uma direção, a formatação (negrito, links, imagens) sobrevive ao passo CSV intacta só se você escrever o conteúdo da célula CSV como texto Markdown cru e tratar o resultado como Markdown de novo.
Privacidade: por que só-navegador importa mesmo aqui
Tabelas não parecem dados sensíveis, mas o conteúdo das tabelas frequentemente é. Planos de projeto contêm decisões de pessoal e funcionalidades não anunciadas. Tabelas de preços contêm informação comercial. Tabelas comparativas em posts de blog não publicados revelam posicionamento editorial. Itens de ação de notas de reunião contêm informação de atribuição e responsabilidade. Geradores de tabela do lado servidor enviam seus dados a um terceiro onde ficam em logs. Esta ferramenta roda inteiramente no seu navegador via JavaScript, verifique na aba Network do DevTools ao editar células, ou coloque a página offline (modo avião) após carregar e o editor continua funcionando. Segura para rascunhos de documentação não publicados, planejamento de projeto interno, tabelas comparativas para posts de blog ainda não publicados, ou qualquer conteúdo de tabela que você não queira ver copiado no disco rígido de um desconhecido.
Perguntas frequentes
Qual sintaxe de tabela Markdown é gerada ?
Ele gera a sintaxe padrão GFM (GitHub Flavored Markdown) com barras verticais, uma linha de separação de traços e dois-pontos opcionais para o alinhamento. Essa sintaxe funciona no GitHub, GitLab, Reddit, Jekyll, Hugo e na maioria dos processadores Markdown.
Como definir o alinhamento das colunas ?
Clique nos botões L (esquerda), C (centro) ou R (direita) abaixo de cada cabeçalho de coluna. O alinhamento à esquerda usa :---, o centro :---: e a direita ---: na linha de separação.
Posso importar de CSV ou colar de uma planilha?
Importação CSV está no roadmap. Por enquanto, colar-do-Excel/Google Sheets frequentemente funciona porque a maioria dos apps de planilha coloca dados separados por tabulação no clipboard, que você pode colar em células individuais. Para importação CSV em massa sem colagem manual, ferramentas de linha de comando como csvlook do csvkit produzem saída tabela-GFM similar, ou pandoc pode converter CSV para Markdown diretamente com pandoc --from csv --to gfm input.csv.
E sobre células fundidas, tabelas aninhadas ou conteúdo bloco em células?
Pipe tables GFM não suportam essas. Cada célula ocupa exatamente uma linha e uma coluna; sem rowspan ou colspan. Sem tabelas aninhadas. Sem conteúdo de nível bloco (listas, blocos de código, citações) dentro de uma célula, apenas conteúdo inline (negrito, itálico, code spans, links, imagens, quebras de linha via <br>). Para layouts de tabela sofisticados que excedam essas restrições, incorpore HTML <table> cru diretamente na sua fonte Markdown, todo processador Markdown deixa passar HTML sem mudanças. O compromisso é que a fonte fica muito mais difícil de ler e editar à mão.
Há limite de linhas ou colunas ?
Você pode ter até 20 colunas e 100 linhas. Para a maioria das documentações e arquivos README, é mais do que suficiente. A tabela é atualizada em tempo real conforme você digita.
O conteúdo das minhas tabelas é enviado a algum lugar?
Não. A geração roda inteiramente no seu navegador via JavaScript. As células que você edita e a saída Markdown nunca cruzam a rede, verifique na aba Network do DevTools ao digitar, ou coloque a página offline (modo avião) após carregar e o editor continua funcionando. Segura para rascunhos de documentação não publicados, planos de projeto internos, tabelas comparativas de preços ainda não publicadas, ou qualquer conteúdo tabular que você não queira ver copiado no disco rígido de um desconhecido.