Formater JSON en ligne

Comment formater du JSON en quatre étapes

1. Collez votre JSON dans la zone JSON à formater.
2. Cliquez sur Formater / Embellir pour l’afficher proprement indenté (2 espaces, 4 espaces ou tabulation), sur Minifier pour retirer les espaces, ou sur Valider pour simplement le vérifier.
3. Si le JSON n’est pas valide, le message indique la ligne et la colonne exactes du problème.
4. Copiez ou téléchargez le résultat.

Formater, valider, minifier : quelle différence ?

Valider consiste à vérifier que votre texte est un JSON bien formé. Formater (ou embellir) réindente un JSON valide pour qu’un humain puisse lire les structures imbriquées. Minifier supprime tous les espaces et retours à la ligne superflus pour que les données soient aussi compactes que possible, ce qui est utile avant de les envoyer sur le réseau ou de les intégrer ailleurs. Aucune de ces opérations ne change le sens de vos données : les clés, les valeurs et les types restent les mêmes et, à quelques nuances près détaillées dans la FAQ (écriture des nombres, clés en double), seuls les espaces diffèrent. L’ordre des clés est conservé tel que vous l’avez écrit, à une exception près, détaillée plus bas : les clés qui sont des entiers.

Causes fréquentes d’un JSON invalide

• Virgule finale — {"a":1,} n’est pas valide : JSON n’accepte aucune virgule après le dernier élément.
• Apostrophes — les chaînes et les clés doivent utiliser des "guillemets doubles", jamais '.
• Clés sans guillemets — {name:"x"} doit s’écrire {"name":"x"}.
• Commentaires — JSON n’accepte ni // ni /* */.
• Littéraux mal écrits — les booléens et la valeur nulle s’écrivent en minuscules (true, false, null) ; les mots-clés propres à JavaScript ne sont pas du JSON valide.
• Crochets ou accolades orphelins — chaque { et chaque [ doit être refermé.

Mes données restent-elles privées ?

Oui. L’outil utilise les fonctions natives JSON.parse et JSON.stringify de votre navigateur : rien n’est envoyé à un serveur, vous pouvez donc coller sans risque des réponses d’API internes, des jetons ou des fichiers de configuration. Il fonctionne même hors ligne une fois la page chargée.

Qu’est-ce que JSON, et d’où vient-il ?

JSON (JavaScript Object Notation) est un format texte léger qui sert à échanger des données structurées. Il a été nommé et popularisé par Douglas Crockford, qui a déposé le domaine json.org en 2002 et y a publié la grammaire. Sa syntaxe reprend les littéraux d’objet et de tableau du langage JavaScript (plus précisément de la norme ECMAScript 3 de 1999), mais JSON lui-même est indépendant de tout langage : il existe des analyseurs et des sérialiseurs pour pratiquement tous les langages de programmation. C’est précisément pour cela qu’il est devenu le moyen habituel pour un navigateur, une application mobile et un serveur — souvent écrits dans trois langages différents — de communiquer entre eux.

JSON a d’abord été décrit dans une spécification de l’IETF, la RFC 4627 (2006). Il a ensuite reçu une grammaire formelle d’un organisme de normalisation avec ECMA-404, en octobre 2013, et la spécification de référence actuelle est la RFC 8259 (2017), également publiée comme norme Internet STD 90. La RFC 8259 a rendu explicite une règle que les textes précédents laissaient floue : un texte JSON échangé entre des systèmes qui ne forment pas un écosystème fermé doit être encodé en UTF-8. Les deux spécifications en vigueur, ECMA-404 et la RFC 8259, décrivent volontairement la même grammaire, et l’Ecma et l’IETF se sont engagés à les mettre à jour ensemble si une différence apparaissait.

Les six types de données JSON

Chaque valeur d’un document JSON appartient à l’un de ces six types seulement — il n’y en a pas d’autre :

• Objet — un ensemble non ordonné de paires "key": value entourées d’accolades. Les clés doivent être des chaînes entre guillemets doubles.
• Tableau — une liste ordonnée de valeurs entourée de crochets. Les valeurs peuvent être de types différents.
• Chaîne — du texte entre guillemets doubles, avec des séquences d’échappement comme \n, \t, \" et \uXXXX.
• Nombre — un nombre décimal comme 42, -3.14 ou 6.022e23, toujours écrit avec un point et jamais avec une virgule. Il n’existe pas de type entier distinct, et NaN, Infinity ainsi que les zéros non significatifs en tête ne sont pas autorisés.
• Booléen — les littéraux en minuscules true ou false.
• Null — le littéral en minuscules null, qui signifie « aucune valeur ».

Un document JSON n’est rien d’autre qu’une valeur de l’un de ces types — le plus souvent un objet ou un tableau au premier niveau, même si la RFC 8259 permet à n’importe quelle valeur (même un simple true ou un nombre seul) de constituer à elle seule un texte JSON complet.

Pourquoi JSON doit être aussi strict

JSON est volontairement un sous-ensemble strict de la syntaxe JavaScript — plus strict encore que les objets que vous écrivez dans le code. Cette rigueur est un atout : une grammaire rigide garantit que tout analyseur conforme lit un document de la même manière, sans ambiguïté. Les règles qui piègent le plus souvent découlent directement de ce choix. Il n’y a pas de commentaires — Crockford les a retirés délibérément pour que personne ne puisse glisser des directives d’analyse dans un fichier de données. Il n’y a pas de virgule finale, car la virgule est un séparateur et ne peut pas suivre le dernier élément. Seuls les guillemets doubles sont admis, pour les clés comme pour les chaînes ; les apostrophes et les clés sans guillemets que JavaScript tolère ne sont pas du JSON valide. Enfin, les mots-clés true, false et null sont sensibles à la casse : True ou NULL provoqueront une erreur.

Le piège des grands nombres

JSON n’impose aucune limite à la taille ni à la précision d’un nombre, mais la plupart des analyseurs — y compris le JSON.parse de votre navigateur — lisent les nombres comme des valeurs à virgule flottante IEEE 754 sur 64 bits. Ce format ne représente exactement les entiers que jusqu’à 2⁵³ − 1 (9007199254740991, exposé en JavaScript sous le nom Number.MAX_SAFE_INTEGER). Un identifiant de base de données sur 64 bits ou un très long jeton numérique au-delà de cette valeur sera arrondi sans avertissement lors de l’analyse. La solution habituelle consiste à transmettre ces valeurs sous forme de chaînes et à ne les convertir que là où un type « grand entier » est disponible. C’est un bogue subtil qu’aucun outil de mise en forme ne peut signaler, cet outil compris, car l’arrondi a lieu dans l’analyseur, avant même que la valeur n’atteigne la page.

JSON, XML et YAML comparés

Avant JSON, XML était le format d’échange dominant. XML est puissant — il gère les attributs, les espaces de noms, les schémas (XSD) et la validation — mais il est verbeux : chaque élément exige une balise ouvrante et une balise fermante, ce qui alourdit les données et le coût d’analyse. JSON exprime les mêmes données avec beaucoup moins de texte et correspond directement aux structures natives (objets, tableaux, dictionnaires, listes) de la plupart des langages, ce qui explique que les API REST l’aient très largement adopté.

YAML est un quasi-surensemble de JSON qui ajoute les commentaires, les ancres et une mise en page fondée sur l’indentation, d’où sa popularité pour les configurations éditées à la main, comme les pipelines d’intégration continue ou les manifestes Kubernetes. La contrepartie : la sensibilité de YAML à l’indentation le rend facile à casser à la main, alors que les accolades et les crochets explicites de JSON ne laissent aucune ambiguïté. Une règle pratique : JSON pour les machines, YAML pour les humains, XML pour les documents au balisage riche et au contenu mixte.

Les cousins plus souples : JSON5, JSONC et NDJSON

Plusieurs extensions assouplissent les règles de JSON pour des usages précis. JSONC (« JSON with Comments ») autorise simplement les commentaires // et /* */ ; c’est le format qu’utilise Visual Studio Code pour ses fichiers de paramètres. JSON5 va plus loin et admet les apostrophes, les clés sans guillemets, les virgules finales et les nombres hexadécimaux, pour rendre les fichiers édités à la main plus tolérants. NDJSON (aussi appelé JSON Lines) stocke un objet JSON indépendant par ligne, ce qui est idéal pour les journaux en flux et les gros jeux de données, car un lecteur peut traiter un enregistrement à la fois sans charger tout le fichier. Aucun de ces formats n’est interchangeable avec le JSON strict : si un serveur attend du JSON conforme à la RFC 8259, les commentaires et les virgules finales seront rejetés, et c’est la cause la plus fréquente d’un contenu qui « a l’air correct » mais refuse d’être analysé.

Où trouve-t-on du JSON ?

Dès qu’on y prête attention, JSON est partout. C’est le format des échanges de la grande majorité des API REST et GraphQL ; le langage de configuration d’innombrables outils (package.json, tsconfig.json, composer.json) ; le format de document natif de bases NoSQL comme MongoDB ; et le contenu de chaque JSON Web Token. Des dialectes spécialisés l’étendent à de nouveaux domaines : GeoJSON décrit des cartes et des formes géographiques, JSON-LD alimente les données structurées que lisent les moteurs de recherche, et JSON Schema décrit et valide la forme d’autres documents JSON. Bien connaître JSON est l’une des compétences les plus rentables du développement logiciel moderne, car le même format revient à tant d’endroits.

Embellir ou minifier ? Tout dépend du lecteur

Le JSON embelli, avec indentation et retours à la ligne, s’adresse à un lecteur : l’humain. Le JSON minifié, débarrassé de tout espace facultatif, s’adresse à un autre : le réseau. Minifiez les données que vous allez transmettre — mais gardez en tête que les réponses HTTP sont presque toujours compressées avec gzip ou Brotli, et que la compression réduit déjà très efficacement les espaces répétés : après compression, l’écart de taille réel est généralement modeste. Le principal gain de la minification est simplement d’avoir moins d’octets à analyser. Tout ce que vous lisez, déboguez, enregistrez dans un gestionnaire de versions ou collez dans un rapport de bogue, embellissez-le d’abord : une structure propre et indentée fait apparaître d’un coup d’œil un crochet manquant ou une valeur mal placée.

Un mot sur JSON et la sécurité

Analyser du JSON est sans danger ; l’évaluer ne l’est pas. Aux débuts, certains développeurs analysaient le JSON en le passant à la fonction eval() de JavaScript, qui exécutait alors tout code caché dans le texte — une faille sérieuse. Utilisez toujours un véritable analyseur comme JSON.parse (celui qu’emploie cet outil), jamais eval. Une subtilité à connaître : dans du JSON non fiable, une clé nommée __proto__ a servi, avec certaines bibliothèques, à des attaques par « pollution de prototype ». Les analyseurs bien maintenus s’en protègent désormais, mais c’est une bonne raison de ne jamais injecter du JSON non fiable directement dans du code sensible qui fusionne des objets.

JSON n’a pas de type date

Beaucoup sont surpris d’apprendre que JSON n’a aucune représentation native pour les dates, les heures ou les données binaires — seulement les six types décrits plus haut. Par une convention quasi universelle, les dates circulent sous forme de chaînes ISO 8601 comme "2026-06-30T14:00:00Z", et les données binaires sous forme de chaînes encodées en Base64. Lorsque vous sérialisez un objet JavaScript Date avec JSON.stringify, vous obtenez automatiquement une chaîne ISO 8601, mais en la relisant vous obtenez une chaîne, pas une Date : la conversion est à faire vous-même. Traiter chaque horodatage en UTC (le Z final) et ne convertir en heure locale que pour l’affichage est le moyen le plus sûr d’éviter les bogues de fuseau horaire.

Clés en double et ordre des clés

Deux autres détails piègent souvent. D’abord, la RFC 8259 indique que les noms d’un objet devraient être uniques mais n’interdit pas les doublons, et précise que le comportement d’un logiciel face à une clé répétée est imprévisible. En pratique, la plupart des analyseurs, dont celui du navigateur, conservent la dernière occurrence — cet outil n’en garde donc qu’une — mais il ne faut jamais compter dessus, et les clés en double sont une source classique de bogues d’interopérabilité. Ensuite, bien qu’un objet JSON soit formellement une collection non ordonnée, la plupart des analyseurs courants conservent l’ordre d’insertion des clés, et cet outil garde vos clés dans l’ordre où vous les avez écrites, avec une exception propre à JavaScript : les clés qui ressemblent à des index de tableau (des entiers) sont placées en tête, par ordre croissant. Si votre application dépend vraiment d’un ordre précis, encodez-le explicitement — par exemple sous forme de tableau de paires — plutôt que de vous fier à l’ordre des clés d’un objet.

Naviguer dans JSON : JSONPath et JSON Pointer

À mesure que les documents grossissent, il faut un moyen de désigner une valeur enfouie en profondeur. Deux petites normes font exactement cela. JSON Pointer (RFC 6901) utilise un chemin séparé par des barres obliques, comme /users/0/email, pour désigner un emplacement précis — c’est ce qu’utilisent en interne JSON Patch et JSON Schema pour faire référence à un nœud. JSONPath est une syntaxe de requête plus expressive (inspirée de XPath pour XML) qui peut sélectionner plusieurs nœuds à la fois, filtrer selon une condition et utiliser des jokers — par exemple $.users[*].email pour récupérer l’adresse e-mail de chaque utilisateur. Pointer répond à « cet endroit précis » ; JSONPath à « tout ce qui correspond ». Savoir qu’ils existent évite de longues recherches à la main dans un gros document embelli.

Conseils pour les gros fichiers JSON

Les outils qui fonctionnent dans le navigateur, celui-ci compris, traitent sans peine des fichiers de plusieurs mégaoctets, car le travail se fait localement sur votre machine. Quelques habitudes aident quand les documents deviennent vraiment volumineux. Embellissez avant de lire pour voir la structure, mais gardez une copie minifiée pour le transport. Pour les fichiers trop gros pour tenir en mémoire d’un seul coup, préférez NDJSON (un objet par ligne) et traitez-le ligne par ligne, ou utilisez un analyseur en flux qui produit les valeurs au fil de la lecture au lieu de construire d’abord tout l’arbre. Et lorsqu’une API renvoie une grande collection, cherchez la pagination — un curseur next ou un paramètre de page — au lieu de tout demander d’un coup ; une API bien conçue ne vous demande jamais de télécharger un million d’enregistrements dans une seule réponse.

Questions fréquentes

Mon JSON est-il envoyé sur un serveur ?

Non. La mise en forme, la validation et la minification s’exécutent entièrement dans votre navigateur, en JavaScript. Vos données ne quittent jamais votre appareil : l’outil est donc rapide, et vous pouvez y coller sans crainte des contenus sensibles.

Pourquoi mon JSON n’est-il pas valide ?

Les causes les plus fréquentes sont une virgule après le dernier élément, des apostrophes au lieu de guillemets doubles, des clés sans guillemets, des commentaires (JSON n’en accepte aucun) ou un crochet ou une accolade manquante. L’outil vous indique la ligne et la colonne exactes où la lecture a échoué.

Quelle est la différence entre formater, valider et minifier ?

Valider consiste à vérifier que le texte est un JSON bien formé. Formater (ou embellir) réindente un JSON valide pour le rendre lisible. Minifier supprime tous les espaces superflus pour obtenir le texte le plus compact possible avant de le transmettre. Cet outil fait les trois à partir d’une seule zone de saisie.

La mise en forme modifie-t-elle mes données ?

Non pour le contenu : embellir et minifier ne changent que les espaces, et les clés, les valeurs, les types et la structure restent les mêmes. Trois nuances toutefois, car l’outil relit puis réécrit le JSON : un nombre est réécrit sous sa forme la plus courte (un zéro décimal inutile ou un exposant disparaît, la valeur reste égale), un entier trop grand pour être représenté exactement est arrondi, et si une clé est répétée, seule sa dernière valeur est conservée. Les clés gardent l’ordre dans lequel vous les avez écrites, sauf les clés qui sont des entiers, placées en tête comme partout en JavaScript.

Quelle taille de fichier l’outil peut-il traiter ?

Comme tout se passe dans votre navigateur, il traite sans difficulté les réponses d’API et les fichiers de configuration courants (plusieurs Mo). Pour les fichiers très volumineux, la seule limite est la mémoire de votre appareil, pas une limite d’envoi.

Outils pour développeurs associés

• JSON vers CSV
• JSON vers XML
• JSON vers tableau HTML
• CSV vers JSON
• Encodeur / décodeur Base64

Voir toutes les conversions pour développeurs et données →