Collez la version A à gauche, la version B à droite, et voyez exactement ce qui a changé. Pas de git clone, pas d'IDE, pas d'inscription. Tout tourne dans votre navigateur.
Un outil gratuit dans le navigateur pour comparer deux versions de code sans ouvrir Git, GitHub ou votre IDE. Collez l'ancienne version à gauche, la nouvelle à droite, et les différences sont mises en évidence caractère par caractère. Le texte ne quitte jamais votre machine, ce qui compte quand le snippet vient d'un repo privé ou d'une branche non fusionnée.
Conçu pour le moment où un collègue lâche deux versions d'une fonction sur Slack et demande "qu'est-ce qui a changé ?". Monter un checkout local pour un diff de 12 lignes, c'est trop. Ouvrir la vue PR de GitHub si la PR n'existe pas encore, c'est trop aussi. Deux panneaux de texte, un diff, réglé en quinze secondes.
Ce n'est pas un remplacement de git diff sur un working tree réel. Il ne peut pas stager des hunks, appliquer des patches ou lancer un blame. Ce qu'il fait, c'est la partie dont vous avez le plus souvent besoin : prendre deux blocs de texte arbitraires et vous montrer les modifications. En dessous, le diff utilise le même moteur que notre outil compare-text, présenté pour la code review.
Le diff travaille caractère par caractère, puis une passe de nettoyage sémantique regroupe les changements en blocs lisibles, de sorte que la mise en évidence porte sur un identifiant renommé plutôt que sur chaque lettre individuelle. Les insertions s'affichent en vert dans le panneau de droite ; les suppressions en rouge dans celui de gauche. Les deux panneaux scrollent en synchronisation : si vous trouvez un changement à la ligne 80 d'un côté, l'autre côté saute avec vous.
Pourquoi le caractère plutôt que la ligne ? Parce que pour des snippets courts la vue ligne est trop grossière. Renommer une variable de id en userId, c'est un seul changement d'identifiant ; un diff par lignes vous montrerait toute la ligne supprimée plus une nouvelle ligne insérée, ce qui est techniquement vrai mais rend l'édition réelle plus dure à repérer. Le mode caractère avec nettoyage sémantique met en évidence le token renommé et laisse le reste de la ligne tranquille. Pour les fichiers longs, le compromis s'inverse, et c'est pour ça que le diff classique par lignes est ce que Git utilise par défaut. Les deux ont leur place. Cet outil vous donne la vue adaptée aux snippets.
Ce que l'outil ne fait délibérément pas : il ne connaît pas la syntaxe. Il ne parse pas JavaScript, Python ou Java. Un bloc reformaté avec la même sémantique apparaîtra quand même comme un diff, parce que pour un comparateur de texte c'est du texte différent. Si vous voulez un diff conscient du format pour des payloads structurés, notre page compare-json le fait pour JSON, compare-yaml pour YAML et compare-xml pour XML et fichiers POM. Pour du code source brut, le diff de texte plus vos propres yeux est souvent plus rapide que de configurer un outil syntaxique pour un coup ponctuel.
Deux panneaux de texte, un diff. Pas de login, pas d'upload, pas de format de patch à parser.
Copiez l'ancienne version de la fonction, du fichier ou du snippet depuis votre éditeur, votre terminal ou là où elle se trouve. Ctrl+C puis collez dans le panneau de gauche. Si vous tirez depuis git show <commit>, copiez le corps du fichier plutôt que l'en-tête de patch, pour que le diff ne mette en évidence que les vrais changements de code.
Faites pareil avec la nouvelle version. Si un collègue l'a collée sur Slack, Teams ou par e-mail, copiez directement de là. Les espaces et l'indentation sont préservés au collage, ce qui compte pour les langages où l'indentation est significative comme Python et YAML. Tab vs espaces apparaîtra comme une différence si les deux snippets ne sont pas d'accord.
Les suppressions apparaissent barrées en rouge à gauche ; les insertions en vert à droite. Les compteurs de changements dans chaque en-tête vous disent combien d'éditions distinctes ont été détectées. Lisez les surlignages, concentrez-vous d'abord sur les changements de logique (flux de contrôle, conditionnelles, gestion d'erreurs), et traitez les renommages purs ou changements de formatage comme des priorités basses dans la passe de revue.
Quelqu'un lâche deux blocs de code dans le chat et demande lequel est correct. Cloner le repo, changer de branche et ouvrir l'IDE pour un snippet de 20 lignes, c'est de l'effort gaspillé. Collez les deux dans l'outil de diff et vous avez la réponse avant le message suivant. C'est la raison la plus courante d'utiliser un diff en ligne.
Pipelines CI, Dockerfiles, package.json et YAML de workflows GitHub Actions dérivent en permanence. Un coéquipier édite .github/workflows/ci.yml sur une branche, le build casse, et vous voulez voir ce qui a changé sans checkout de sa branche. Collez la version de main à côté de celle de la branche cassée et l'étape fautive remonte en quelques secondes. Pour les fichiers de workflow spécifiquement, notre page de diff YAML gère les cas d'indentation plus proprement.
Product managers, designers et account managers ont parfois besoin de savoir ce que fait un changement de code sans lire une interface Git. La vue PR de GitHub suppose une familiarité avec la syntaxe diff, l'arbre de fichiers et les commentaires de revue. Coller le avant-après dans une vue propre à deux panneaux, puis parcourir les surlignages ensemble, c'est beaucoup plus accueillant. Utile aussi en postmortem d'incident quand l'audience inclut des gens hors ingénierie.
Vous avez la sortie de git show abc123 et de git show def456 pour un fichier sur deux commits, peut-être depuis un log CI ou un sandbox distant où vous ne pouvez pas lancer facilement des commandes git. Retirez les en-têtes de patch, collez les deux contenus de fichier et faites le diff. Ça marche bien quand vous déboguez sur un serveur, lisez un artefact de build ou revoyez un avis de sécurité qui cite des contenus de fichier sur deux commits précis.
Un fournisseur envoie un exemple d'intégration en PDF. Un régulateur envoie par e-mail un snippet de code de conformité. Un consultant attache une version patchée de votre script. Aucun de ces cas ne vient sous forme de repo clonable. Copiez le texte depuis le PDF ou le mail, collez-le à côté de votre version actuelle et vous avez une surface de revue utilisable en moins d'une minute. Attendez-vous à du bruit de formatage en collant depuis un PDF ; sauts de ligne et guillemets sont les coupables habituels.
Les cas où un diff de texte brut ne dit pas la même chose que Git, votre IDE ou votre outil de code review. À parcourir avant de coller du code de production et de craindre un faux positif.
| Topic | What this tool does |
|---|---|
| Fins de ligne (CRLF vs LF) | CRLF style Windows et LF style Unix sont des octets différents. Un fichier collé depuis un éditeur Windows et un fichier collé depuis un conteneur Linux apparaîtront comme un diff complet si les fins de ligne diffèrent, même avec un texte visible identique. Git normalise ça avec core.autocrlf ; cet outil non. |
| Espaces en fin de ligne | Espaces ou tabs en fin de ligne apparaîtront comme une différence. Le core.whitespace de Git peut avertir ou auto-corriger au commit ; ici, ce que vous collez est ce que vous comparez. Si le bruit de fond de votre code review est plein d'éditions de fin de ligne, retirez-les dans votre éditeur avant de differ. |
| Fichiers binaires | Cet outil est texte uniquement. Coller le contenu d'un fichier binaire (un PNG, un JAR compilé, une BD sqlite) produira du charabia ou bloquera l'onglet. Pour le diff binaire, Git affiche "Binary files differ" plutôt qu'un patch ; il faut du tooling spécifique au format pour le contenu réel. |
| Marquage text vs binary dans .gitattributes | Le .gitattributes d'un repo peut surcharger la détection texte/binaire de Git par motif de fichier. Ce réglage ne voyage pas avec un copier-coller. Si vous suspectez qu'un fichier est traité différemment entre deux checkouts, ce fichier est l'endroit à regarder ; cet outil le diffrera comme du texte brut quoi qu'il arrive. |
| Diff caractère vs ligne | Cette page utilise un diff caractère avec nettoyage sémantique. Git fait par ligne par défaut, avec git diff --word-diff en option pour le niveau mot. Le caractère est meilleur pour les snippets courts où un seul token a changé ; la ligne est meilleure pour les fichiers longs où beaucoup de lignes ont changé en bloc. |
| git diff --word-diff | Le mode --word-diff de Git met en évidence les changements au niveau mot dans une ligne, plus proche de ce que cet outil fait pour les snippets. Le format de sortie diffère (markup pour terminal vs panneaux côte à côte), mais l'intention se recoupe. Si vous vivez dans le terminal, --word-diff est l'équivalent local. |
| Seuils de fichiers volumineux | Les diffs en navigateur restent réactifs jusqu'à quelques milliers de lignes par côté. Au-delà, le nettoyage sémantique ralentit et le DOM rendu devient lourd. Pour les fichiers énormes, lancez git diff localement et envoyez-le dans un pager, ou découpez la comparaison en sections plus petites. |
| Encodage (UTF-8 uniquement) | Le diff suppose une entrée UTF-8, ce qui couvre presque tout le code source en 2026. Les fichiers sauvés en UTF-16, Windows-1252 ou Shift-JIS peuvent apparaître en mojibake au collage selon votre navigateur. Si un snippet a l'air brouillé, ré-enregistrez le fichier source en UTF-8 avant de copier. |
Le git diff local compare deux refs (commits, branches, working tree) dans un repo réel. Il connaît votre index, votre worktree et votre historique. Cet outil en ligne ne fait rien de tout ça. Il compare deux blocs arbitraires de texte que vous collez. Utilisez git diff pour le travail de revue réel sur un repo cloné. Utilisez ceci quand vous avez deux snippets et aucun moyen pratique de les poser dans un working tree, ou quand vous voulez une vue côte à côte sans changer de contexte.
Pas exactement. GitHub et GitLab utilisent un unified diff par lignes avec contexte de fichier, en-têtes de hunk et résumés par fichier. Cet outil utilise un diff caractère avec nettoyage sémantique, meilleur pour les snippets courts et moins bon pour comparer des fichiers entiers avec beaucoup de changements. Pour une vraie revue de pull request, allez sur la vue PR de GitHub. Pour une comparaison rapide hors PR, ceci est plus rapide et n'oblige pas à naviguer jusqu'au bon repo.
Non. C'est un diff de texte brut. Il ne parse pas le langage, donc il ne peut pas savoir qu'une variable renommée est le même identifiant à 12 endroits, et il ne peut pas ignorer les espaces reformatés comme le ferait un diff syntaxique. Pour la plupart des revues de snippet ça suffit, parce que vous lisez les surlignages avec votre propre cerveau. Si vous voulez du diff sémantique vrai pour le code, votre IDE (VS Code, IntelliJ) ou un diff basé sur tree-sitter est le bon outil. Cette page optimise la vitesse, pas le parsing profond.
La commande Unix classique diff -u produit un patch au format unifié (le même format que Git utilise en interne). Elle est par lignes et conçue pour être lisible par machine, pour pouvoir appliquer le patch ailleurs. Cet outil est lisible par l'humain. Il montre deux panneaux côte à côte avec surlignage en ligne, plutôt qu'une seule colonne de lignes plus et moins. Il ne produit pas de fichier patch applicable avec git apply ou patch -p1. Si vous devez générer un patch, passez en ligne de commande. Si vous devez lire un diff, ceci est plus accueillant.
Oui, mais à sa façon. Les fins de ligne CRLF (Windows) et LF (Unix) apparaîtront comme une différence si les deux snippets collés ne s'accordent pas, parce que techniquement ce sont des octets différents. Pareil pour les espaces en fin de ligne. C'est cohérent avec la façon dont Git traite les fichiers quand core.autocrlf est désactivé. Si seuls les changements de logique vous intéressent, trimmez chaque panneau avant de coller. Nous n'offrons pas encore d'option "ignorer les espaces", c'est sur la roadmap ; git diff -w est l'équivalent local.
En pratique oui. Le diff tourne dans votre navigateur, donc des entrées très grandes (toute une bibliothèque vendorisée ou un fichier généré de 50 000 lignes) ralentiront la page ou bloqueront l'onglet selon la mémoire disponible. Pour la revue de code typique (fonctions, fichiers, scripts de build, configs jusqu'à quelques milliers de lignes par côté), le diff finit pratiquement instantanément. Si vous devez comparer des dépôts entiers, un vrai outil Git ou un comparateur de dossiers est la bonne réponse ; cette page est faite pour les snippets et les fichiers seuls.
Votre code ne quitte jamais votre navigateur. Le diff, le surlignage et le rendu tournent tous sur votre machine. Nous n'uploadons pas le texte, ne le loggons pas et ne le passons à aucun service tiers. Ça compte spécifiquement pour la revue de code propriétaire : coller une fonctionnalité non publiée, un patch de sécurité ou un snippet d'un repo privé dans un service cloud peut déjà violer la politique de traitement des données de votre employeur. Vérifier cette affirmation est simple. Ouvrez les DevTools de votre navigateur, passez à l'onglet Network, collez les deux versions et regardez. Aucune requête sortante au moment de la comparaison. Le même modèle de confidentialité tient sur nos autres outils, dont compare-text, compare-json et compare-yaml. La revue de code marche mieux quand la surface de revue est digne de confiance.