Comparateur de texte (diff)
Comparez deux textes ligne par ligne, avec options ignorer la casse, le whitespace et les lignes vides, plus un diff unifié à copier.
Ce comparateur de texte met deux versions de n'importe quel texte face à face, ligne par ligne, directement dans votre navigateur, donc rien n'est envoyé et rien n'est loggé. Collez un original et une version modifiée, puis cliquez sur Comparer pour voir les lignes supprimées en rouge et les ajoutées en vert, avec les numéros de ligne des deux côtés et un décompte des lignes ajoutées, supprimées ou inchangées. La comparaison utilise un vrai algorithme longest common subsequence, la même famille que le diff Unix d'origine, donc le résultat est exact et pas une approximation floue. Activez ignorer la casse, ignorer le whitespace ou ignorer les lignes vides quand le bruit de formatage noie le vrai changement, pratique pour les configs, les scripts et les dumps SQL. Une fois fini, le bouton Copier le diff unifié vous donne un patch texte brut avec préfixes moins et plus, prêt à coller dans un ticket, un chat ou une code review.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Comparateur de texte (diff) local
Collez deux versions d'un texte et voyez exactement quelles lignes ont changé. J'ai construit cet outil parce que comparer deux configs à l'oeil nu, c'est exactement comme ça que les erreurs survivent à la code review. La comparaison repose sur un vrai algorithme LCS, directement dans votre navigateur. Rien n'est envoyé, rien n'est loggé. Les lignes supprimées passent en rouge, les ajoutées en vert, et vous pouvez copier le résultat en diff unifié brut quand vous avez fini.
Tout tourne en local dans votre navigateur. Cela dit, réfléchissez à deux fois avant de coller des identifiants ou des données clients dans un outil, celui-ci compris.
Comment ce comparateur de texte met deux versions face à face
Un comparateur de texte ne compare pas vos deux textes caractère par caractère. Il découpe d'abord chacun en lignes, puis pose une seule question : quelle est la plus longue suite de lignes qui apparaît, dans le même ordre, dans les deux versions ? C'est la longest common subsequence, LCS pour faire court. Tout ce qui fait partie de cette colonne vertébrale compte comme inchangé. Ce qui reste en plus dans l'original a été supprimé, et ce qui reste en plus dans le nouveau texte a été ajouté. L'idée est simple, mais étonnamment délicate à implémenter proprement.
Cet outil le fait à la façon des manuels. Il construit une table de programmation dynamique où chaque cellule contient la meilleure longueur de correspondance jusque-là, puis remonte la table pour retrouver la séquence réelle d'opérations. Pas d'heuristique, pas de correspondance floue. Si une ligne a bougé du haut du fichier vers le bas, vous la verrez comme une suppression plus un ajout, parce que c'est littéralement ce qui s'est passé du point de vue de l'ordre des lignes. Certains outils plus sophistiqués essaient de détecter les déplacements. Franchement, je trouve la version simple plus facile à croire sur parole.
Un truc à savoir : quand une ligne change légèrement, disons une faute de frappe corrigée, un diff par lignes la signale comme l'ancienne ligne supprimée plus la nouvelle ajoutée. Il ne peut pas dire que ces deux lignes sont identiques à quatre-vingt-quinze pour cent, parce qu'il ne connaît que égal ou pas égal. Le diff au niveau des caractères à l'intérieur des lignes modifiées, c'est un problème à part, plus dur, et la plupart du temps les paires rouge et vert posées côte à côte vous disent déjà tout.
Diff contre git diff
La commande diff classique compare des fichiers sous Unix depuis les années 1970, et son format de sortie unifié (ces lignes préfixées par - et +) est devenu la lingua franca des patchs. git diff parle le même format mais répond à une autre question. Le diff classique compare deux fichiers que vous lui désignez. Git diff compare des instantanés à l'intérieur d'un dépôt : votre working tree contre l'index, un commit contre un autre, une branche contre sa merge base.
Sous le capot, git utilise par défaut l'algorithme de Myers, qui trouve le même genre de script d'édition minimal que le LCS, juste calculé plus efficacement sur de gros volumes. Git embarque aussi des alternatives comme --diff-algorithm=patience et histogram, qui produisent parfois des diffs plus lisibles pour un humain, même quand ils ne sont pas strictement minimaux. Cette page s'en tient à l'approche LCS classique parce que, pour deux textes collés, c'est exact, prévisible et largement assez rapide. Si vous avez besoin de merges à trois voies ou de détection de renommage, c'est le boulot de git, pas celui d'un textarea de navigateur.
Quand ignorer le whitespace
Le bruit de whitespace, c'est la raison numéro un pour laquelle un diff a l'air plus effrayant qu'il ne l'est. L'éditeur d'un collègue supprime les espaces de fin à la sauvegarde, ou quelqu'un réindente un bloc, et d'un coup quarante lignes s'allument alors que le vrai changement tient en deux. Activer l'option whitespace retire les espaces en début et en fin de chaque ligne avant la comparaison, donc une ligne réindentée mais identique par ailleurs compte comme inchangée.
Méfiez-vous quand même. En Python, en YAML et dans les Makefiles, l'indentation EST la logique. Une tabulation de tête ignorée peut masquer exactement le bug que vous traquez. Ma règle : laisser le whitespace significatif au premier passage, et ne basculer l'option que quand le diff se noie clairement dans du bruit de formatage. Ignorer la casse est pratique pour des choses comme les mots-clés SQL ou les noms d'hôtes Windows, où SELECT et select veulent dire la même chose. Ignorer les lignes vides fait ce que ça annonce : les lignes vides (ou composées uniquement de whitespace, quand l'option whitespace est aussi active) sont retirées des deux côtés avant la comparaison.
Confidentialité : votre texte reste sur votre machine
Toute la comparaison se passe en JavaScript, dans l'onglet de votre navigateur. Pas d'upload, pas de traitement côté serveur, pas d'analytics qui lorgne le contenu des textareas. Vous pourriez charger cette page, débrancher votre câble réseau, et l'outil continuerait de fonctionner exactement pareil. J'ai vu des gens coller des configs de prod avec des mots de passe dans des sites de diff en ligne pris au hasard, et ça me fait grincer des dents à chaque fois. Avec celui-ci, le texte ne quitte physiquement jamais la page, mais l'habitude de nettoyer les secrets avant de coller quoi que ce soit où que ce soit reste une bonne habitude à garder.
Questions fréquentes
Cet outil envoie-t-il mon texte quelque part ?
Non. Le diff tourne entièrement dans votre navigateur, en JavaScript pur. Pas d'appel backend, pas de stockage, pas de logs. Fermez l'onglet et le texte disparaît. Si vous êtes sceptique (bon réflexe), ouvrez le panneau réseau de votre navigateur au moment de cliquer sur Comparer et constatez qu'exactement zéro requête ne part.
Quel algorithme la comparaison utilise-t-elle ?
La classique longest common subsequence, calculée avec une table de programmation dynamique sur les lignes des deux textes, puis une passe de backtracking qui transforme la table en opérations ajoutées, supprimées et inchangées. C'est la même famille d'approche que celle sur laquelle le diff Unix d'origine est construit. Exact, pas heuristique.
Pourquoi une ligne modifiée apparaît-elle comme supprimée plus ajoutée ?
Parce que la comparaison travaille au niveau de la ligne. L'outil sait seulement si deux lignes sont identiques ou non, donc une édition d'un seul caractère fait passer l'ancienne ligne en supprimée et la nouvelle en ajoutée. Elles se retrouvent juste à côté l'une de l'autre dans la sortie, ce qui en pratique rend le changement facile à repérer de toute façon.
Je peux comparer du code source avec ça ?
Bien sûr, c'est surtout pour ça que je m'en sers. Collez deux versions d'une config, d'un script, d'un dump SQL, ce que vous voulez. Faites juste attention à l'option ignorer le whitespace dans les langages sensibles à l'indentation comme Python ou YAML, où un indent décalé est un vrai changement et pas juste du bruit.
Je peux exporter le résultat comme patch ?
Le bouton Copier le diff unifié vous donne une version texte brut avec un préfixe moins sur les lignes supprimées, un plus sur les ajoutées et un espace sur les inchangées. C'est volontairement simple : pas de hunk headers, pas de métadonnées de fichier. Très bien pour les tickets, le chat et les reviews, mais pas un truc à donner tel quel à la commande patch.