Comparer deux fichiers JSON

Collez les deux documents JSON dans les deux volets de l’outil « Comparer du JSON », comparez-les, puis lisez la liste des changements qu’il produit — ajouts, suppressions et modifications de valeurs, ordre des clés et espaces ignorés. Tout s’exécute dans votre navigateur ; exportez le résultat sous forme de correctif RFC 6902 quand vous avez besoin d’une trace des différences lisible par une machine.

100 % local

Vous voulez juste l’outil ? Ouvrez Comparer du JSONCompare deux JSON en ignorant l’ordre des clésOuvrir l’outil

Deux documents JSON divergent rarement de façon bruyante. L’un a une clé que l’autre n’a pas, l’un imbrique sa config un niveau plus profond, l’un met un nombre entre guillemets que l’autre laisse nu — et un diff ligne à ligne répond à chacune de ces différences cosmétiques par un mur de rouge. Ce que vous voulez vraiment savoir est plus petit et plus utile : quelles valeurs ont changé, quelles clés sont apparues ou disparues, et si la structure dont vous dépendez a toujours la forme attendue.

Cette page déroule le travail de bout en bout avec l’outil « Comparer du JSON » du site — quatre étapes, chacune accompagnée d’une vérification que vous pouvez effectuer avant de passer à la suivante. Toute la comparaison s’exécute dans votre navigateur : les documents sont analysés en arbres syntaxiques localement et ne quittent jamais l’onglet, c’est pourquoi la même procédure est sûre pour des configs qui contiennent des noms d’hôte, des identifiants déjà renouvelés ou des données clients que vous préférez ne pas coller dans le champ de formulaire d’un inconnu.

Avant de commencer, sachez ce que l’outil vous dira et ne vous dira pas. Il compare les deux documents que vous lui donnez — il ne connaît ni l’historique git, ni les déploiements, ni l’intention. La liste des changements est un fait portant sur deux documents, pas une explication de qui a changé quoi et pourquoi ; les étapes ci-dessous indiquent où chercher quand vous avez besoin de cette seconde moitié de l’histoire.

Chaque étape ci-dessous se déroule dans l’outil « Comparer du JSON » — deux volets, une action de comparaison et une liste des changements qui ignore tout ce qui est cosmétique.

Si le vocabulaire des objets, des tableaux et des clés est nouveau, le guide sur ce qu’est JSON couvre ce vocabulaire en langage clair avant que vous ne compariez quoi que ce soit.

Les étapes

Ouvrez l’outil et chargez le premier document
Ouvrez l’outil « Comparer du JSON » et placez le premier document dans le volet de gauche. Vous pouvez le coller, déposer le fichier sur le volet, ou charger l’exemple intégré si vous préférez répéter d’abord sur des données d’exemple. Les fichiers sont lus par le navigateur lui-même — il n’y a aucune étape d’envoi dans cette procédure, à aucun moment.
Vérifiez : Le volet de gauche accepte le document sans erreur d’analyse, ce qui signifie que le JSON était assez valide pour être comparé. Une erreur d’analyse à cet endroit, c’est l’outil qui vous dit quelle ligne corriger avant que quoi que ce soit d’autre ne fonctionne.
Chargez le second document à droite
Placez le second document dans le volet de droite de la même façon. L’ordre compte pour la désignation, pas pour la justesse : la gauche est la référence et la droite est la version comparée à elle, et le bouton « Intervertir » échange leurs places si vous avez choisi le mauvais sens. Une fois les deux côtés chargés, la comparaison peut s’exécuter.
Vérifiez : Les deux volets contiennent un document plutôt qu’une erreur. Si un seul s’analyse, la comparaison ne peut pas démarrer — corrigez d’abord le côté fautif plutôt que de comparer un document contre rien.
Comparez et lisez la liste des changements
Lancez la comparaison. Le résultat est une liste de différences réelles : des clés ajoutées d’un côté, des clés retirées de l’autre, et des valeurs qui ont changé sous un chemin de clés inchangé. L’ordre des clés et les espaces sont délibérément ignorés — {"a":1,"b":2} et {"b":2,"a":1} sont le même document ici, et le dire est tout l’intérêt d’un diff sémantique. Utilisez Alt+↑ et Alt+↓ pour parcourir la liste sans aller chercher la souris.
Vérifiez : Un changement dont vous savez qu’il existe (renommez une valeur exprès avant de comparer, si vous voulez une répétition générale) apparaît comme exactement une ligne, pas comme une réécriture de toutes les lignes autour. C’est le signal que vous lisez la sémantique, pas le texte.
Exportez les différences en correctif
Quand la liste est juste, exportez-la en JSON Patch RFC 6902 — un petit document ordonné qui dit add, remove et replace pour chaque changement. Le correctif est ce qui transforme une session de lecture en trace : remettez-le à un collègue, joignez-le à un ticket, ou appliquez-le au document de gauche ailleurs pour reproduire exactement le côté droit.
Vérifiez : Le correctif exporté est lui-même un JSON valide et nettement plus petit que l’un ou l’autre document. L’appliquer à une copie du document de gauche devrait produire celui de droite.

Ce qu’un diff sémantique ignore volontairement

L’outil analyse les deux documents en arbres et compare les arbres, si bien que trois sortes de différence n’arrivent jamais dans la liste des changements. L’ordre des clés : un objet est une correspondance, pas une séquence, et aucun consommateur ne donne de sens à l’ordre dans lequel ses clés sont écrites. Les espaces insignifiants : indentation et espacement relèvent de la présentation, et reformater un côté ne devrait produire aucun changement. L’écriture d’un nombre à valeur égale : 1 et 1.0 désignent le même nombre dans les comparaisons qui comptent.

Ce qui atteint la liste, c’est tout ce qui change ce que le document veut dire : une valeur modifiée, une clé apparue ou disparue, un changement de type — la chaîne « 42 » qui devient le nombre 42 est un vrai changement, et l’outil le classe comme tel au lieu de l’accepter en silence. Si un changement auquel vous vous attendiez manque, la première question honnête est de savoir s’il faisait partie des trois cas cosmétiques.

Tableaux : correspondance par position ou par clé

Les tableaux sont le seul endroit où un diff sémantique doit faire un choix, car ["a","b"] face à ["b","a"] peut se lire de deux façons : tout a bougé, ou rien n’a changé et l’ordre porte du sens. L’outil vous laisse décider — la correspondance par index traite le tableau comme une séquence, tandis que la correspondance par un champ de clé primaire aligne les éléments par identité, comme le ferait une base de données.

Pour les listes d’enregistrements (utilisateurs, hôtes, événements), la correspondance par clé est presque toujours ce que vous voulez : insérer un nouvel enregistrement en tête ne produit alors qu’un seul ajout au lieu de secouer chaque ligne. Pour les listes où l’ordre est le sens — les étapes d’une procédure, des résultats classés — la correspondance par index est le choix honnête. Faites-le délibérément plutôt que de laisser le réglage par défaut décider à votre place.

Les gros fichiers et l’endroit où le travail s’exécute vraiment

La comparaison s’exécute dans un Web Worker, en dehors du thread principal de la page, avec un plafond de 100 MB par document. La conséquence pratique : une grosse paire prend de vraies secondes à comparer — mais l’onglet reste vivant pendant le travail, et vous pouvez continuer à faire défiler la liste des changements déjà affichée au lieu de regarder une page figée.

Le mode de fusion à trois — où un document de base rejoint deux branches modifiées — calcule dans la page elle-même et s’arrête à 8 MB pour cette raison. Si vos entrées de fusion sont plus grosses que cela, la comparaison à deux documents décrite ci-dessus reste disponible à pleine taille.

Quand un diff JSON est le mauvais instrument

Deux documents dans des formats différents — une config JSON et sa traduction YAML — exigent d’en convertir un d’abord, sinon le diff dépensera toutes ses lignes à dire que les conteneurs diffèrent. Convertissez un côté dans le format de l’autre, puis comparez. Et quand la question n’est pas structurée du tout — deux fichiers de log, deux paragraphes de prose — la comparaison de texte brut est le bon outil, et la machinerie JSON n’apporte que du bruit.

La réciproque vaut aussi : si vous vous surprenez à lire une liste de changements en racontant l’intention à voix haute — « c’est ici qu’ils ont déplacé le timeout » — le diff a fait son travail et une trace du changement a sa place quelque part de structuré. L’export RFC 6902 existe précisément pour que la session de lecture se termine par un artefact plutôt que par un souvenir.

Questions fréquentes

Mes fichiers JSON sont-ils envoyés quand je les compare ici ?

Non. Les deux documents sont analysés et comparés dans votre onglet — le moteur de comparaison s’exécute dans un Web Worker sur votre machine, et il n’existe aucun endpoint d’envoi vers lequel les transmettre. Vous pouvez le confirmer dans DevTools : ouvrez le panneau Network, lancez une comparaison, et aucune requête ne transporte vos données. La Content-Security-Policy de la page refuse de surcroît les connexions sortantes par construction.

Pourquoi le réordonnancement des clés n’apparaît-il pas comme une différence ?

Parce qu’un objet est une correspondance, pas une liste ordonnée — {"a":1,"b":2} et {"b":2,"a":1} portent exactement la même information, et chaque analyseur JSON construit le même arbre à partir des deux. Un diff qui signale un réordonnancement de clés signale en réalité du formatage, ce qui est du bruit pour le lecteur qui veut savoir ce qui a changé sémantiquement. Les espaces sont ignorés pour la même raison.

Qu’est-ce qu’un correctif RFC 6902 et pourquoi en exporter un ?

RFC 6902 définit JSON Patch : un document JSON qui énumère des opérations — add, remove, replace, move, copy, test — chacune pointant vers un chemin précis. Exporter votre comparaison sous cette forme transforme la liste des changements en trace applicable par une machine : le même correctif appliqué au document de gauche reproduit le côté droit, ce qui en fait une passation précise pour un collègue, un jeu d’essai ou un script de migration.

Quelle taille peuvent avoir les deux fichiers JSON ?

Jusqu’à 100 MB par document. L’analyse et la comparaison s’exécutent dans un Web Worker, donc une grosse paire prend un vrai temps mais ne fige pas l’onglet — l’interface reste réactive et les lignes déjà affichées restent défilables pendant que le worker travaille. Le mode de fusion à trois, séparé, a son propre plafond, plus bas, de 8 MB, parce que ce calcul s’exécute sur le thread principal de la page.

Peut-il comparer des tableaux sans traiter chaque ligne comme modifiée ?

Oui — c’est le réglage de correspondance des tableaux. La correspondance par index compare l’élément 0 à l’élément 0 et est juste quand l’ordre porte du sens. La correspondance par clé aligne les éléments sur un champ de votre choix (un id, un slug, un nom d’hôte) et convient aux listes d’enregistrements, où insérer une nouvelle ligne devrait produire un seul changement, pas une réécriture de la liste. Le réglage existe parce qu’aucune des deux réponses n’est correcte pour tous les tableaux.

Le diff me dit-il quel changement est arrivé en premier, ou qui l’a fait ?

Non — et aucun diff ne le peut. Une comparaison voit deux documents, pas une chronologie : elle sait qu’une valeur a changé, et elle ne peut pas savoir quand, par qui, ni pourquoi. Cette histoire vit dans le contrôle de versions, les logs de déploiement, ou le processus qui a modifié le fichier. L’export du correctif est le pont : joignez-le au ticket ou au commit où l’histoire se raconte.

Équipe ToolsByUs · Comment nous vérifions nos outils