Introdução à sintaxe markdown: guia prático e completo

Sintaxe markdown na prática: negrito, itálico, tachado, código com realce de linguagem, listas, links, tabelas e por que ela é a língua nativa dos LLMs.
markdown
sintaxe
documentação
programação
tutorial
Autor

Pedro Nakashima

Data de Publicação

12 de setembro de 2026

Data de Modificação

12 de setembro de 2026

Palavras-chave

sintaxe markdown, markdown, CommonMark, GitHub Flavored Markdown, tabelas markdown, blocos de código, arquivo .md, markdown para LLMs

Publicado em 12 de setembro de 2026, às 08:46, por Pedro Nakashima

Atualizado em 12 de setembro de 2026, às 09:50, por Pedro Nakashima

A sintaxe markdown é o conjunto mínimo de sinais de pontuação que transforma texto puro em documento formatado: dois asteriscos viram negrito, uma cerquilha vira título, três crases abrem um bloco de código. Este guia cobre, na ordem em que você vai precisar, a extensão do arquivo e como visualizá-lo renderizado, as três formas de ênfase, código em bloco e inline com identificação de linguagem, listas numeradas e não numeradas, links para fora e para dentro do próprio documento, tabelas e os detalhes que separam quem escreve markdown de quem apenas o usa. No fim, o argumento que mais importa hoje: markdown deixou de ser uma conveniência de programador e virou o formato em que humanos e modelos de linguagem conversam. Se você chegou aqui depois do guia de sintaxe Python, a lógica é a mesma: uma sintaxe pequena, aprendida de uma vez só, que rende todos os dias.

O que é markdown

Markdown é uma linguagem de marcação leve criada por John Gruber em 2004, com duas metas declaradas: o texto deve ser legível antes de ser renderizado, e o resultado renderizado deve ser HTML. É essa dupla natureza que explica seu sucesso — o arquivo .md é útil aberto no Bloco de Notas e útil publicado numa página web, sem conversão manual no meio.

A especificação original de Gruber ainda está no ar, na página do projeto Markdown no Daring Fireball, e vale a leitura pelo tom: é uma proposta editorial, não um padrão técnico. A formalização veio depois. Em 2016, o RFC 7763 registrou o tipo de mídia text/markdown na IETF, reconhecendo explicitamente que markdown é uma família de sintaxes, e não uma só. E o esforço de dar a essa família um núcleo testável produziu o CommonMark, hoje na versão 0.31.2, de janeiro de 2024, com centenas de casos de teste que qualquer implementação pode rodar.

Guarde essa distinção desde já, porque ela explica quase todo problema prático que você vai encontrar: markdown não é um padrão único. Há um núcleo comum (CommonMark) e há extensões que alguns renderizadores implementam e outros não — tabela e texto tachado, por exemplo, estão fora do núcleo.

O arquivo: extensão, como editar e como ver renderizado

A extensão

A extensão consagrada é .md. Você também vai encontrar .markdown, .mdown e .mkd, todas válidas e todas raras: use .md, que é o que o GitHub, o VS Code, o Obsidian e praticamente todo o ecossistema reconhecem sem configuração.

E vale saber o que a extensão não faz: ela não muda um único byte do conteúdo. Renomear um .txt para .md deixa o arquivo exatamente igual — o que muda é só como as ferramentas passam a tratá-lo, qual realçador o editor aplica e se o renderizador vai interpretar os asteriscos ou mostrá-los crus. Existem ainda dialetos que acrescentam ao markdown blocos de código de fato executáveis, muito usados em computação científica, e alguns adotam extensão própria; neles, a sintaxe de texto é a mesma que você vai aprender aqui.

Por baixo, um arquivo markdown é texto puro, e é isso que importa. Não há formato binário, não há cabeçalho proprietário, não há versão de programa. Grave sempre em UTF-8 sem BOM: o BOM é um caractere invisível que alguns editores do Windows inserem no começo do arquivo e que quebra o bloco de metadados de geradores de site como Hugo, Jekyll e MkDocs, porque o --- deixa de ser a primeira coisa do arquivo.

Como editar

Qualquer editor de texto serve — e essa é a primeira vantagem concreta do formato. Na prática, três caminhos cobrem quase todo mundo:

  • VS Code, que é o padrão de fato: realce de sintaxe embutido e pré-visualização lado a lado com Ctrl+Shift+V (ou Cmd+Shift+V no macOS). É a combinação mais produtiva para quem também escreve código.
  • Obsidian ou Typora, para quem escreve notas e textos longos: editam markdown em modo quase-WYSIWYG, mostrando a formatação aplicada enquanto você digita, e gravam arquivos .md comuns na sua própria pasta.
  • O próprio navegador, no editor web do GitHub ou do GitLab, que tem aba de preview ao lado da aba de edição. Não precisa instalar nada.

O que não serve é editor de texto rico — Word, Google Docs, WordPad. Eles gravam formatação binária, não os caracteres ** que markdown exige.

Como visualizar renderizado

Renderizar é converter o markdown em HTML (ou PDF, ou DOCX). Você tem quatro níveis de esforço:

  1. Automático, sem fazer nada: GitHub, GitLab, Bitbucket, Notion, Obsidian, Discord, Slack e Reddit renderizam markdown na hora, ao exibir o conteúdo. Um README.md num repositório aparece formatado porque a plataforma converte a cada visita.
  2. Pré-visualização no editor: o Ctrl+Shift+V do VS Code abre um painel que atualiza a cada tecla. É o laço de retorno mais curto e o que você vai usar em 90% do tempo.
  3. Conversão por linha de comando, com o Pandoc, que é o conversor universal de documentos: pandoc artigo.md -o artigo.html gera HTML, e trocar a extensão de saída para .pdf ou .docx gera PDF ou Word a partir do mesmo arquivo de origem.
  4. Publicação como site, com Hugo, Jekyll, MkDocs ou Eleventy, que pegam uma pasta de arquivos markdown e produzem um site inteiro com navegação, busca e feed RSS.

O ponto a internalizar: markdown não formata nada por si. Ele descreve a estrutura; o renderizador decide a aparência. É por isso que o mesmo **negrito** sai em fontes diferentes no GitHub e no seu blog — e é também por isso que um recurso pode funcionar num lugar e falhar no outro.

Ênfase: negrito, itálico e tachado

O que você quer Como escreve Como sai
Itálico *texto* ou _texto_ texto
Negrito **texto** ou __texto__ texto
Negrito e itálico ***texto*** texto
Tachado ~~texto~~ texto 
Escrever bem exige *clareza*, **precisão** e ***as duas coisas juntas***.
O prazo era ~~sexta-feira~~ segunda-feira.

Três detalhes que evitam frustração, e nenhum deles é óbvio:

Prefira o asterisco ao sublinhado. Os dois funcionam, mas eles não se comportam igual dentro de uma palavra. Pela regra do CommonMark, ** aplica ênfase no meio de uma palavra e __ não aplica — de modo que pandas**3**.0 funciona e pandas__3__.0 sai literal. Como nomes de variáveis e funções em código costumam ter sublinhado (meu_nome_de_variavel), usar * e ** para ênfase evita colisão acidental.

O tachado é extensão, não núcleo. O ~~texto~~ vem do GitHub Flavored Markdown, o GFM, especificado na versão 0.29-gfm de abril de 2019 como um superconjunto estrito do CommonMark. Isso significa que ele funciona no GitHub, no GitLab, no Pandoc e na maioria dos renderizadores modernos, mas pode sair literal num renderizador que implemente só o CommonMark puro. A especificação do GFM aceita também um til só (~texto~); use dois, que é a forma portável.

Não existe sublinhado de texto em markdown. Sublinhar é convenção de link na web, e o formato deliberadamente não oferece sintaxe para isso. Se você precisar mesmo, a saída é HTML inline: <u>texto</u>, que a maioria dos renderizadores aceita.

Código: em bloco e inline, com identificação de linguagem

Esta é a parte em que markdown se descola de qualquer editor de texto comum, e a razão pela qual o formato nasceu num ambiente de programadores.

Código inline

Envolva o trecho em crases simples. Serve para nomes de arquivo, comandos, variáveis, funções e qualquer coisa que deva sair em fonte monoespaçada, sem interpretar a marcação de dentro:

Rode `pip install pandas` e depois chame `df.head()` para ver as cinco primeiras linhas.

Se o próprio código contém uma crase, use duas crases na volta e um espaço de folga: uma crase por dentro. É o mesmo princípio de escapar delimitadores em qualquer linguagem.

Bloco de código com linguagem

Abra e feche com três crases. A palavra imediatamente após as três crases de abertura é o que o CommonMark chama de info string, e é ali que você declara a linguagem:

```python
import pandas as pd

df = pd.read_csv("extratos.csv")
print(df.groupby("banco")["valor"].sum())
```

O resultado:

import pandas as pd

df = pd.read_csv("extratos.csv")
print(df.groupby("banco")["valor"].sum())

Os identificadores mais usados são python, r, sql, bash, json, yaml, html, css, javascript, markdown e diff. Aliases funcionam (py, js, sh), mas escreva o nome completo: é o que todo realçador reconhece.

E aqui vai a nuance que quase todo tutorial omite: markdown não colore nada. A info string é apenas um rótulo que o markdown repassa ao HTML como uma classe (class="language-python"). Quem pinta as palavras-chave é uma biblioteca de realce do lado do renderizador — Highlight.js e Prism no navegador, Pygments no Pandoc e no Sphinx, Chroma no Hugo. Consequência prática: se o seu bloco sai sem cor, o problema não está no markdown, está no tema ou no realçador do site. E se você escreve pythonn por engano, nada quebra — o bloco só sai sem realce.

Vale conhecer a forma antiga, porque você vai encontrá-la em documentos de dez anos atrás: um bloco também se cria indentando quatro espaços. Ela ainda funciona no CommonMark, mas não permite declarar linguagem e é fácil de acionar por acidente ao colar texto indentado. Use sempre as crases.

Para mostrar um bloco de código dentro de outro bloco — como fiz acima para exibir a sintaxe crua — use quatro crases na cerca externa. A regra do CommonMark é simples: a cerca de fechamento precisa ter pelo menos tantas crases quanto a de abertura, então uma cerca de quatro engole uma de três inteira.

Listas numeradas e não numeradas

Para lista não numerada, comece a linha com -, * ou +, seguido de um espaço. Escolha um marcador e mantenha-o no documento inteiro: trocar de marcador no meio faz alguns renderizadores iniciarem uma lista nova em vez de continuar a mesma.

Para lista numerada, use número, ponto e espaço:

- Primeiro item
- Segundo item
  - Subitem, indentado com dois espaços
  - Outro subitem
- Terceiro item

1. Instale o Pandoc
2. Escreva o arquivo .md
3. Converta para HTML

Duas coisas que economizam tempo real:

Os números não precisam estar certos. O CommonMark usa o número do primeiro item para saber onde a lista começa e renumera o resto sozinho, em sequência. Escrever 1. em todas as linhas produz uma lista 1, 2, 3 perfeita — e é o que você deve fazer em listas longas, porque assim inserir um item no meio não obriga a renumerar nada. Já começar com 5. produz uma lista que começa em 5, o que é útil ao continuar uma sequência interrompida.

A indentação do aninhamento segue o conteúdo do item pai, não uma contagem fixa. Em lista não numerada, o marcador - mais o espaço ocupam duas colunas, então dois espaços bastam. Em lista numerada, 1. mais o espaço ocupam três, e a regra pede três espaços. Quatro espaços funcionam nos dois casos e é o que eu recomendo por simplicidade: indente sublistas com quatro espaços e pare de pensar nisso. E sempre deixe uma linha em branco antes da lista — sem ela, muitos renderizadores tratam o primeiro item como continuação do parágrafo anterior. É o erro mais comum de todos.

O GFM acrescenta a lista de tarefas, que o GitHub converte em caixas clicáveis dentro de issues e pull requests:

- [x] Escrever o rascunho
- [ ] Revisar as fontes
- [ ] Publicar

Tabelas

Tabela é uma extensão do GFM, não parte do CommonMark. Funciona no GitHub, no GitLab, no Pandoc e nos geradores de site modernos, e é o recurso que mais falha em renderizadores minimalistas — quando sua tabela aparece como uma sopa de barras verticais, é isso que está acontecendo.

A sintaxe são barras verticais separando células e uma linha de hífens separando o cabeçalho do corpo:

| Sintaxe | Núcleo CommonMark | Extensão GFM |
|---|---|---|
| Negrito e itálico | sim | — |
| Bloco de código com linguagem | sim | — |
| Tachado | não | sim |
| Tabela | não | sim |
| Lista de tarefas | não | sim |
Sintaxe Núcleo CommonMark Extensão GFM
Negrito e itálico sim —
Bloco de código com linguagem sim —
Tachado não sim
Tabela não sim
Lista de tarefas não sim

O alinhamento de cada coluna é definido por dois-pontos na linha separadora: :--- alinha à esquerda, ---: à direita e :---: centraliza. Alinhar números à direita é o único uso desse recurso que muda de fato a legibilidade:

| Item        | Quantidade |
|:------------|-----------:|
| Parcelas    |         60 |
| Amortizadas |          7 |

Quatro limites que você vai encontrar, e para os quais é melhor estar preparado:

  • As barras não precisam estar alinhadas no arquivo cru. | a | b | e |a|b| produzem a mesma tabela. Alinhe se ajudar a leitura, mas não perca tempo com isso — e as barras das pontas são opcionais.
  • A linha de cabeçalho é obrigatória. Não existe tabela sem cabeçalho em GFM; se você não quiser um, deixe as células do cabeçalho vazias.
  • Uma célula não tem várias linhas. Não há como colocar parágrafo, lista ou bloco de código dentro de uma célula. Para conteúdo complexo, o caminho é HTML puro ou uma tabela gerada por código.
  • Barra vertical dentro de uma célula precisa ser escapada com \|, senão ela quebra a coluna. Vale para o operador ou de expressões regulares e para o pipe do shell.

A regra prática que uso: se a tabela não cabe confortavelmente na largura da tela em markdown cru, ela provavelmente não deveria ser uma tabela markdown. Dados de verdade vivem melhor num .csv ao lado, carregado por código.

Outros elementos que valem saber

Títulos vão de # (nível 1) a ###### (nível 6), com um espaço após a cerquilha. A convenção é um único # por documento — e em Hugo, Jekyll e MkDocs você nem escreve esse: o título vem do bloco de metadados, e o corpo começa em ##. Nunca pule níveis: um ### sob um # confunde leitor de tela e buscador.

Citação se faz com > no começo da linha, e ela acumula: >> aninha uma citação dentro da outra. Dentro de uma citação valem todos os outros elementos, inclusive listas e código.

Linha horizontal são três ou mais hífens (---), asteriscos (***) ou sublinhados (___) numa linha isolada. Atenção a uma pegadinha clássica: --- imediatamente abaixo de uma linha de texto, sem linha em branco no meio, não é linha horizontal — é a sintaxe antiga de título nível 2, e seu parágrafo vira um cabeçalho gigante. Sempre deixe uma linha em branco antes.

Imagens são links com uma exclamação na frente: ![texto alternativo](caminho/imagem.png). O texto alternativo não é opcional na prática — é o que o leitor de tela lê e o que aparece se a imagem falhar. A única exceção legítima é a imagem puramente decorativa, que vai com alt vazio justamente para o leitor de tela pulá-la.

Quebra de linha dentro do mesmo parágrafo é a fonte de confusão número um. Apertar Enter uma vez não quebra a linha no resultado renderizado: markdown junta linhas consecutivas num único parágrafo. Para forçar a quebra, termine a linha com dois espaços ou com uma barra invertida. Para separar parágrafos, deixe uma linha em branco. Corolário importante: não quebre parágrafos por coluna no arquivo — deixe cada parágrafo numa linha física longa e deixe o editor e o navegador cuidarem da exibição. Isso também deixa o histórico do Git legível, porque uma frase alterada aparece como uma linha alterada, não como um bloco inteiro reescrito.

Escape com barra invertida, quando você quer o caractere literal: \*asterisco\* sai com os asteriscos visíveis.

Bloco de metadados no topo do arquivo, entre duas linhas de ---, em YAML. Não é markdown — é convenção, e uma tão universal que virou infraestrutura: Hugo, Jekyll, MkDocs, Docusaurus, Obsidian e Pelican todos leem título, data, autor e categorias dali. É de lá que um gerador de site tira o que mostrar na listagem, no cabeçalho da página e no feed RSS.

HTML inline funciona na maioria dos renderizadores: se markdown não tem a sintaxe de que você precisa, escreva a tag. Duas ressalvas — o GFM filtra deliberadamente algumas tags perigosas (como <script>) em conteúdo de usuário, e HTML no meio do texto se perde quando você converte para PDF ou DOCX. Use com parcimônia.

Notas de rodapé ([^1]), fórmulas matemáticas em LaTeX entre cifrões ($e^{i\pi} = -1$) e listas de definição são extensões, disponíveis no Pandoc e em processadores mais completos, ausentes no GFM. São ótimas para texto técnico longo — só não conte com elas fora dessas ferramentas.

Por que markdown é útil

O argumento mais forte não é a velocidade de digitação. É o texto puro.

Um arquivo .md é uma sequência de caracteres, e isso tem três consequências que nenhum formato binário consegue oferecer. Ele é versionável de verdade: o Git mostra exatamente qual frase mudou entre duas versões, o que é impossível num .docx, onde o diff é um borrão binário. Ele é legível por qualquer programa — grep, script Python, editor de 1995, terminal via SSH. E ele não expira: um markdown escrito em 2004 abre hoje sem nenhuma camada de compatibilidade, enquanto arquivos de processadores de texto da mesma época já exigem conversor.

A segunda razão é a separação entre conteúdo e apresentação. Você escreve a estrutura — isto é um título, isto é uma lista, isto é código — e a aparência é decidida na hora de renderizar. Uma fonte, várias saídas: o mesmo .md vira página web, PDF, apresentação de slides, e-book e documento Word via Pandoc, sem retrabalho de formatação. Para quem publica em mais de um lugar, é a diferença entre escrever uma vez e escrever três.

A terceira é o custo cognitivo perto de zero. A sintaxe inteira que importa cabe em meia página, e ela foi desenhada para parecer o que significa: asteriscos ao redor de uma palavra já indicavam ênfase em e-mail muito antes de existir markdown. Você aprende em vinte minutos e não volta a consultar.

A quarta é ubiquidade, e ela se tornou o argumento decisivo. Markdown é a língua do GitHub, que hospeda mais de 180 milhões de desenvolvedores, e também do GitLab, do Slack, do Discord, do Reddit, do Notion, do Obsidian, do Jupyter, do Stack Overflow e da documentação técnica de quase todo projeto sério de software. Aprender a sintaxe uma vez rende em uma dezena de lugares por dia.

A objeção honesta existe, e é a fragmentação: como não há um markdown único, um documento que usa extensões pode sair diferente — ou sair errado — em outro renderizador. É um problema real, e é por isso que este artigo marca o tempo todo o que é núcleo e o que é extensão. Mas ele encolheu muito. Na prática, escrever para o núcleo do CommonMark mais as cinco extensões do GFM — tabela, tachado, lista de tarefas, autolink estendido e filtro de HTML — cobre praticamente todo destino em que seu texto vai cair. E quando precisar de mais (nota de rodapé, fórmula, referência bibliográfica), a escolha consciente é subir para o Pandoc ou para um processador equivalente, sabendo que ali o alvo é outro.

Aplicações: documentação, publicação e LLMs

As aplicações tradicionais já justificam o aprendizado. Documentação de software vive em markdown: o README.md é a primeira página de qualquer repositório, e ferramentas como MkDocs e Docusaurus constroem sites de documentação inteiros a partir de pastas de .md. Publicação é o terreno dos geradores de site estático, que transformam uma pasta de arquivos markdown versionada num repositório em um site com navegação, listagem e feed RSS, sem banco de dados e sem painel de administração. Notas pessoais e gestão de conhecimento ganharam vida nova com Obsidian e Logseq, que tornam links entre arquivos a estrutura primária — e, porque a base é markdown puro, suas anotações nunca ficam presas ao aplicativo. Computação científica usa markdown ao lado do código, em notebooks Jupyter, com o texto explicativo e o resultado do cálculo no mesmo arquivo — é o que o guia de introdução ao pandas mostra em funcionamento.

A aplicação nova, e a que mais mudou nos últimos dois anos, é markdown como formato de interface com modelos de linguagem.

Três razões explicam por que markdown ocupou esse lugar. A primeira é de treinamento: os modelos foram treinados sobre volumes enormes de GitHub, documentação técnica e fóruns — todos em markdown. É o formato que eles viram mais, e é por isso que a resposta padrão de praticamente todo assistente já sai com ##, listas e blocos de código, mesmo quando ninguém pediu. A segunda é economia de tokens: markdown carrega muito menos sobrecarga sintática que HTML, XML ou JSON para expressar a mesma estrutura. Onde HTML gasta <strong>texto</strong> (dezessete caracteres só de andaime), markdown gasta **texto** (quatro). Em um contexto de centenas de milhares de tokens, esse andaime é espaço que deixa de ser conteúdo — e, em uma API paga por token, é dinheiro gasto em pontuação. A terceira é que a estrutura sobrevive à conversão em texto plano: um título markdown continua visivelmente um título depois de tokenizado, ao contrário de formatação binária, que simplesmente desaparece.

Isso rende quatro hábitos práticos que valem a pena adotar:

  1. Escreva seus prompts em markdown. Use ## para separar contexto, tarefa e restrições, e listas para enumerar requisitos. Um prompt estruturado é mais fácil de o modelo seguir e muito mais fácil de você revisar e reaproveitar depois.
  2. Peça a saída em markdown quando ela for alimentar outro sistema. “Responda em markdown, com uma tabela de três colunas” produz algo que você cola direto no repositório ou no site.
  3. Converta antes de indexar. Em sistemas de recuperação (RAG), converter PDF e HTML para markdown antes de fatiar os documentos preserva a hierarquia de títulos, e é essa hierarquia que permite cortar o texto em pedaços que fazem sentido sozinhos.
  4. Publique uma versão legível por máquina. A convenção llms.txt — um arquivo markdown na raiz do site, com índice e descrições — nasceu exatamente para dar a agentes um ponto de entrada estruturado no seu conteúdo.

E vale a ressalva, porque a euforia em torno disso ultrapassa a evidência: markdown não é mágico. Ele é bom para texto estruturado; é ruim para dado tabular largo, onde CSV ou JSON são mais confiáveis, e a pesquisa sobre como a serialização afeta o desempenho de modelos em dados estruturados está longe de fechada. Use markdown para prosa, hierarquia e código; use formato de dados para dados.

O que vem por aí: o Google OKF

Há um desdobramento recente que merece artigo próprio, e vou escrever um em breve aqui no blog.

Em junho de 2026, o Google Cloud lançou o Open Knowledge Format (OKF), uma especificação aberta e neutra de fornecedor para empacotar conhecimento e entregá-lo a agentes de IA. O detalhe que interessa a este artigo é o que o OKF é, por baixo: um diretório de arquivos markdown com bloco de metadados em YAML. Nada de banco de dados novo, nada de formato proprietário, nada de ferramenta obrigatória — a especificação já está na versão 0.2, publicada no GitHub, e exige essencialmente um único campo obrigatório no cabeçalho de cada arquivo.

Pense no que isso significa. A mesma sintaxe que você acabou de aprender para escrever um README foi escolhida, vinte e dois anos depois de inventada, como camada de transporte do conhecimento organizacional para agentes de IA. Como isso funciona na prática, o que a especificação exige de fato, e por que eu já uso um formato derivado dela na minha própria produção de conteúdo — é isso que vou destrinchar no próximo artigo. Vale acompanhar o blog.

Perguntas frequentes

Markdown e HTML são a mesma coisa?

Não. Markdown é uma sintaxe de atalho que gera HTML: **texto** se converte em <strong>texto</strong> na hora de renderizar. Markdown é mais rápido de escrever e legível sem renderizar, mas cobre um conjunto pequeno de elementos; HTML cobre tudo e é muito mais verboso. A maioria dos renderizadores aceita HTML inline dentro do markdown, o que dá uma saída de emergência quando a sintaxe curta não basta.

Qual extensão devo usar, .md ou .markdown?

.md, sem hesitar. As duas são válidas, mas .md é o que toda ferramenta reconhece por padrão. A única razão para usar outra extensão é quando a ferramenta que vai processar o arquivo exige a dela — e, nesse caso, a documentação dela diz qual é.

Por que minha tabela (ou meu texto tachado) não aparece?

Porque os dois são extensões do GFM, não parte do núcleo do CommonMark, e o renderizador que você está usando provavelmente implementa só o núcleo. A verificação é rápida: cole o mesmo trecho num arquivo do GitHub e veja se renderiza. Se renderizar lá e não no seu destino, o problema é a configuração do renderizador — no Pandoc, por exemplo, é preciso pedir o dialeto certo (-f gfm) ou habilitar a extensão de tabelas.

Markdown dá conta de um documento acadêmico, com citações e fórmulas?

Dá, mas não em markdown puro — você precisa de um processador mais completo, como o Pandoc. Ele acrescenta notas de rodapé, fórmulas LaTeX, legendas, referências cruzadas numeradas e bibliografia a partir de um arquivo .bib, gerando PDF via LaTeX. É um fluxo consolidado em estatística e economia, e a vantagem sobre escrever LaTeX direto é que o texto continua legível e o mesmo fonte também gera HTML.

Preciso instalar algo para começar?

Nada. Abra o Bloco de Notas, escreva # Meu título e uma linha de texto, salve como teste.md e arraste o arquivo para uma janela do VS Code — ou crie um repositório no GitHub e cole ali. O fato de a barreira de entrada ser essencialmente zero é parte do motivo pelo qual o formato venceu.

Conclusão

  • A extensão é .md, o conteúdo é texto puro em UTF-8 sem BOM, qualquer editor serve para escrever e o Ctrl+Shift+V do VS Code é a forma mais rápida de ver o resultado renderizado.
  • Ênfase: *itálico*, **negrito**, ~~tachado~~. Prefira asterisco a sublinhado, porque ** funciona no meio de palavras e __ não.
  • Código: crase simples para inline, três crases para bloco, com a linguagem declarada logo após as crases de abertura. O realce de cores é trabalho do renderizador, não do markdown.
  • Listas: - para não numeradas, 1. para numeradas — e escrever 1. em todos os itens funciona, porque o renderizador renumera. Deixe sempre uma linha em branco antes da lista.
  • Links: [texto](url) para fora, [texto](#identificador) para dentro, e {#identificador} ao lado do título quando você quer uma âncora estável. A âncora sempre descreve o destino, nunca “clique aqui”.
  • Tabelas usam barras verticais e dois-pontos para alinhamento, mas são extensão do GFM — como o texto tachado e a lista de tarefas. É aí que mora quase todo problema de compatibilidade.
  • O núcleo é o CommonMark 0.31.2; o dialeto de fato é o CommonMark mais as cinco extensões do GFM. Escrever para esse alvo cobre praticamente todo destino.
  • A aplicação que mais cresce é a interface com LLMs: é o formato que os modelos emitem por padrão, o mais econômico em tokens para expressar estrutura, e o que preserva hierarquia ao ser convertido em texto. Estruture seus prompts com ## e listas.
  • Markdown para texto, formato de dados para dados. Tabela markdown larga é sinal de que o dado deveria estar num .csv.

Tópicos: #Markdown #Documentacao #Programacao #CommonMark #LLMs