Formateur JSON en Ligne

Le JSON brut est souvent compact et illisible. Un formateur (prettifier) ajoute des indentations et sauts de ligne pour rendre le JSON explorable et compréhensible. C'est un outil quotidien pour les développeurs travaillant avec des API et des bases de données.

Le JSON (JavaScript Object Notation) est le format de données le plus utilisé sur le web. Les API retournent souvent du JSON « minifié » (compact, sans espaces) pour réduire la bande passante. Le formatage (ou « pretty print ») ajoute des indentations, des sauts de ligne et aligne les accolades pour rendre la structure lisible. Notre outil valide aussi la syntaxe et signale les erreurs.

Les erreurs de syntaxe que le validateur signale le plus souvent

Presque toutes les erreurs de JSON viennent de la même confusion : le JSON ressemble à un objet JavaScript, mais il obéit à des règles nettement plus strictes. La virgule finale arrive en tête. Ajouter une virgule après le dernier élément d'un tableau ou d'un objet est autorisé en JavaScript moderne, et pratique quand on édite du code. Le JSON l'interdit sans exception. C'est l'erreur numéro un, et elle survient typiquement après avoir supprimé la dernière ligne d'une liste. Viennent ensuite les guillemets. Le JSON n'accepte que les guillemets doubles, jamais les simples, et cela vaut aussi pour les noms de clés, qui doivent obligatoirement être entre guillemets. Un objet JavaScript parfaitement valide avec des clés nues devient invalide dès qu'on le colle comme JSON. Les commentaires ne sont pas davantage autorisés. Ni les doubles barres obliques, ni les blocs. C'est un choix délibéré du format, régulièrement contesté, et la raison pour laquelle des variantes comme JSONC existent pour les fichiers de configuration. Enfin, certaines valeurs numériques n'ont pas de représentation. Les valeurs non numériques et les infinis, qui existent en JavaScript, n'ont pas d'équivalent en JSON : sérialiser un calcul qui a débordé produit soit une erreur, soit une valeur nulle selon l'implémentation. De même, un nombre ne peut pas commencer par un zéro superflu ni par un signe plus. Une astuce de lecture : quand un validateur signale une erreur à une position donnée, la faute se situe presque toujours juste avant, pas à l'endroit indiqué. L'analyseur ne détecte le problème qu'au moment où il rencontre un caractère qu'il n'attendait pas.

Minifier ou indenter : ce que ça change vraiment

Un formateur propose les deux opérations inverses, et le choix entre elles est moins évident qu'il n'y paraît. Indenter ajoute des espaces et des retours à la ligne pour rendre la structure visible. C'est indispensable pour lire, comparer deux versions ou repérer une imbrication de trop. La convention la plus répandue est de deux espaces par niveau ; quatre se rencontre aussi, la tabulation plus rarement. Minifier supprime tout ce qui n'est pas signifiant. Sur un document richement imbriqué, la réduction atteint couramment 20 à 30 % du poids brut, ce qui paraît considérable. Sauf que ce calcul ignore la compression. Les échanges HTTP sont compressés en gzip ou en brotli, et ces algorithmes excellent précisément sur les répétitions — or l'indentation n'est qu'une longue suite d'espaces identiques. Une fois compressé, l'écart entre un JSON indenté et le même minifié tombe souvent sous les 5 %. L'optimisation est donc réelle, mais bien plus modeste que le gain brut ne le laisse croire. La règle pratique qui en découle : minifiez ce qui transite et ce qui est stocké en masse, indentez ce qui est lu par un humain ou versionné. Sur un fichier de configuration suivi en gestion de version, l'indentation a même un avantage décisif : un document minifié tient sur une seule ligne, et le moindre changement produit alors une différence illisible où l'outil de comparaison signale que toute la ligne a changé.

Pourquoi votre JSON est valide mais refusé par l'API

Un document peut passer le validateur et être rejeté à l'autre bout. Les causes se situent alors en dehors de la syntaxe. La plus fréquente est la marque d'ordre des octets. Certains éditeurs sous Windows placent trois octets invisibles en tête de fichier pour signaler l'encodage UTF-8. Le JSON n'autorise aucun caractère avant l'accolade ouvrante : de nombreux analyseurs échouent alors sur une erreur déroutante, signalant un caractère inattendu en position zéro alors que le fichier paraît commencer normalement. Vient ensuite le problème des clés en double. La spécification ne dit pas ce qu'il faut en faire ; en pratique la plupart des analyseurs conservent la dernière valeur et ignorent silencieusement les précédentes. Un document contenant deux fois la même clé est donc accepté partout, mais avec un contenu qui dépend de l'implémentation. C'est une source de bugs particulièrement pénible car rien ne signale l'anomalie. La précision des nombres constitue le troisième cas. La spécification n'impose aucune limite, mais les environnements qui consomment le document stockent généralement les nombres en virgule flottante double précision. Un identifiant de plus de seize chiffres est alors relu avec ses derniers chiffres modifiés. Le remède est de transporter ces valeurs en chaîne de caractères, ce que font la plupart des grandes API pour leurs identifiants. Enfin, l'ordre des clés n'est pas garanti. Un objet JSON est un ensemble non ordonné : rien n'oblige un analyseur à restituer les propriétés dans l'ordre du document. Le formatage peut donc légitimement les réordonner, et un système qui dépendrait de cet ordre serait fragile par construction. Si l'ordre compte, c'est un tableau qu'il faut utiliser, pas un objet.

• Utilisez JSON.stringify(obj, null, 2) en JavaScript pour un formatage avec 2 espaces
• Notre outil détecte et signale les erreurs de syntaxe avec la position exacte
• Pour minifier : JSON.stringify(obj) sans les paramètres d'indentation

Questions supplémentaires