Diff HTML: Compare Dois Arquivos HTML Online
Cole, formate e compare dois documentos HTML lado a lado. Realce de sintaxe ciente de tags e verificações de boa formação ao vivo incluídos.
O que é a ferramenta de diff HTML?
Uma ferramenta gratuita no navegador para comparar dois documentos HTML. Cole a versão antiga de uma landing page à esquerda, a nova à direita, e as mudanças se acendem tag por tag e atributo por atributo. Nada é enviado.
O diff em si é a nível de caractere. O botão Format em cada painel reformata seu HTML com indentação consistente, do jeito que Prettier ou HTML Tidy fariam. O realce de sintaxe segue o WHATWG HTML Living Standard, então elementos void, atributos booleanos e referências de entidades são todos renderizados corretamente enquanto você lê o diff.
Se você já enviou uma correção de copy para uma página de marketing e perdeu uma hora descobrindo por que um nome de classe na seção hero também mudou, esta é a ferramenta que traz isso à tona em segundos. Para prosa simples, nosso diff de texto é a escolha certa. O primo estrito do HTML, XML, tem um diff XML dedicado. E como Markdown frequentemente compila para HTML em builds de sites estáticos, o diff de Markdown é um vizinho útil.
Como o diff realmente funciona
Isto é um diff a nível de texto com realce de sintaxe ciente de HTML, não um diff de DOM. A comparação roda a nível de caractere, depois um passo de pós-processamento semântico desloca os realces para que caiam em nomes de tag, valores de atributo e texto visível em vez de pontuação aleatória. Inserções aparecem em verde no painel direito, exclusões em vermelho à esquerda.
HTML tem mais peculiaridades de parsing do que as pessoas lembram, e a maioria só importa quando você compara dois arquivos como texto. Pelo algoritmo de parsing, a ordem de atributos não é significativa, as aspas de atributos podem ser simples, duplas ou ausentes para alguns valores, e nomes de tag e atributo são case-insensitive. Um diff de texto ainda sinaliza cada reordenação e troca de maiúsculas. A solução prática é formatar ambos os lados com a mesma ferramenta (Prettier com parser: "html" funciona bem) para que os painéis fiquem normalizados antes de você ler o diff.
Esta ferramenta não faz parsing do documento numa árvore DOM e compara nós. Isso significa que dois arquivos que renderizam idênticos num navegador, por exemplo um com <img src="a.png"> e outro com <img src='a.png' />, ainda assim aparecerão como diferentes aqui. Se você precisa de uma comparação verdadeiramente estrutural, faça parsing dos dois lados com DOMParser e percorra as árvores você mesmo, ou passe ambos pelo Tidy primeiro. Para 95% dos casos de revisão de código (uma correção de copy, uma troca de atributo, adicionar um aria-label), o diff de texto é mais rápido e mais claro.
Como comparar HTML em três passos
Dois painéis de texto, um diff. Sem cadastro, sem upload, sem ida e volta ao servidor.
- 1
Cole ou envie seu HTML
Cole o HTML antigo à esquerda, o novo HTML à direita. Ou clique em Enviar em qualquer um dos lados para carregar diretamente um arquivo .html, .htm ou .eml. O botão Exemplo preenche ambos os painéis com um pequeno trecho de landing page se você quiser ver a ferramenta em ação primeiro.
- 2
Formate ambos os lados para uma comparação justa
Clique em Format em cada painel para pretty-print com indentação consistente. Isso normaliza espaços em branco e quebras de linha, então o diff foca em mudanças de conteúdo reais, não em ruído de formatação de um arquivo Windows com CRLF vs um Unix com LF. O selo de validação fica verde quando o documento parseia limpamente.
- 3
Leia o diff
Exclusões aparecem com realce vermelho à esquerda, inserções com realce verde à direita. As contagens de mudanças em cada cabeçalho dizem quantas edições distintas o diff encontrou entre nomes de tag, valores de atributo e texto visível. Role qualquer painel e o outro segue em sincronia.
Quando o diff HTML é a ferramenta certa
Comparar duas saídas de templates renderizados no servidor
Uma mudança de template no CMS sai e um consumidor downstream relata markup quebrado no hero. Curl o HTML renderizado antes e depois do deploy, cole ambos no diff, e o <div> wrapper culpado ou a troca de classe fica óbvia. Útil para upgrades de temas WordPress, edições de layout em Hugo e Jekyll, e qualquer saída renderizada no servidor onde o template fonte não é diretamente legível.
Diff de HTML de email-template antes de um teste A/B
HTML de email não perdoa. O Outlook ainda usa o motor de renderização do Word, então um aninhamento de <table> trocado ou um atributo style inline renomeado pode estilhaçar o layout. Diff a variante A contra a variante B antes de empurrar a campanha, depois passe ambos por Litmus ou Email on Acid. Pegar um cellpadding="0" faltante no diff sai mais barato do que pegá-lo em mil caixas de entrada.
Revisar mudanças de atributos de acessibilidade num PR
Um PR adiciona atributos aria-label, role e aria-describedby em metade dos componentes. O diff de texto torna trivial confirmar que cada elemento interativo ganhou o atributo certo, que nenhum role="presentation" foi aplicado a um botão real, e que nenhum elemento focável perdeu seu nome acessível. Combine isso com axe DevTools ou Lighthouse para a auditoria de fato.
Comparar uma landing page de marketing após uma correção de copy
Um copywriter devolve a home com headlines revisados e um CTA novo. Cole o HTML em produção contra o HTML proposto e o diff te diz exatamente quais <h1>, <p> e textos de botão mudaram, mais quaisquer edições de class ou href que vieram junto. Mais rápido que um Word com controle de alterações e sobrevive intacto à viagem de volta para o codebase.
Auditar a saída de um sanitizador HTML por regressões XSS
Após um bump de versão de DOMPurify ou sanitize-html, faça testes de regressão do sanitizador com payloads conhecidos como ruins e diff a saída contra um baseline bom anterior. Um sanitizador que de repente preserva <svg onload="..."> ou URLs javascript: em atributos href é exatamente o tipo de regressão que você quer pegar em CI antes que vá para produção. O diff faz mudanças de um único caractere (um escape faltante) saltarem aos olhos.
Referência rápida HTML
Uma chuleta curta para os detalhes de parsing que esta ferramenta traz à tona com mais frequência. Tudo fundamentado no WHATWG HTML Living Standard.
| Topic | What this tool does |
|---|
| Elementos void | <img>, <br>, <input>, <meta>, <link>, <hr> e companhia não têm tag de fechamento. A barra final estilo XHTML <br /> é permitida em HTML5 mas renderiza como no-op; o parser a ignora. |
|---|
| Ordem de atributos | Não significativa pela spec HTML. <a href="/x" class="btn"> e <a class="btn" href="/x"> são idênticos para um parser. Um diff de texto sinaliza a troca; formate ambos os lados para manter a ordem estável. |
|---|
| Aspas de atributos | Aspas duplas, simples ou nenhuma para valores sem espaços ou caracteres especiais. id=hero, id='hero' e id="hero" são equivalentes. A maioria dos guias de estilo exige aspas duplas por consistência. |
|---|
| Atributos booleanos | O que importa é a presença. <input disabled>, <input disabled=""> e <input disabled="disabled"> desabilitam o input todos. A spec recomenda a forma nua; XHTML exigia a forma verbosa. |
|---|
| Sensibilidade a maiúsculas | Nomes de tag e atributo são case-insensitive em HTML (<DIV> equivale a <div>). Valores de atributo são case-sensitive (id="Hero" difere de id="hero"). A convenção desde HTML5 é tags e atributos em minúsculas. |
|---|
| Entidades de caractere | Cinco embutidas: & < > " '. Mais entidades nomeadas como e referências numéricas como é para letras acentuadas. Seções CDATA só são válidas em conteúdo estrangeiro (SVG, MathML), não em HTML regular. |
|---|
| DOCTYPE | HTML5 usa a forma curta <!DOCTYPE html>. DOCTYPES XHTML 1.0 mais antigos ainda são parseados mas disparam o modo no-quirks da mesma forma. Um DOCTYPE faltante ou mal formado coloca a página em modo quirks, o que muda o comportamento do modelo de caixa. |
|---|
| Espaço em branco | Sequências de espaços, tabs e quebras de linha colapsam num único espaço ao renderizar, exceto dentro de <pre>, <textarea> e elementos com CSS white-space: pre. O texto fonte é preservado, então um diff de texto vê cada byte. |
|---|
Diff HTML: perguntas frequentes
Por que usar a visão de diff HTML em vez de texto puro para markup?
Por baixo é o mesmo algoritmo a nível de caractere, mas o editor usa o realce em modo HTML para que tags, atributos e entidades sejam renderizados com a coloração de sintaxe familiar enquanto você lê o diff. O botão Format usa um pretty-printer ciente de HTML, não uma reformatação genérica de texto, o que mantém o aninhamento de elementos intacto. Para prosa sem markup, nosso diff de texto basta; para qualquer arquivo onde os limites de tag importam, esta visão é mais fácil de varrer.
A ordem dos atributos num elemento importa?
Não para um navegador. O HTML Living Standard diz que a ordem de atributos numa tag de abertura não é significativa, então <a href="/x" class="btn"> e <a class="btn" href="/x"> renderizam idênticos. Um diff de texto ainda vai sinalizar a troca porque vê os caracteres crus. A solução é formatar ambos os lados com a mesma ferramenta (Prettier e html-validate ordenam de forma sensata) para que a ordem de atributos seja estável antes de comparar.
Por que espaços em branco entre elementos aparecem no diff?
HTML colapsa a maioria das sequências de espaços em branco num único espaço ao renderizar, então dois arquivos que parecem idênticos num navegador podem ter texto fonte muito diferente. Dentro de <pre> e <textarea>, o espaço em branco é preservado. O diff é a nível de texto, então cada espaço, tab e quebra de linha conta. Formate ambos os lados primeiro para normalizar a indentação; só as mudanças significativas permanecerão realçadas.
Posso comparar a estrutura DOM ignorando a formatação?
Esta ferramenta faz um diff de texto, não um diff de DOM, então a forma mais confiável de ignorar ruído de formatação é formatar ambos os lados com o mesmo pretty-printer (Prettier, HTML Tidy ou htmlhint --format) antes de colar. Isso normaliza indentação, aspas de atributos e espaço em branco no fim. Para uma comparação verdadeira a nível de árvore, faça parsing de cada lado com DOMParser e percorra os nós; para revisão de código e trabalho de copy-edit, o fluxo formatar-depois-diff é mais rápido e pega os mesmos bugs.
Como JavaScript e CSS inline são tratados?
O conteúdo de <script> e <style> é diferenciado como texto puro, caractere por caractere. Isso significa que uma mudança de uma linha em CSS dentro de um bloco <style> ou uma função renomeada dentro de um <script> inline aparecerá exatamente onde você espera. Para blocos de script maiores, considere extrair para arquivos .js e diferenciar separadamente. O modo HTML do editor ainda realça os limites de script e style para que o markup ao redor permaneça legível.
E quanto à codificação de caracteres e entidades?
Os arquivos são lidos como UTF-8, que é o padrão para HTML5 e o que a tag <meta charset="UTF-8"> declara. Entidades nomeadas como &, <, > e são diferenciadas como seu texto fonte literal, não a forma decodificada, então uma troca de para um caractere de espaço real aparecerá como uma mudança. Se dois arquivos renderizam idênticos no navegador mas o diff acende no início, suspeite de um byte order mark UTF-8 em um deles.
Privacidade e como isto funciona
Seu HTML nunca sai do seu navegador. O formatador, o validador e o diff rodam todos na sua máquina, localmente. Sem analytics no seu input, sem logs, sem ida e volta "prestativa" para a nuvem. O realce de sintaxe segue o WHATWG HTML Living Standard, e a recomendação mais antiga W3C HTML 5.2 é uma referência cruzada útil. A documentação de referência a nível de elemento está no MDN, e os padrões de acessibilidade vêm do ARIA Authoring Practices Guide. Leitura de fundo sobre o formato em si na Wikipedia.