Cole dois documentos Markdown e veja o que mudou linha a linha. Funciona em READMEs, notas de versão, MDX e documentos com frontmatter. O diff roda no seu navegador.
Uma ferramenta gratuita, executada no navegador, para comparar dois documentos Markdown no nível do texto-fonte. Cole um README.md antigo à esquerda, o atualizado à direita, e cada título, item de lista, link, bloco de código e célula de tabela alterado é destacado. Nada sai da sua máquina.
O diff é caractere por caractere. Markdown é texto puro, então essa é a primitiva certa: você vê a alteração literal na origem do documento, não um chute sobre como um renderizador o interpretaria.
Se você já usa nosso diff de texto para prosa em geral, a página de Markdown é o mesmo motor com texto voltado para os casos que aparecem quando se escreve documentação de verdade. Para comparar os blocos de frontmatter em YAML no topo de arquivos Jekyll, Hugo ou MkDocs, a página de YAML lida melhor com a estrutura sensível à indentação. Dados estruturados estritos com buscas por chave/valor pertencem ao diff de JSON.
O diff é em nível de caractere. Após o diff bruto, uma passagem de limpeza semântica desloca os destaques para que caiam em palavras inteiras, itens de lista e alvos de link, em vez de cortar um `code span` no meio ou separar o ## inicial de um título. Inserções aparecem em verde à direita, exclusões em vermelho à esquerda.
É um diff de texto-fonte, não de saída renderizada. Essa é a primitiva certa para trabalho com Markdown e pesa mais do que parece. Dois documentos que renderizam para o mesmo HTML podem ter origens muito diferentes: **negrito** contra __negrito__, marcadores com * contra -, indentação de quatro espaços contra tabulação em uma lista aninhada. Um renderizador achata tudo isso na mesma saída e o sinal se perde. Quando você quer saber se um colaborador realmente só corrigiu um typo, é o diff de fonte que responde.
Markdown também é uma família de dialetos. A especificação original de John Gruber (veja daringfireball.net) era propositalmente solta, e com o tempo CommonMark, GitHub Flavored Markdown, Pandoc e MultiMarkdown puxaram cada um para um lado. Tabelas existem em GFM e Pandoc, mas não em CommonMark. Tachado com ~~ e listas de tarefas com - [ ] são extensões GFM. A ferramenta de diff não se importa com o dialeto; mostra o texto bruto. O sabor importa quando você começa a perguntar se um parágrafo ainda renderiza certo no novo tema dos docs, e isso é assunto do renderizador, não do diff.
Dois painéis de texto, um diff. Sem cadastro, sem upload, sem ida ao servidor.
Cole a versão antiga à esquerda, a nova à direita. Ou clique em Upload em qualquer painel para carregar um arquivo .md, .markdown ou .mdx. O botão Exemplo preenche os dois lados com um README pequeno para você ver o diff funcionando antes de colar seu próprio conteúdo.
Um arquivo editado no Windows costuma ter quebras CRLF; um arquivo de servidor Linux usa LF. Um diff de caractere trata isso como diferente, o que pode pintar todas as linhas como alteradas. Se o diff parecer suspeitosamente cheio de vermelho e verde, normalize os dois arquivos para a mesma quebra de linha no seu editor antes. O VS Code mostra a quebra ativa na barra de status inferior.
Exclusões aparecem em vermelho à esquerda, inserções em verde à direita. Os dois painéis rolam em sincronia. Blocos de frontmatter, cercas de código, linhas de tabela e itens de lista são todos só texto para o motor de diff, então as mudanças dentro deles aparecem do mesmo jeito que mudanças no corpo do texto. As contagens de mudanças em cada cabeçalho dão uma medida rápida de quão pesada foi a edição.
Você quer uma leitura rápida do que mudou em README.md em uma branch de PR contra a main, mas não quer abrir o GitHub, passar pelo preview renderizado e clicar em "Display the source diff" três menus abaixo. Cole os dois arquivos crus aqui. Títulos, cercas de código e alvos de link aparecem com clareza. Útil quando o PR também mexe em cem arquivos de fonte e a mudança da doc se perde no ruído.
Notas de versão passam por várias edições até saírem. Rascunhos são reordenados, marcadores são fundidos, números de versão se mexem. Diferenciar o RELEASE_NOTES.md publicado anterior do novo rascunho pega entradas perdidas e duplicações acidentais, algo em que o preview renderizado é ruim porque o olho desliza por linhas parecidas. O diff também facilita verificar se a seção ## Breaking changes realmente cresceu entre versões.
Sua equipe escreve docs em Markdown em um repositório Git, mas o site público é gerado por um CMS ou gerador estático como MkDocs, Hugo ou Docusaurus. Às vezes a página publicada se afasta da fonte: alguém editou a página ao vivo pela UI do CMS e esqueceu de empurrar de volta, ou um passo de CI reescreveu o arquivo. Exporte a página publicada como Markdown, jogue em um painel, jogue o .md do repositório no outro, e o desvio fica diante de você em segundos.
Você mandou um post de blog em Markdown para um editor. O editor devolveu uma versão com marcações. Um diff entre os dois absorve o feedback bem mais rápido do que reler parágrafo por parágrafo, especialmente quando o editor reordenou seções ou reescreveu sua introdução. Funciona igualmente bem para conteúdo escrito por terceiros em que o redator precisa confirmar quais ajustes de voz sobreviveram à passagem editorial.
Migrar um site Docusaurus ou Astro de .md para .mdx parece uma operação inócua, até você descobrir que alguns imports mudaram de lugar, componentes JSX substituíram tabelas que antes eram Markdown puro, e algumas cercas de código agora estão envolvidas em componentes próprios. Diferencie o velho page.md do novo page.mdx arquivo a arquivo e as decisões da migração ficam revisáveis. Mesmo fluxo no sentido inverso se você concluir que o MDX foi um erro e quiser voltar para Markdown puro.
Um resumo curto dos casos limítrofes de sintaxe que esta ferramenta mais traz à tona. A coluna de dialeto diz quais sabores realmente suportam o recurso, já que a maior parte das surpresas entre renderizadores nasce daí.
| Topic | What this tool does |
|---|---|
| Diferenças entre sabores | Markdown é uma família. CommonMark é a base de fato. GFM adiciona tabelas, listas de tarefas, tachado e links automáticos. Pandoc e MultiMarkdown adicionam notas de rodapé, listas de definições e mais. Uma mesma fonte pode renderizar de formas bem diferentes entre eles. |
| Tabelas | Tabelas com pipes existem em GFM e Pandoc. Elas não fazem parte do CommonMark nem do Markdown original. Se um renderizador imprime caracteres | brutos em vez de células, o parser é CommonMark estrito e você precisa de um compatível com GFM. |
| Tachado | ~~texto~~ é uma extensão do GFM. Markdown original e CommonMark não suportam. Pandoc suporta com a extensão strikeout ligada. Se seu texto está renderizando com tils literais, o renderizador não conhece GFM. |
| Listas de tarefas | - [ ] tarefa e - [x] feita são extensão do GFM. CommonMark renderiza como simples marcadores com colchetes literais. GitHub, GitLab e a maioria dos sites de docs modernos suportam; processadores Markdown padrão geralmente não. |
| Blocos de código: cercados vs indentados | Blocos cercados (três crases ou tils, com tag de linguagem opcional) são CommonMark e suportados em todo lugar. A especificação original só tinha blocos com indentação de quatro espaços, que ainda funcionam mas não levam dica de linguagem. Misturar os dois em um arquivo é legal, porém bagunçado. |
| Quebras de linha forçadas | Três opções: terminar a linha com dois espaços ao final, terminar com uma contrabarra \ (CommonMark e GFM, não original) ou inserir uma linha em branco para quebra de parágrafo. Os espaços finais são invisíveis na maioria dos editores, por isso quebras forçadas costumam sobreviver a um diff que nenhum humano percebe. |
| Frontmatter | YAML entre cercas ---, TOML entre +++ ou JSON entre { } bem no topo do arquivo. Não faz parte da especificação do Markdown, mas é onipresente em Jekyll, Hugo, MkDocs, Docusaurus e Astro. Os renderizadores removem antes de fazer parsing do corpo. |
| HTML inline | CommonMark permite tags HTML cruas dentro do Markdown. GFM também, mas aplica um sanitizador de HTML ao renderizar no github.com. Alguns geradores estáticos sanitizam, outros deixam o HTML passar e alguns escapam. Diffs de páginas com blocos <div> ou <iframe> embutidos são comuns em auditorias de migração. |
Não. A ferramenta diferencia o texto-fonte do Markdown, não o HTML que um renderizador produziria. É proposital. Dois documentos podem renderizar para o mesmo HTML e ainda assim ter fontes com diferenças relevantes, por exemplo marcadores escritos com * contra - ou negrito escrito com ** contra __. O diff em nível de fonte preserva esse sinal. Se você quer ver como o documento renderiza, cole no seu visualizador de sempre: a UI web do GitHub, o VS Code ou seu gerador estático.
Um diff de HTML renderizado diz o que os leitores vão ver. Um diff de fonte diz o que de fato foi mudado no arquivo. Eles respondem a perguntas diferentes. Para Markdown, o diff de fonte é quase sempre o mais útil porque mostra fielmente as edições do autor: um nível de título mudou de ## para ###, um bloco de código com cerca trocou de tag de linguagem, um link relativo virou absoluto. Se você quer comparação no nível de HTML, passe os dois arquivos pelo seu renderizador antes e diferencie a saída.
O diff em si não faz parsing de Markdown, então não importa qual dialeto você usa. Tabelas, listas de tarefas, tachado e links automáticos parecem só texto. O sabor importa quando você pergunta se o documento ainda renderiza certo. CommonMark é o que mais se aproxima de uma especificação base, e GitHub Flavored Markdown é o CommonMark mais tabelas, listas de tarefas, tachado e links automáticos. Escolha o que seu renderizador-alvo suportar.
Frontmatter é só texto no topo do arquivo, delimitado por --- para YAML ou +++ para TOML. Geradores estáticos como Hugo, Jekyll e MkDocs usam isso para metadados de página. O diff trata o bloco como texto comum, então mudanças em title:, date: ou tags: aparecem como qualquer outra linha. Se seu frontmatter é grande e sensível à indentação, nossa página de diff de YAML é melhor para esse bloco isolado.
Sim. MDX é Markdown com componentes JSX embutidos, e o JSX é só mais texto do ponto de vista do diff. Você pode colar um arquivo .mdx em qualquer painel e o diff vai destacar mudanças em imports, props de componentes e no Markdown ao redor do mesmo jeito que faz com .md. A única coisa que a ferramenta não faz é validar se o seu JSX compila; isso é trabalho do compilador MDX. Para revisar só os pedaços JSX como código, cole no nosso diff de texto.
Quebras de linha são caracteres, então um arquivo salvo em CRLF estilo Windows e outro em LF estilo Unix saem como diferentes em cada linha. Se seus painéis parecem cheios de mudanças fantasmas, esta é quase sempre a causa. A solução é normalizar os dois arquivos para a mesma quebra de linha no seu editor antes de colar; no VS Code a quebra ativa aparece na barra de status inferior e troca com um clique. A configuração core.autocrlf do Git também pode introduzir diferenças surpresa de CRLF entre máquinas.
Seu Markdown nunca sai do navegador. O editor, o diff e o formatador rodam todos na sua máquina. Sem analytics sobre sua entrada, sem logs, sem ida ao servidor. Para leitura de fundo sobre o formato, há material no Wikipédia, com a especificação CommonMark mais recente em spec.commonmark.org/0.31.2 e o sabor do GitHub em github.github.com/gfm.