Cole a versão A à esquerda, a versão B à direita e veja exatamente o que mudou. Sem git clone, sem IDE, sem cadastro. Roda inteiramente no navegador.
Uma ferramenta gratuita no navegador para comparar duas versões de código sem abrir Git, GitHub ou seu IDE. Cole a versão antiga à esquerda, a nova à direita, e as diferenças aparecem destacadas caractere por caractere. O texto nunca sai da sua máquina, o que importa quando o trecho vem de um repo privado ou de uma branch ainda não mesclada.
Foi feita para o momento em que um colega larga duas versões de uma função no Slack e pergunta "o que mudou?". Subir um checkout local para um diff de 12 linhas é exagero. Abrir a view de PR do GitHub se ainda não há PR também é. Dois painéis de texto, um diff, resolvido em quinze segundos.
Isto não substitui o git diff em uma working tree real. Não dá para fazer staging de hunks, aplicar patches ou rodar blame. O que dá é a parte que você mais precisa: pegar dois blocos arbitrários de texto e mostrar as edições entre eles. Por baixo, o diff usa o mesmo motor que a nossa ferramenta compare-text, agora com cara de code review.
O diff roda caractere por caractere e depois um passe de limpeza semântica reagrupa as mudanças em blocos legíveis, para que o destaque caia sobre um identificador renomeado e não sobre cada letra individual. Inserções no painel da direita aparecem em verde; remoções no painel da esquerda aparecem em vermelho. Os dois painéis rolam sincronizados, então quando você acha uma mudança na linha 80 de um lado, o outro lado pula junto.
Por que nível de caractere e não de linha? Porque para trechos curtos a visão só por linha é grossa demais. Renomear uma variável de id para userId é uma única mudança de identificador; um diff por linha mostraria a linha inteira como apagada mais uma linha nova inserida, o que tecnicamente está certo, mas torna a edição real mais difícil de notar. O modo caractere com limpeza semântica destaca o token renomeado e deixa o resto da linha quieto. Em arquivos longos a balança vira, e por isso o diff clássico por linha é o que o Git usa por padrão. Cada um tem seu lugar. Esta ferramenta dá a visão amigável para trechos.
O que a ferramenta deliberadamente não faz: ela não conhece sintaxe. Não parseia JavaScript, Python nem Java. Um bloco reformatado com a mesma semântica vai aparecer como diff, porque para um comparador de texto é texto diferente. Se você precisa de diff que entenda formato para payloads estruturados, nossa página compare-json faz isso para JSON, compare-yaml para YAML e compare-xml para XML e arquivos POM. Para código fonte cru, o diff de texto somado aos seus olhos costuma ser mais rápido do que configurar uma ferramenta sintática para algo pontual.
Dois painéis de texto, um diff. Sem login, sem upload, sem formato de patch para parsear.
Copie a versão antiga da função, arquivo ou trecho do seu editor, terminal ou de onde estiver. Ctrl+C e cole no painel da esquerda. Se você está puxando de git show <commit>, copie o corpo do arquivo em vez do cabeçalho do patch, para que o diff destaque só mudanças reais de código.
Mesma coisa com a versão nova. Se um colega colou no Slack, Teams ou no e-mail, copie direto de lá. Espaços e indentação são preservados ao colar, o que importa em linguagens onde a indentação é significativa, como Python e YAML. Tab vs espaços vai aparecer como diferença se os dois trechos não combinarem.
Remoções aparecem como riscos vermelhos à esquerda; inserções como verde à direita. Os contadores de mudança em cada cabeçalho dizem quantas edições distintas foram detectadas. Leia os destaques, foque primeiro em mudanças de lógica (fluxo de controle, condicionais, tratamento de erro) e trate renomeações puras ou mudanças de formato como prioridade menor na revisão.
Alguém solta dois blocos de código no chat e pergunta qual está certo. Clonar o repo, trocar de branch e abrir a IDE para um trecho de 20 linhas é esforço desperdiçado. Cole os dois na ferramenta de diff e a resposta vem antes da próxima mensagem. É o motivo mais comum de gente recorrer a um diff online.
Pipelines de CI, Dockerfiles, package.json e YAML de workflows do GitHub Actions mudam o tempo todo. Um colega edita .github/workflows/ci.yml em uma branch, o build quebra, e você quer ver o que mudou sem fazer checkout da branch dele. Cole a versão da main ao lado da versão quebrada e o passo culpado costuma aparecer em segundos. Para arquivos de workflow, nossa página de diff de YAML trata casos de indentação de forma mais limpa.
Product managers, designers e account managers às vezes precisam saber o que uma mudança de código faz sem ler uma interface de Git. A view de PR do GitHub assume familiaridade com sintaxe de diff, árvore de arquivos e comentários de revisão. Colar o antes e depois numa visão limpa de dois painéis e percorrer os destaques juntos é muito mais amigável. Também é útil em postmortems de incidente quando o público inclui pessoas fora de engenharia.
Você tem a saída de git show abc123 e a de git show def456 para um arquivo em dois commits, talvez de um log de CI ou de um sandbox remoto onde não dá para rodar comandos git facilmente. Tire os cabeçalhos do patch, cole os dois conteúdos do arquivo e compare. Funciona bem quando você está depurando em um servidor, lendo um artefato de build ou revisando um aviso de segurança que cita conteúdos de arquivo de dois commits específicos.
Um fornecedor manda uma integração de exemplo em PDF. Um regulador envia por e-mail um trecho de código de política. Um consultor anexa uma versão corrigida do seu script. Nada disso vem como repo clonável. Copie o texto do PDF ou do e-mail, cole ao lado da sua versão atual e você tem uma superfície de revisão usável em menos de um minuto. Conte com algum ruído de formatação ao colar de PDF; quebras de linha e aspas costumam ser as culpadas.
Os casos em que um diff de texto puro discorda do que o Git, sua IDE ou sua ferramenta de code review mostrariam. Vale dar uma olhada antes de colar código de produção e se preocupar com falso positivo.
| Topic | What this tool does |
|---|---|
| Fim de linha (CRLF vs LF) | CRLF estilo Windows e LF estilo Unix são bytes diferentes. Um arquivo colado de um editor Windows e outro colado de um container Linux vão aparecer como diff de arquivo inteiro se os fins de linha discordarem, mesmo com texto visível idêntico. O Git normaliza isso com core.autocrlf; esta ferramenta não. |
| Espaço no fim da linha | Espaços ou tabs no fim da linha vão aparecer como diferença. O core.whitespace do Git pode avisar ou auto-corrigir no commit; aqui, o que você cola é o que você compara. Se o ruído de fundo do code review está cheio de mudança de espaço no fim, tire isso no editor antes de comparar. |
| Arquivos binários | Esta ferramenta é só de texto. Colar o conteúdo de um arquivo binário (um PNG, um JAR compilado, um BD sqlite) vai produzir bobagem ou travar a aba. Para diff binário, o Git mostra "Binary files differ" em vez de um patch; é preciso tooling específico do formato para o conteúdo real. |
| Marcação text vs binary do .gitattributes | O .gitattributes de um repo pode sobrescrever a detecção texto-vs-binário do Git por padrão de arquivo. Essa configuração não viaja com copy-paste. Se você suspeita que um arquivo está sendo tratado de forma diferente em dois checkouts, esse arquivo é o lugar certo para olhar; esta ferramenta vai comparar como texto puro de qualquer forma. |
| Diff por caractere vs por linha | Esta página usa diff em nível de caractere com limpeza semântica. O Git vai por linha por padrão, com git diff --word-diff opcional para nível de palavra. Caractere é melhor para trechos curtos onde um único token mudou; linha é melhor para arquivos longos onde muitas linhas mudaram em bloco. |
| git diff --word-diff | O modo --word-diff do Git destaca mudanças em nível de palavra dentro de uma linha, mais perto do que esta ferramenta faz para trechos. O formato de saída é diferente (markup amigável a terminal vs painéis lado a lado), mas a intenção se sobrepõe. Se você vive no terminal, --word-diff é o equivalente local. |
| Limites de arquivos grandes | Diffs no navegador respondem bem até alguns milhares de linhas por lado. Acima disso, a limpeza semântica fica lenta e o DOM renderizado fica pesado. Para arquivos enormes, rode git diff localmente e mande para um pager, ou quebre a comparação em seções menores. |
| Encoding (só UTF-8) | O diff assume entrada UTF-8, o que cobre quase todo o código fonte em 2026. Arquivos salvos como UTF-16, Windows-1252 ou Shift-JIS podem aparecer como mojibake ao colar dependendo do navegador. Se um trecho estiver embaralhado, salve o arquivo fonte como UTF-8 antes de copiar. |
O git diff local compara dois refs (commits, branches, working tree) dentro de um repositório real. Ele conhece o seu index, sua worktree e seu histórico. Esta ferramenta online não faz nada disso. Ela compara dois blocos arbitrários de texto que você cola. Use o git diff para revisão real em um repo com checkout. Use isto quando tiver dois trechos sem jeito prático de colocá-los numa working tree, ou quando quiser uma visão lado a lado sem trocar de contexto.
Não exatamente. GitHub e GitLab usam unified diff por linha com contexto de arquivo, cabeçalhos de hunk e resumos por arquivo. Esta ferramenta usa diff em nível de caractere com limpeza semântica, melhor para trechos curtos e pior para arquivos inteiros com muitas mudanças. Para uma revisão de pull request real, vá para a view de PR do GitHub. Para uma comparação rápida de trecho fora do PR, isto é mais rápido e não exige navegar até o repo certo.
Não. É um diff de texto puro. Ele não parseia a linguagem, então não dá para saber que uma variável renomeada é o mesmo identificador em 12 lugares, e ele não consegue ignorar reformatações de espaço como faria um diff sintático. Para a maioria das revisões de trecho isso basta, porque você lê os destaques com o seu próprio cérebro. Se você precisa de diff semântico real para código, sua IDE (VS Code, IntelliJ) ou um diff baseado em tree-sitter é a ferramenta certa. Esta página otimiza velocidade, não parsing profundo.
O comando clássico Unix diff -u produz um patch em formato unificado (o mesmo formato que o Git usa internamente). É baseado em linha e foi pensado para ser legível por máquina, para você aplicar o patch em outro lugar. Esta ferramenta é legível por humanos. Mostra dois painéis lado a lado com destaque em linha em vez de uma única coluna de linhas com mais e menos. Não produz um arquivo de patch que dê para aplicar com git apply ou patch -p1. Se você precisa gerar um patch, use a linha de comando. Se precisa ler um diff, isto é mais amigável.
Sim, mas do jeito dela. CRLF (Windows) e LF (Unix) vão aparecer como diferença se os dois trechos colados não combinarem, porque tecnicamente são bytes diferentes. Espaço no fim da linha também. Isto bate com o jeito que o Git trata arquivos quando core.autocrlf está desligado. Se você só liga para mudanças de lógica e não para espaços, dê trim em cada painel antes de colar. Não oferecemos hoje uma chave "ignorar espaços", mas está no roadmap; git diff -w é o equivalente local.
Na prática sim. O diff roda no seu navegador, então entradas muito grandes (uma biblioteca vendorizada inteira ou um arquivo gerado de 50.000 linhas) vão deixar a página lenta ou travar a aba dependendo da memória do navegador. Para revisão de código típica (funções, arquivos, scripts de build, configs até alguns milhares de linhas por lado) o diff termina praticamente instantâneo. Se você precisa comparar repositórios inteiros, uma ferramenta Git real ou um comparador de pastas é a resposta certa; esta página foi feita para trechos e arquivos avulsos.
Seu código nunca sai do navegador. O diff, o destaque e a renderização rodam todos na sua máquina. Não fazemos upload do texto, não logamos e não passamos para nenhum serviço de terceiros. Isto importa principalmente para revisão de código proprietário: colar uma feature não lançada, um patch de segurança ou um trecho de um repo privado em um serviço na nuvem pode por si só violar a política de tratamento de dados da sua empresa. Verificar essa afirmação é direto. Abra o DevTools do navegador, vá para a aba Network, cole as duas versões e observe. Não há requisições de saída quando você compara. O mesmo modelo de privacidade vale nas nossas outras ferramentas, incluindo compare-text, compare-json e compare-yaml. Revisão de código funciona melhor quando a superfície de revisão é confiável.