Text Diff online: comparar dois textos com LCS/Myers + 6 casos práticos
Uma ferramenta de text diff online responde rápido a uma pergunta: o que realmente mudou entre a versão A e a versão B? Você cola dois blocos de texto, a ferramenta roda um algoritmo de Longest Common Subsequence (LCS) e devolve uma visualização lado a lado ou unificada com cada inserção, remoção e edição, geralmente em menos de um milissegundo.
Este guia é para desenvolvedores em revisão de código, SREs comparando trechos de log, advogados marcando contratos e redatores revisando edições. Ele cobre o algoritmo (LCS, Myers, Patience), as duas visualizações padrão, as opções de “ignorar” que resolvem 95% das queixas do tipo “parece que mudou tudo”, quando recorrer a um JSON diff, seis casos prontos para copiar e colar e as armadilhas que o próprio algoritmo explica.
Quer pular direto para comparar dois textos agora? Abra o Text Diff: roda inteiramente no seu navegador, sem upload.
1. O que é um text diff?
Um text diff é o menor conjunto de inserções e remoções que transforma um texto em outro, com cada linha marcada como adicionada, removida ou inalterada. Diffs modernos fazem uma segunda passagem em nível de palavra ou caractere, de modo que uma edição de um único caractere ilumine apenas aquele token e não a linha inteira.
1.1 Por que a igualdade caractere a caractere (===) não basta
Insira uma linha no topo de um arquivo de configuração com 200 linhas e uma comparação ingênua, byte a byte, vai relatar como diferente cada byte depois do ponto de inserção. O texto não mudou, sua posição mudou. Um algoritmo de diff precisa reconhecer que “as próximas 199 linhas continuam sendo as mesmas, só deslocadas em um” e relatar uma única inserção. Esse reconhecimento é o que o LCS oferece, e é por isso que git, GitHub e qualquer ferramenta séria de revisão de código embarcam um.
1.2 Lado a lado vs diff unificado
A visualização lado a lado coloca as duas versões em colunas paralelas e usa cores nas células: verde para adicionado, vermelho para removido, amarelo para modificado. O diff unificado é o formato textual mais antigo, do GNU diff: uma única coluna, marcadores - e +, três linhas de contexto em torno de cada hunk. Mesma comparação, duas apresentações. A seção 4 explica quando usar cada uma.
1.3 Onde se usa text diff
Revisão de código no GitHub e GitLab. Saída do git diff local. Patches colados no Slack. Marcação de contratos. Revisão de tradução. Testes de snapshot de CI que falham com saída +/-. Investigação de timeline de logs. Comparar dois arquivos .env. Qualquer situação em que dois blobs de texto precisem ser casados linha por linha.
Abra o Text Diff e cole dois textos para ver tudo isso em ação. Cada comparação roda localmente dentro do seu navegador.
2. O algoritmo por trás do text diff (LCS + Myers + Patience)
2.1 Longest Common Subsequence
Dadas duas sequências de linhas A e B, a Longest Common Subsequence é a maior lista de linhas que aparecem em ambas, na mesma ordem, sem precisar ser adjacentes. Uma vez obtida a LCS, o diff sai naturalmente: linhas em A que não estão na LCS são removidas, linhas em B que não estão na LCS são adicionadas, linhas na LCS são inalteradas.
O LCS clássico funciona como uma tabela de programação dinâmica de tamanho N × M. A célula (i, j) guarda o tamanho da LCS entre as primeiras i linhas de A e as primeiras j linhas de B. Preencha a tabela da esquerda para a direita, de cima para baixo, e depois caminhe de volta a partir da célula inferior direita para reconstruir o script de edição. Tempo e espaço são ambos O(N×M): tranquilo para dois arquivos de mil linhas, lento para um log de cem mil linhas.
2.2 Myers (1986)
O artigo de Eugene Myers de 1986, “An O(ND) Difference Algorithm and Its Variations”, reformula o problema como o caminho mais curto através de um grafo de edição: os nós são posições (i, j) nas duas entradas, movimentos horizontais são remoções, movimentos verticais são inserções e movimentos diagonais são correspondências. O caminho mais curto é o script de edição mínimo.
Myers roda em O((N+M)D), em que D é o tamanho do script de edição. Quando os dois textos são parecidos (o caso usual em diffs), D é pequeno e o algoritmo fica essencialmente linear. É o padrão em git diff, no GNU diff e no renderizador de PRs do GitHub. Para 99% das entradas web, é a resposta certa.
2.3 Patience diff (Bram Cohen, 2005)
O Patience diff segue uma abordagem diferente: encontre linhas que aparecem exatamente uma vez em cada entrada (chamadas “linhas-âncora únicas”), case essas âncoras e recurse nos intervalos entre elas. A matemática é mais bagunçada (o pior caso continua ruim), mas a saída lê muito melhor em código.
Por quê? Myers minimiza a distância de edição, o que é matematicamente ótimo, mas visualmente péssimo quando o alinhamento ótimo cruza chaves ou linhas em branco sem relação entre si. Patience se recusa a alinhar em boilerplate comum (todo arquivo tem linhas }, todo arquivo tem linhas em branco), de modo que as fronteiras das funções permanecem intactas. Bram Cohen criou o algoritmo para o Bazaar; o Git o entrega como git diff --patience. O algoritmo Histogram, intimamente relacionado (git diff --histogram), é um pouco mais rápido com qualidade de saída semelhante.
Imagine duas versões do mesmo arquivo em que uma função foi movida. Myers pode alinhar a chave de fechamento da função A com a chave de fechamento da função B e relatar os corpos como completamente diferentes. Patience ancora nos nomes únicos das funções e relata um move limpo. Mesma entrada, experiência de revisão bem diferente.
2.4 Comparativo entre algoritmos
| Propriedade | Myers (padrão) | Patience | Histogram |
|---|---|---|---|
| Complexidade de tempo | O((N+M)D) | ~O(N log N) no caso comum | semelhante ao Patience |
| Distância de edição ótima | Sim, script mais curto | Não, pode ser mais longo | Não, pode ser mais longo |
| Lê naturalmente em código | Às vezes desalinha chaves e linhas em branco | Excelente, ancora em linhas únicas | Excelente |
| Usado por | Padrão do git, GNU diff, UI do GitHub | git diff --patience, Bazaar | git diff --histogram |
| Melhor para | Velocidade e correção na maioria das entradas | Code reviews, diffs de refatoração | Igual ao Patience, um pouco mais rápido |
2.5 O que esta ferramenta faz
O Text Diff usa LCS clássico com programação dinâmica e duas otimizações agressivas: corte de prefixo e sufixo comum e uma segunda passagem de LCS em nível de token para o diff intralinha em nível de palavra. Um diff entre duas configurações de duas mil linhas com uma linha alterada colapsa para uma tabela DP 1×1 depois do corte e renderiza em menos de um milissegundo. Para entradas web típicas, a escolha entre Myers e DP é imperceptível: ambos terminam antes de o navegador pintar o resultado.
3. Diff intralinha em nível de palavra: por que uma mudança de um caractere acende a linha inteira
Você muda um identificador numa linha e a linha inteira fica vermelha e verde. Bug? Não, design.
O diff primeiro roda LCS em nível de linha: “a linha 14 foi substituída.” Depois, para cada par substituído, ele roda um segundo LCS em nível de token. Os tokens são produzidos quebrando nos limites de palavras Unicode: sequências de letras e dígitos ficam juntas, espaços em branco e pontuação viram cada um seu próprio token. O segundo LCS devolve o script mínimo de edição em nível de token dentro daquela linha.
O renderizador desenha a linha inteira na cor do destaque para o seu olho a encontrar, e depois pinta apenas os tokens alterados com o fundo brilhante. Os tokens inalterados ao redor levam uma versão atenuada da mesma cor, presentes, mas visualmente silenciosos. Seu olho pousa exatamente na edição.
Exemplo 1: renomeação de identificador. function getUser(id) vira function getUser(userId). A linha inteira é marcada como modificada. Dentro da linha, só id (riscado em vermelho) e userId (verde brilhante) recebem o destaque inline. O resto permanece atenuado.
Exemplo 2: mudança de latência em log. POST /api/orders 201 88ms vira POST /api/orders 201 4200ms. A linha está modificada. Inline, só 88 e 4200 aparecem brilhantes. O path, o método e o status code ficam atenuados, exatamente o que quem está lendo uma timeline de incidente precisa.
Quando muitos tokens mudam, o destaque em nível de palavra vira ruído. A ferramenta cai para uma apresentação em par removido + adicionado: a linha original mostrada como removida, a nova linha mostrada como adicionada, sem coloração intralinha. O limiar é aproximadamente “mais da metade dos tokens difere”.
Resumo: o diff em nível de linha diz qual linha mudou; o diff em nível de palavra diz quais caracteres daquela linha carregam a mudança. Clique em Sample dentro do Text Diff para ver as duas visualizações no mesmo input.
4. Lado a lado vs diff unificado: duas visualizações, um diff
4.1 Visualização lado a lado
Duas colunas: original à esquerda, modificada à direita. Linhas que casam ficam alinhadas horizontalmente. Linhas adicionadas aparecem só na coluna direita com fundo verde; linhas removidas aparecem só na coluna esquerda com fundo vermelho; pares modificados ficam um ao lado do outro com gutter amarelo e destaques inline em nível de palavra.
Use o lado a lado quando um humano vai ler o diff: revisão de PR, ensino, demos, mostrar uma mudança contratual para alguém não-técnico. É a visualização para os olhos.
A contraparte: não viaja. Você não consegue colar uma renderização lado a lado no Slack para alguém aplicar. Não dá para passar por pipe ao patch. Para compartilhar e aplicar, você precisa do unified.
4.2 Formato diff unificado
Diff unificado é um formato em texto puro de cinquenta anos definido pelo GNU diff e padronizado no POSIX. Um exemplo completo:
--- original
+++ modified
@@ -1,3 +1,4 @@
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
+2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.As duas primeiras linhas nomeiam os arquivos de origem. A linha @@ -L,C +L,C @@ é o cabeçalho do hunk: -L,C significa “começando na linha L do original, C linhas estão envolvidas”; +L,C diz o mesmo para a versão modificada. Dentro do hunk, linhas começando com espaço são contexto (inalterado), - é removido, + é adicionado.
Três linhas de contexto acima e abaixo de cada mudança é o padrão do GNU. A maioria das ferramentas permite mudar com -U n: diff -U0 para sem contexto, diff -U10 para dez linhas. O cabeçalho do hunk acompanha o que você escolher.
No Text Diff, clique na aba Unified para trocar de visualização ou em Copy unified diff para colocar o patch no seu clipboard.
4.3 Onde o diff unificado é portátil
Diff unificado viaja. Funciona como moeda comum de mudança textual entre ferramentas.
| Destino | Aceita diff unificado? | Como |
|---|---|---|
GNU patch | Sim | patch -p1 < diff.patch |
git apply | Sim | git apply diff.patch |
| Comentário de revisão em PR no GitHub | Sim (num bloco ```diff) | Renderiza colorido |
| Comentário em MR no GitLab | Sim | Mesmo bloco com cerca |
| PR no Bitbucket / Azure DevOps | Sim | Mesmo bloco com cerca |
| Colar no Slack / Discord | Parcial | Renderiza como texto num bloco de código, sem cor |
| ”Open Patch” do VS Code | Sim | Aplique o patch via Source Control |
| Corpo de issue no Jira / Linear | Parcial | Funciona num bloco de código, sem botão de aplicar |
As mesmas nove linhas de texto ---/+++/@@ se aplicam no patch, no git apply, renderizam em três plataformas de PR e sobrevivem a uma colagem no Slack. Nenhum outro formato de diff chega perto desse alcance.
4.4 Quando escolher cada um
Lado a lado para revisar, unificado para compartilhar e aplicar. Se você é quem está lendo o diff, as colunas são mais rápidas. Se qualquer pessoa ou ferramenta a jusante precisa consumir (um revisor, uma ferramenta, um comando de patch), copie o formato unificado.
5. Opções de ignorar: espaços em branco, caixa, linhas em branco, finais de linha
A maioria das queixas “parece que mudou tudo” é ruído. Quatro toggles resolvem 95% delas.
- Ignorar caixa mapeia
Aparaa. Equivalente agit diff -i. Use para comparações de variáveis de ambiente, auditorias de estilo de palavras-chave SQL, qualquer lugar em que a convenção alterne entre caixa-alta grita e caixa-baixa quieta sem mudar o significado. - Ignorar todos os espaços em branco colapsa cada espaço, tab e quebra de linha antes da comparação. Equivalente a
git diff -w. A cura para reformatações de tabs ↔ espaços, reescrita de indentação e diffs do tipo “migramos para o Prettier” que destroem a contagem de linhas. Um diff ignorando espaços nessas mudanças tipicamente sai de 87 modificações para 4. - Ignorar espaços e tabs no fim da linha remove apenas o whitespace de fim de linha. Equivalente a
git diff -b. A cura para o ruído de CRLF depois de copiar entre máquinas Windows e Unix: os caracteres\rno fim somem do filtro e o conteúdo real se alinha. - Ignorar linhas em branco descarta linhas vazias antes do diff. A cura para “adicionei uma quebra de parágrafo e agora o parágrafo 12 parece completamente diferente” em diffs de prosa.
Uma configuração de 200 linhas que relata “87 modificações” normalmente cai para “4 modificações” depois de Ignorar todos os espaços em branco. Uma cópia Windows-para-Unix que marca cada linha cai para zero com Ignorar espaços no fim. Cada toggle é independente e persiste entre sessões.
CRLF vs LF. Finais de linha do Windows são \r\n; Unix é \n; Mac clássico é \r. Abra um arquivo do Windows num editor Unix que não normaliza e você carrega o \r no fim. Toda linha vai dar diff como “o conteúdo bate, mas tem um \r no final”. Ignorar espaços no fim silencia isso sem perder mudanças reais.
Um aviso. Opções de ignorar são faca de dois gumes. Ligue Ignorar caixa e uma refatoração que muda LOG.error para log.Error parece idêntica. Ligue Ignorar todos os espaços em branco e um bug de indentação no Python fica invisível. Escolha os toggles para a pergunta que você está fazendo e desligue quando terminar.
6. Text diff vs JSON diff vs git diff: matriz de decisão
Text diff é casamento por linha e palavra, sem entender estrutura. É exatamente o que você quer para prosa e exatamente o que você não quer para JSON.
6.1 Matriz de decisão
| Tipo de entrada | Text diff | JSON diff | Git diff |
|---|---|---|---|
| Prosa / Markdown / contrato | Melhor escolha | Ferramenta errada | Parcial (só em arquivos rastreados) |
| Snippet de código (colagem de um arquivo) | Melhor escolha | Ferramenta errada | Parcial (precisa de repo) |
| Código em um repositório (multi-arquivo) | Parcial | Ferramenta errada | Melhor escolha |
| Resposta JSON de API | Ferramenta errada (falso-positivo na ordem das chaves) | Melhor escolha | Ferramenta errada |
| Config YAML / TOML | Parcial (falso-positivo na ordem das chaves) | Melhor escolha (após conversão) | Parcial |
| CSV linha a linha | Parcial | Ferramenta errada | Ferramenta errada |
| Log / heredoc | Melhor escolha | Ferramenta errada | Ferramenta errada |
| Arquivo binário | Ferramenta errada | Ferramenta errada | git diff --binary |
6.2 Quando text diff é a ferramenta errada
Três erros clássicos.
JSON com chaves reordenadas. {"a":1,"b":2} e {"b":2,"a":1} são o mesmo documento JSON. Um text diff relata cada linha como modificada porque elas realmente são linhas diferentes. Use o JSON Diff, que entende que as chaves JSON são desordenadas.
Configs YAML que foram reformatadas. Mude um valor, passe o arquivo por um formatter, e indentação, ordem das chaves e aspas mudam. O text diff relata uma reescrita completa. Converta os dois arquivos para JSON primeiro e compare com o JSON Diff.
Refatorações multi-arquivo com renames. O Git rastreia renames; o text diff não. Se você comparar duas árvores concatenando arquivos num único blob, todo movimento entre arquivos aparece como removido + adicionado. Use git diff (ou git diff --find-renames=80%).
6.3 Quando text diff é exatamente certo
Prosa. Snippets de código colados de qualquer lugar. Marcações de contrato. Recortes de log. Revisão de tradução em que você está casando frases em linguagem natural. Arquivos .env, em que a ordem importa porque os shells leem de cima para baixo. Qualquer coisa em que as próprias linhas carregam significado.
Para se aprofundar em filtrar ruído de diffs JSON (timestamps, IDs de requisição, UUIDs gerados automaticamente), leia Como Ignorar Timestamps e IDs no JSON Diff.
7. Seis casos do mundo real (com entradas para copiar e colar)
7.1 Snippet de revisão de código: renomear função
Você está revisando um PR. O autor renomeou id para userId e adicionou uma guard clause. Cole as duas versões:
// Original
function getUser(id) {
const u = db.users.find(x => x.id === id);
return u;
}// Modified
function getUser(userId) {
if (!userId) return null;
const u = db.users.find(x => x.id === userId);
return u;
}O diff mostra três linhas modificadas e uma linha adicionada. O destaque inline em nível de palavra marca cada token id → userId; a nova guard clause aparece com fundo verde. Opções de ignorar desligadas. Teste no Text Diff e copie a saída unificada para deixar como comentário de revisão.
7.2 Marcação de contrato ou política: uma cláusula inserida
Cinquenta parágrafos de contrato, uma cláusula inserida. Cole a versão de ontem à esquerda e a de hoje à direita:
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.O diff renderiza quarenta e nove linhas inalteradas e uma linha adicionada (+2a. Termination notice must be in writing.). Exporte o diff unificado como trilha de revisão jurídica.
7.3 Investigação de timeline de logs
Você suspeita de uma regressão de latência. Pegue um pedaço dos access logs antes e durante o incidente:
GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21msGET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21msO destaque inline traz à tona 88 → 4200 (um salto de latência de 50×) e 200 → 500 (um endpoint de detalhe de pedido começou a falhar). Para trabalho de log mais profundo (extrair campos, agrupar por endpoint, calcular percentis), combine o diff com o Guia rápido do jq se seus logs forem JSON.
7.4 Revisão de tradução: preservar placeholders
Você contratou uma nova agência de tradução e quer verificar se a nova cópia bate em estrutura com a antiga. Cole a tradução antiga à esquerda, a nova à direita. Ative Ignorar espaços e tabs no fim da linha porque tradutores frequentemente deixam um espaço sobrando no fim das strings.
O diff confirma que cada {username}, {count} e %s permanece no lugar; só o texto em linguagem natural muda. Um placeholder que sumiu aparece como um token removido no diff inline, pego antes de ir para produção. Se você precisa comparar os próprios formatos de placeholder, o Cheat Sheet de Regex cobre \{\w+\} e companhia. Experimente no Text Diff.
7.5 Auditoria de config ou .env: produção vs staging
Compare dois arquivos .env. Ligue Ignorar linhas em branco para que o agrupamento estilo parágrafo não desalinhe as seções. O diff mostra quais chaves diferem em valor, quais existem em um ambiente mas não no outro e onde os comentários ficaram fora de sincronia. Cinco minutos que evitam aquela sessão de debug “funciona em staging mas não em prod”.
7.6 Revisão de prosa ou rascunho
Seu editor devolveu um rascunho. Cole o original à esquerda e a versão editada à direita. O diff de palavras inline mostra exatamente quais frases foram reescritas, quais ficaram intocadas e quais parágrafos foram inseridos. Aceite ou rejeite mudança a mudança, sem Track Changes, sem arquivo Word, sem formato proprietário.
8. Armadilhas comuns e como lê-las como sintomas
O comportamento do algoritmo explica a maior parte da dor do usuário. Cinco reclamações comuns e o que elas realmente significam.
Armadilha 1: “Toda linha está vermelha depois de copiar de Windows para Unix.” Sintoma: cada linha no diff aparece como mudada, embora o conteúdo pareça idêntico. Causa: \r no fim de linha do CRLF. Solução: ligue Ignorar espaços e tabs no fim da linha. O diff vai cair para as mudanças reais.
Armadilha 2: “Colei JSON e 100% das linhas estão diferentes.” Sintoma: dois objetos JSON que deveriam ser equivalentes aparecem completamente mudados. Causa: reordenação de chaves. O text diff trata ordem de linha como significativa; JSON não. Solução: use o JSON Diff para qualquer entrada JSON.
Armadilha 3: “Reformatar tabs ↔ espaços explodiu o diff.” Sintoma: 87 modificações, todas elas indentação. Causa: seu formatter mudou o whitespace inicial de cada linha. Solução: Ignorar todos os espaços em branco vai colapsar o ruído e revelar as mudanças semânticas reais.
Armadilha 4: “O diff diz idêntico, mas o cmp discorda.” Sintoma: o diff relata zero diferenças, mas uma comparação byte a byte aponta divergência. Causa: uma opção de ignorar ficou ligada de uma sessão anterior e está mascarando mudanças reais. Solução: abra o painel de Opções de ignorar, desligue cada toggle e rode o diff de novo.
Armadilha 5: “Uma edição curta aparece como remover + adicionar.” Sintoma: uma pequena mudança aparece como uma linha removida separada e uma linha adicionada separada, em vez de um destaque inline. Causa: a proporção de tokens alterados cruzou o limiar inline e o renderizador caiu para a apresentação de par de linhas. Isso é design, não bug. Troque para a visualização Unified para ver o par clássico -/+ que as ferramentas de patch esperam.
9. Privacidade, performance e quando recorrer à linha de comando
Cada comparação no Text Diff roda em JavaScript dentro do seu navegador. Sem upload, sem arquivo temporário, sem log de servidor, sem analytics no texto que você cola. Seguro para código proprietário, contratos internos, logs privados, qualquer coisa que você não estaria disposto a colar num servidor de terceiros.
Limites práticos: cerca de 5.000 linhas ou 1 MB por lado. O diff em tempo real é desligado acima de 200 KB combinados e o app muda para um botão Diff manual, para que digitar não trave a página. Acima de 5.000 linhas a entrada é truncada e um aviso aparece. Os limites existem porque o diff roda na thread principal (sem web worker), e o handoff para um worker mais a serialização custariam mais do que o próprio diff em entradas pequenas.
Quando sua entrada extrapola o navegador, desça para a linha de comando:
# Unified diff between two files
diff -u a.txt b.txt
# Same, but using git's diff engine (Patience, Histogram, color)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt
# Streaming diff viewer for huge files (Rust, side-by-side, syntax-aware)
delta a.txt b.txtMude para a linha de comando para logs de vários megabytes, arquivos binários, diffs multi-arquivo de repositório, qualquer caso em que você queira coloração ciente de sintaxe como delta, ou em qualquer lugar onde você precise canalizar a saída do diff para outra ferramenta.
10. Unicode, CJK e RTL: notas internacionais sobre text diff
O tokenizer quebra nos limites de palavra Unicode usando três categorias: sequências de palavra (\p{L} letras e \p{N} números), pontuação fora de palavra e whitespace. Cada categoria produz seus próprios tokens, então hello, world! vira hello, ,, , world, !, cinco tokens no total.
Para conteúdo CJK (chinês, japonês, coreano), cada ideograma ou kana é seu próprio token. Mude um caractere numa frase em chinês e só esse caractere recebe o destaque inline, enquanto o resto da linha fica atenuado. A estrutura em nível de parágrafo continua sendo por linha, então uma reescrita de frase que adiciona uma quebra de linha aparece como edição em nível de linha, não em nível de token.
Para idiomas RTL (árabe, hebraico), o diff usa direções CSS lógicas (ms-, me- em vez de ml-, mr-). Em locales RTL, o gutter e as colunas de linha invertem naturalmente; dentro de cada célula de diff, a direção do texto segue o conteúdo, então strings em árabe renderizam da direita para a esquerda enquanto os marcadores + e - continuam alinhados ao gutter inicial.
A normalização de fim de linha reconhece \r\n (Windows), \n (Unix) e \r solitário (Mac OS antigo até a versão 9). Os três se separam como linhas distintas, então um arquivo convertido de uma plataforma para outra não colapsa numa mega-linha única.
11. FAQ
Como funciona um text diff online?
Um text diff quebra as duas entradas em linhas, roda um algoritmo de Longest Common Subsequence (tipicamente Myers, com O((N+M)D)) para encontrar o menor conjunto de inserções e remoções e em seguida marca linhas adicionadas (verde), removidas (vermelho) e inalteradas (cinza). Um segundo LCS em nível de token marca as palavras alteradas dentro de cada linha modificada. O Text Diff roda a comparação inteira localmente no seu navegador.
Qual a diferença entre text diff e JSON diff?
O text diff compara linha por linha, ideal para prosa, código, logs e contratos. O JSON Diff entende o modelo de dados do JSON: a ordem das chaves é irrelevante, os tipos são estritos (1 ≠ "1") e arrays podem casar por chave. Cole JSON num text diff e reordenações de chave ou whitespace vão aparecer como mudanças que o JSON Diff ignora. Use text diff para conteúdo não estruturado e JSON Diff para respostas de API e configs.
Por que o diff mostra linhas inteiras como alteradas quando editei só uma palavra?
Não mostra. A linha está destacada porque algo nela mudou, mas dentro do destaque só os tokens alterados levam o fundo brilhante (verde para adicionado, vermelho riscado para removido). Isto é o diff intralinha em nível de palavra: o contexto da linha continua legível enquanto seu olho pousa exatamente na edição. Quando muito da linha mudou para que o destaque em nível de palavra seja útil, o diff cai para um par separado de remover + adicionar, mantendo a estrutura limpa.
Como ignoro espaços em branco, caixa ou linhas em branco no diff?
Use o painel de Opções de ignorar. Ignorar caixa faz A e a iguais. Ignorar todos os espaços em branco colapsa cada espaço, tab e quebra de linha, equivalente a git diff -w. Ignorar espaços e tabs no fim da linha espelha git diff -b e silencia o ruído de CRLF. Ignorar linhas em branco descarta linhas vazias para que o reespaçamento de parágrafos pare de desalinhar o diff. Cada opção é independente e persiste entre sessões.
O que é o formato unified diff?
Unified diff é o formato textual ---/+++/@@ -L,C +L,C @@ introduzido pelo GNU diff no fim dos anos 1980 e usado pelo git, GitHub, GitLab e pelo comando patch do Unix. Cada hunk mostra três linhas de contexto em torno da mudança, com - para removido e + para adicionado. Copie a saída unificada para um comentário de PR, cole no git apply ou rode patch -p1 < diff.patch para aplicar limpinho.
Myers vs Patience: qual algoritmo de diff é melhor para revisão de código?
Myers é o padrão no git diff e no GNU diff: rápido e matematicamente mínimo, mas às vezes alinha linhas em branco ou chaves de fechamento sem relação, produzindo diffs que “leem estranho”. Patience (Bram Cohen, 2005) ancora em linhas que aparecem exatamente uma vez em cada entrada e recurse entre as âncoras, mantendo as fronteiras das funções intactas. Use git diff --patience (ou --histogram para resultados similares e um pouco mais rápidos) ao revisar refatorações.
O texto que eu colo é enviado para algum servidor?
Não. Cada comparação no Text Diff roda localmente em JavaScript dentro do seu navegador. Seu texto nunca é enviado, registrado em log, gravado em disco ou repassado a terceiros. Só as suas preferências de UI (modo de visualização e toggles de ignorar) ficam salvas no localStorage para a página lembrar na próxima visita, nunca o texto. Confira em DevTools → Network: zero requisições disparam quando você clica em Diff.
Quão grandes podem ser as duas entradas?
O limite prático é em torno de 5.000 linhas ou 1 MB por lado. O diff em tempo real é desligado acima de 200 KB combinados e troca para um botão Diff manual. Acima de 5.000 linhas, a entrada é truncada com aviso. Para arquivos de vários megabytes, mude para diff -u a.txt b.txt, git diff --no-index a.txt b.txt ou delta: eles fazem streaming e dão conta de gigabytes.