JSON : mise en forme, validation et réparation de ce qui est cassé
Collez une réponse d'API, une configuration ou un extrait de journal — vous obtenez une vue lisible, une arborescence et la liste de tout ce qui s'écarte de la norme, avec la ligne et la position exactes. Tout est analysé dans votre navigateur : les données ne sont envoyées nulle part et ne sont jamais conservées.
.json — il est lu localement. Vous pouvez aussi coller ce qui n'est pas encore du JSON valide : un journal, une réponse d'API avec commentaires, un fragment avec des virgules finales.
Les clés et leur ordre sont conservés, l'écriture des nombres n'a pas changé.
Collez du JSON ci-dessus et appuyez sur « Traiter ».
Collez du JSON ci-dessus et appuyez sur « Traiter ».
Les données ne quittent pas votre navigateur : l'analyse et la mise en forme s'exécutent localement, sans rien envoyer à un serveur.
Quatre éditions de la norme et ce qui les distingue
JSON est décrit par plusieurs documents, et ils ne sont pas identiques. Le choix de la spécification change ce que l'outil considère comme une erreur. RFC 4627 (2006) — la première. Un document de premier niveau ne peut être qu'un objet ou un tableau ; un nombre ou une chaîne isolés sont interdits. Certaines vieilles bibliothèques s'appuient encore sur cette édition. RFC 7159 (2014) — a autorisé n'importe quelle valeur au premier niveau. Depuis, 42 et « texte » sont des documents JSON à part entière. RFC 8259 (2017) — celle en vigueur. Elle a ajouté l'exigence d'UTF-8 pour les échanges entre systèmes et a établi que les noms d'un même objet doivent être uniques. ECMA-404 — ne décrit que la syntaxe. Elle n'interdit pas les clés en double et ne mentionne pas les demi-substituts isolés : l'ensemble des avertissements y est donc le plus court. En cas de doute, restez sur la RFC 8259 : c'est le plus strict des jeux de règles en vigueur, et ce qui y passe sera accepté partout.
Pourquoi une analyse maison plutôt que le JSON.parse du navigateur
L'analyseur intégré est fait pour la vitesse, pas pour le diagnostic. Sur les mêmes données, il se tait là où un outil devrait parler : Un message sans coordonnées. Le navigateur dit « Unexpected token » et un décalage en caractères ; ici, vous avez la ligne, la position et ce qui était précisément attendu. Une seule erreur pour tout le document. Après le premier échec, l'analyse se rétablit et montre les suivantes au lieu de vous forcer à corriger une par une. Les clés en double passent en silence. JSON.parse garde la dernière valeur, et la perte se remarque en production. L'écriture des nombres se perd. 1.0 devient 1, et un entier supérieur à neuf millions de milliards change ses derniers chiffres — c'est exactement ainsi que se cassent les identifiants venus d'une base. L'ordre des clés en sortie reste celui de la source tant que vous ne demandez pas vous-même un tri. Ici, les nombres sont par défaut restitués tels qu'ils étaient écrits : l'outil montre le document, pas le résultat de son interprétation.
Ce que le mode correction répare exactement
Les données réelles sont rarement du JSON propre. Le mode réparation ramène à la norme ce qui arrive des configurations, des journaux et des API des autres : les commentaires // et /* */ sont supprimés ; les virgules devant une accolade ou un crochet fermant sont retirées ; les guillemets simples et typographiques sont ramenés à des guillemets doubles ; les clés sans guillemets et les clés numériques sont mises entre guillemets ; True, NULL, None, undefined deviennent true, false, null ; NaN et Infinity deviennent null, car JSON n'a pas de nombres sans valeur finie ; l'écriture des nombres : plus superflu, point en bordure, zéros initiaux ; les caractères de contrôle dans les chaînes sont échappés ; le BOM en début de fichier et l'enveloppe JSONP sont retirés. Aucune correction n'est faite en silence : chacune figure dans la liste avec son nombre d'occurrences. Si le résultat ne vous convient pas, décochez la case et le document est vérifié tel quel.