Colle, formate et compare deux extraits JSON côte à côte. Validation, mise en forme et minification incluses.
Un outil gratuit, dans le navigateur, pour comparer deux documents JSON. Colle l'ancienne version à gauche, la nouvelle à droite, et les différences s'allument caractère par caractère. Rien ne quitte ta machine.
On utilise le JSON.parse natif de ton navigateur pour la validation. Il y a un bouton Formater quand ton JSON arrive sur une seule ligne minifiée géante, un bouton Minifier pour le cas inverse, et une validation en direct qui signale les erreurs de syntaxe au fur et à mesure.
Si tu as déjà fixé un diff openapi.json de 6 000 lignes dans une PR GitHub en cherchant le seul champ qui a cassé un client downstream, c'est l'outil qui t'amène là en quelques secondes.
Le diff se fait au niveau du caractère, puis nettoyé par un post-traitement sémantique pour que les surlignages tombent sur des morceaux qui ont du sens et pas sur des caractères au hasard. Les ajouts apparaissent en vert dans le panneau de droite, les suppressions en rouge dans celui de gauche.
JSON a ses propres bizarreries pointées par la spec. La spécification JSON dans RFC 8259 définit les objets comme non ordonnés, donc réordonner les clés ne change rien techniquement même si un diff texte va le signaler. On gère ça avec un bouton Formater de chaque côté : formate les deux, puis compare, et l'ordre devient cohérent. Pour du travail structurel plus poussé, regarde JSON Patch (RFC 6902) ou le plus simple format JSON Merge Patch (RFC 7396), qui sont les deux façons standard de décrire un changement JSON sous forme de données.
Quand l'ordre compte pour du hashing ou de la signature, la spec à connaître c'est RFC 8785 (JSON Canonicalization Scheme). Trie les clés, normalise le format des nombres, puis fais le diff.
Deux panneaux de texte, un diff. Pas d'inscription, pas d'upload, pas d'aller-retour serveur.
Colle l'ancien JSON à gauche, le nouveau à droite. Ou clique sur Téléverser de chaque côté pour charger directement un fichier .json. Le bouton Exemple remplit les deux panneaux avec un petit cas si tu veux d'abord voir l'outil en action.
Clique sur Formater sur chaque panneau pour mettre en forme avec une indentation de deux espaces. Ça normalise les espaces et les sauts de ligne, donc le diff met en avant les vrais changements de données, pas les différences de mise en forme. Le badge de validation passe au vert quand ton JSON parse correctement.
Les suppressions apparaissent surlignées en rouge à gauche, les ajouts en vert à droite. Scrolle d'un côté et l'autre suit. Les compteurs de changements dans chaque en-tête t'indiquent combien de modifications distinctes le diff a trouvées.
Colle la sortie actuelle de aws iam get-policy-version contre le JSON proposé pour voir exactement quelles entrées Action ont été ajoutées, ou si quelqu'un a glissé "Resource": "*" dans une instruction qui était auparavant spécifique. La console AWS réordonne les statements à la sauvegarde, ce qui rend un diff GitHub trompeur ; formate les deux côtés ici et le vrai changement saute aux yeux.
Quand terraform show -json tfplan renvoie un blob de 4 Mo, le lire à l'œil est sans espoir. Compare le plan d'aujourd'hui à celui d'hier pour faire remonter le aws_security_group_rule que quelqu'un a ajouté sous une PR de refactor ou le bloc lifecycle.ignore_changes qui a discrètement disparu.
Un diff openapi.json de 6 000 lignes est illisible quand un générateur de code réordonne les paths par ordre alphabétique. Formate les deux côtés, compare, et le vrai changement remonte : un champ required ajouté à CreateOrderRequest, ou une réponse 200 dont le schéma est passé en silence de string à string | null.
Après avoir résolu un conflit sur package-lock.json, compare ton fichier résolu contre le lockfile de main pour attraper un downgrade transitif. npm résout parfois le même range semver à des versions exactes différentes selon les machines, et c'est la vraie cause de "ça marche chez moi, ça casse en CI". Lis la doc de package-lock.json pour ce que chaque champ veut dire.
Récupère GET /my-index/_mapping de staging et de prod, balance les deux dans le diff. La prod peut encore avoir "type": "text" sur un champ que la staging a migré en "keyword" au sprint dernier, et c'est pour ça que la requête d'agrégation ne renvoie rien en prod et marche en local. Les mappings sont imbriqués sur cinq ou six niveaux et un diff texte enterre ça dans le bruit.
Quand un test Playwright passe en local et casse en CI, capture le corps JSON de la réponse que le test a réellement vu et compare-le à la fixture dans ton repo. Souvent c'est un timestamp createdAt ou un champ traceId que personne n'a figé, et le diff structurel rend la clé fautive évidente au lieu de te balancer dans un mur de texte formaté.
Un petit mémo sur les cas limites de parsing que cet outil fait remonter le plus souvent. Tout est ancré dans la spécification JSON.
| Topic | What this tool does |
|---|---|
| Ordre des clés d'objet | Non ordonné selon la spec. {"a":1,"b":2} est égal à {"b":2,"a":1}. Utilise Trier les clés pour normaliser avant de comparer. |
| Ordre du tableau | Ordonné. [1,2,3] n'est pas égal à [3,2,1]. Trie manuellement si l'ordre n'a pas d'importance pour ton cas. |
| Virgules finales | Non autorisées. { "a": 1, } est une erreur de parsing en JSON standard. Autorisées en JSON5/JSONC qui sont des sur-ensembles : retire-les d'abord. |
| Commentaires | Non autorisés. // comme ça est une erreur de parsing. JSON5 et JSONC les acceptent ; cet outil suit la grammaire stricte de RFC 8259. |
| Nombres | Parsés comme floats IEEE 754 64 bits. 0.1 + 0.2 = 0.30000000000000004. Les entiers au-dessus de 2^53 − 1 perdent en précision ; stocke les IDs snowflake en string. |
| Clés en double | La spec les classe en comportement indéfini. La plupart des parseurs gardent la dernière occurrence. Le diff te les montre toutes, ce qui est en général ce que tu veux quand tu audites des fichiers de config. |
| Encodage | UTF-8 uniquement. RFC 8259 interdit un BOM UTF-8 en début de document ; certains parseurs l'acceptent quand même, mais la spec non. |
| Null vs absent | Une clé avec la valeur null est présente. Une clé absente ne l'est pas. Différent du undefined de JavaScript, qui n'a pas de représentation JSON. |
Non. Le diff tourne entièrement dans ton navigateur. Rien n'est envoyé sur un serveur, ni loggé, ni stocké. Colle une réponse d'API interne ou une politique IAM puis ferme l'onglet, il ne reste aucune copie. Pour vérifier, ouvre les DevTools, va sur l'onglet Réseau et regarde : il n'y a aucune requête sortante quand tu compares.
Oui, les deux le font. Un diff texte compare les caractères ligne par ligne, donc le reformatage, le réordonnancement des clés ou les changements d'espaces apparaissent comme des différences même si les données sont identiques. Clique sur le bouton Formater dans les deux panneaux d'abord, et le diff se concentre sur les vrais changements de données. Pour une comparaison entièrement structurelle qui ignore l'ordre des clés, trie les clés des deux côtés avant de comparer.
Pour les clés d'objet, non : la spec JSON dit que les objets ne sont pas ordonnés, donc {"a":1,"b":2} et {"b":2,"a":1} représentent les mêmes données. Un diff caractère signalera quand même le réordonnancement, c'est pour ça que le bouton Formater compte. Les tableaux c'est différent : [1,2,3] et [3,2,1] ne sont pas égaux parce que l'ordre du tableau a un sens en JSON.
À cause du virgule flottante IEEE 754. 0.1 + 0.2 vaut en fait 0.30000000000000004, et JSON.parse lit les nombres comme des floats 64 bits. Les grands entiers se cognent à la même limite : tout ce qui dépasse 2^53 - 1 (9007199254740991) perd en précision, donc un ID snowflake style Twitter ne survit pas à un round-trip. Si la précision compte, stocke-les en string.
Le JSON standard n'autorise ni l'un ni l'autre. { "a": 1, } ou // commentaire te donneront une erreur de parsing. Ça c'est du JSON5 ou du JSONC (le format que VS Code utilise pour settings.json), qui est un sur-ensemble. Vire les commentaires et les virgules finales d'abord. On suit la grammaire stricte de RFC 8259 exprès, pour que le diff colle à ce que ton API accepte vraiment.
Jusqu'à quelques Mo c'est très bien, sub-seconde. Au-delà de 10 Mo le navigateur commence à le sentir, surtout parce que c'est le rendu du diff (pas son calcul) qui devient cher. Pour des exports de 50 Mo et plus, filtre les deux côtés sur le sous-arbre qui t'intéresse avec jq d'abord, puis colle ça.
Ton JSON ne quitte jamais ton navigateur. Le parseur, le formatteur et le diff tournent tous sur ta machine, en local. Pas d'analytics sur ce que tu colles, pas de logs, pas d'aller-retour cloud "pratique". Le parsing utilise le JSON.parse natif du navigateur, et la spec JSON qu'on suit c'est RFC 8259.