Formateur JSON, requête et diff

Formatez, interrogez et comparez du JSON en local dans votre navigateur.

Ce formateur JSON parse votre payload directement dans le navigateur et en fait toute la boucle de debug, pas seulement une jolie indentation. Embellissez, minifiez ou triez les clés, puis allez chercher une valeur enfouie six niveaux plus bas avec un sélecteur JSONPath-lite comme $.items[*].id. Explorez chaque scalar path avec son type, lisez des hints de forme façon schéma, et comparez un document au payload qui marchait hier pour attraper les valeurs feuilles qui ont changé, ont été ajoutées ou ont discrètement disparu. La validation vient d'abord, alors une erreur de parsing pointe vers les trailing commas, les single quotes, les clés non quotées ou les commentaires égarés avant que vous perdiez du temps. Copiez ou téléchargez la version dont vous avez vraiment besoin. Rien ne quitte jamais la page.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Atelier local de formatage, requête et diff JSON

Collez votre JSON. Il est parsé ici même, dans votre navigateur. J'ai construit ça pour le bazar avec lequel je me bats le plus souvent : l'embellir ou le minifier, trier les clés, aller chercher une valeur enfouie six niveaux plus bas avec un sélecteur JSONPath-lite, puis le comparer au payload qui marchait hier. Rien n'est envoyé nulle part. Ça, franchement, c'est important pour moi.

JSON en entrée

Requête JSONPath-lite

Sortie

Indentation

JSON à comparer (optionnel)

Tout tourne dans votre navigateur. Mais réfléchissez quand même. Ne collez pas de vrais secrets dans un outil en ligne, quel qu'il soit, à moins d'être certain que c'est bien là que ces données ont leur place.

Un formateur JSON est surtout utile quand il vous aide à déboguer

Un formateur JSON gagne sa place quand il vous aide à déboguer, pas quand il se contente d'ajouter des espaces. La jolie indentation, c'est la partie facile. La partie difficile arrive quand une réponse d'API ou le corps d'un webhook atterrit devant vous et que vous devez comprendre pourquoi ça a cassé. Est-ce valide ? Où est ce champ, celui qui est enfoui six niveaux plus bas ? Correspond-il encore à la version qui marchait hier ? Un outil qui se contente d'ajouter des espaces vous laisse scroller à l'infini, à la recherche de ce qui a changé, et ça, j'en ai eu marre il y a des années.

Alors j'ai casé toute la boucle de debug au même endroit. Il parse en local. Il vous rend la sortie embellie, ou minifiée, ou avec toutes les clés triées, compte ce qu'il y a dedans, construit un path explorer, et lance une requête rapide comme $.tools[0].status ou $.items[*].id pour quand vous connaissez le nom du champ mais pas l'endroit où il se cache. Des hints de type façon schéma, un diff des scalar paths entre deux documents, c'est dedans aussi. Et oui, des boutons copier et télécharger. Parce qu'une fois la réponse trouvée, elle ne reste presque jamais en place. Elle repart direct dans votre code ou dans un ticket.

Comment lire un payload JSON avant de le modifier

Commencez par vérifier qu'il parse, tout simplement. Honnêtement ? L'erreur du parser vous en dit plus en deux secondes que plisser les yeux sur du texte brut en deux minutes. Les coupables habituels : les trailing commas, les single quotes, les clés non quotées, les commentaires que quelqu'un a collés tels quels depuis du JavaScript, plus le undefined ou le NaN occasionnel qui a fuité d'un sérialiseur qui aurait dû savoir mieux faire. Une fois que ça parse, regardez la forme. L'imbrication vous dit jusqu'où va ce terrier de lapin. Les scalar paths vous montrent les valeurs qui bougent réellement d'une réponse à l'autre, et quand vous connaissez le champ mais que vous n'arrivez pas à le trouver, une requête ciblée vous épargne les yeux.

Sortie formatée vous rend du JSON lisible, ou du JSON minifié bien serré. Vous voulez un ordre stable ? Il trie chaque clé récursivement.
Résultat de requête parcourt les dot keys et les bracket indexes, plus les wildcards sur lesquels je m'appuie le plus.
Explorateur de paths déroule chaque scalaire avec son path complet et son type, pour que rien ne se cache.
Hints de schéma esquissent les types d'objets et de tableaux, pratique quand j'écris de la doc ou que je crayonne une validation.
Diff attrape les valeurs feuilles qui ont changé, qui ont été ajoutées, ou qui ont discrètement disparu entre deux payloads.

Vérifications JSON pratiques pour les API et les configs

Un webhook soudain mort ? Comparez le payload qui a échoué avec un qui est passé, avant de commencer à tripoter l'endpoint. C'est peut-être juste ma veine, mais neuf fois sur dix la réponse est là, posée pile dans le diff. Un fichier de config qui se fait rejeter ? Validez d'abord le JSON brut, avant de trier ou de minifier, sinon vous allez enterrer en silence l'erreur même que vous traquez. La doc vague comme d'habitude ? Interrogez la seule branche qui vous intéresse et vérifiez son type réel au lieu de faire confiance au README. Et quand une valeur doit obéir à de vraies règles métier, là on est dans le domaine du JSON Schema ou de la validation applicative. Ici, c'est la passe exploratoire rapide qui vient en premier.

Notes sur la confidentialité et le workflow

Tout faire tourner dans le navigateur, c'est pratique. Ça ne vous rend pas à l'épreuve des étourderies pour autant. Retirez les tokens et les fiches clients avant de faire une capture d'écran ou de balancer un payload dans un chat. J'ai vu un access token rester dans un fil Slack pendant des mois parce que quelqu'un avait oublié qu'il était là. Gardez une copie brute pendant que vous traquez une erreur de parsing ; vous voudrez récupérer l'original, croyez-moi. Triez les clés quand vous comparez la forme. Ne le faites pas quand l'ordre lui-même veut dire quelque chose pour celui qui le lira ensuite. Et une fois qu'un fichier devient vraiment énorme et que le navigateur commence à ramer, ouvrez-le dans un éditeur local ou passez-le dans un parser CLI.

Questions fréquentes

Est-ce du JSONPath complet ?

Non. Et je n'ai pas non plus cherché à en faire un. Vous avez la partie vers laquelle je reviens vraiment au quotidien : le marqueur racine, les dot keys, les bracket indexes, les wildcards pour parcourir les choses. À la seconde où vous avez besoin de filters, de recursive descent ou d'une compatibilité stricte avec la spec, allez chercher une vraie bibliothèque JSONPath. C'est le bon outil pour ça, pas ce petit truc.

Le formatage répare-t-il du JSON invalide ?

Non. Volontairement. Il vous dira ce qui a cassé et pointera vers les suspects habituels, mais il n'ira pas réparer vos données en douce dans votre dos. L'auto-repair a l'air charmant jusqu'au moment exact où il devine de travers et change discrètement le sens de votre payload. Je préfère que vous corrigiez la source vous-même, en connaissance de cause, en sachant exactement ce que vous avez touché.

Quelle est la différence entre valider et formater du JSON ?

Deux jobs différents, et les gens les confondent sans arrêt. La validation pose une seule question : la syntaxe est-elle légale ? Le formatage prend du JSON déjà valide et le ré-indente pour qu'un humain puisse réellement lire le truc. Tout formateur qui mérite qu'on l'utilise valide d'abord, puis vous montre exactement où il a calé quand le JSON est cassé. Sautez cette étape et vous ne faites que réarranger des déchets en déchets plus propres.

Pourquoi mon JSON échoue avec une erreur unexpected token ?

Je parierais sur l'une de quatre choses. Une trailing comma avant une accolade fermante. Des single quotes là où il faut des double quotes. Une clé qui a oublié ses guillemets. Ou un commentaire que vous avez copié depuis du JavaScript. Le JSON strict ne tolère rien de tout ça, même si chacun de ces cas a l'air parfaitement correct en JS. Et ce décalage ? Il fait trébucher les gens encore et encore.