Qu'est-ce que le JSON ? Syntaxe, règles et erreurs courantes

Le JSON (JavaScript Object Notation) est un format texte pour représenter des données structurées : des objets, des listes, du texte, des nombres. Il s’écrit avec des accolades et des crochets, se lit dans n’importe quel langage de programmation, et c’est le format que la quasi-totalité des API web utilisent pour échanger des données.

Ce qu’est vraiment le JSON

Un document JSON n’accepte que six types de valeurs, et rien d’autre. Les voici :

• string : une chaîne de caractères, toujours entre guillemets doubles, jamais simples
• number : un nombre, entier ou décimal
• boolean : true ou false
• null : l’absence de valeur
• object : une collection de paires clé-valeur entre accolades, comme `{"nom":"Ada"}`
• array : une liste ordonnée de valeurs entre crochets, comme `["a","b","c"]`

C’est tout. Pas de dates natives, pas de fonctions, pas de types personnalisés. Cette simplicité volontaire est justement ce qui rend le JSON portable d’un langage à l’autre : un objet JSON produit par un serveur Python se lit sans surprise dans un client JavaScript ou une application Java.

En dehors de ces six types, quelques règles de syntaxe strictes s’appliquent :

• les clés d’un objet doivent être des chaînes entre guillemets doubles, jamais laissées nues
• aucune virgule finale n’est autorisée après le dernier élément d’un tableau ou la dernière propriété d’un objet
• aucun commentaire n’est toléré, sous aucune forme
• les chaînes et les clés utilisent exclusivement des guillemets doubles, jamais des guillemets simples
• NaN, Infinity et undefined ne sont pas des valeurs JSON valides
• les fonctions ne peuvent tout simplement pas être représentées en JSON

Ces règles paraissent restrictives la première fois qu’on les lit, mais elles servent une seule idée : zéro ambiguïté pour le parseur. Il n’existe qu’une seule façon correcte d’écrire une donnée, donc n’importe quel analyseur, dans n’importe quel langage, produit exactement le même résultat.

JSON face à un objet littéral JavaScript

Le JSON ressemble beaucoup à un objet littéral JavaScript, au point que beaucoup de développeurs les confondent et collent l’un à la place de l’autre. Les deux se lisent presque pareil à l’œil nu, mais leurs règles divergent sur plusieurs points précis :

Caractéristique	JSON	Objet littéral JavaScript
Clés obligatoirement entre guillemets	Oui, guillemets doubles uniquement	Non, les guillemets sont optionnels
Virgule finale autorisée	Non	Oui
Commentaires autorisés	Non	Oui
Chaînes entre guillemets simples	Non	Oui
Fonctions comme valeurs	Non	Oui
undefined comme valeur	Non	Oui

Cette confusion vient d’un raccourci historique : le JSON a été conçu à partir de la syntaxe des objets littéraux JavaScript, donc les deux se ressemblent visuellement. Mais le JSON est un format d’échange de données, indépendant de tout langage, alors qu’un objet littéral est du code JavaScript exécutable. Copier-coller un objet JavaScript directement dans un fichier .json est l’une des causes les plus fréquentes d’erreur de parsing : le fichier contient une virgule finale ou une clé sans guillemets, deux choses parfaitement légales en JavaScript mais interdites en JSON.

Exemple concret : minifier et formater une vraie réponse d’API

Voici un objet représentant un utilisateur, dans les deux formes que vous croiserez en pratique.

Sous sa forme minifiée, sans le moindre espace, cet objet tient en 107 caractères :

{"id":1,"name":"Ada Lovelace","email":"[email protected]","roles":["admin","user"],"active":true,"meta":null}

Sous sa forme formatée, avec une indentation de 2 espaces, il occupe 145 caractères :

{
  "id": 1,
  "name": "Ada Lovelace",
  "email": "[email protected]",
  "roles": [
    "admin",
    "user"
  ],
  "active": true,
  "meta": null
}

La version formatée est environ 35 % plus lourde que la version minifiée, uniquement à cause des espaces et des retours à la ligne ajoutés. Cet écart explique pourquoi les API renvoient leurs réponses en JSON minifié : chaque octet économisé compte quand on multiplie une requête par des milliers d’appels par seconde. À l’inverse, un développeur qui inspecte cette même réponse dans ses outils de débogage veut la version formatée, celle qui laisse voir d’un coup d’œil la structure imbriquée, le tableau roles, la valeur null du champ meta.

Formatez votre propre JSON

Collez votre JSON ci-dessous pour le formater, le minifier ou repérer immédiatement une erreur de syntaxe.

Formateur et Validateur JSON

Gratuit, sans inscription, sur tous les appareils.

Ouvrir l'outil complet

Erreurs courantes et cas limites

La virgule finale. C’est l’erreur la plus fréquente, celle qui survient dès qu’on colle un objet JavaScript tel quel. Avec `{"id":1,"name":"Ada",}`, le moteur V8 de Chrome (celui qui exécute JSON.parse dans le navigateur de la plupart des visiteurs) renvoie exactement ce message : Expected double-quoted property name in JSON at position 21 (line 1 column 22). Le message peut varier légèrement d’un navigateur à l’autre (Firefox et son moteur SpiderMonkey formulent leurs erreurs différemment), mais l’analyse échoue toujours de la même façon : la virgule finale n’a rien après elle, donc le parseur s’attend à une propriété qui n’arrive jamais.

Une clé sans guillemets. Écrire `{id:1}` produit Expected property name or '}' in JSON at position 1 (line 1 column 2). Le parseur JSON n’accepte que des clés entre guillemets doubles ; sans eux, il ne reconnaît tout simplement pas id comme une clé valide.

Une clé entre guillemets simples. Le même type d’erreur apparaît avec `{'a':1}`, qui produit Expected property name or '}' in JSON at position 1 (line 1 column 2). Les guillemets simples ne font pas partie de la grammaire JSON, même s’ils sont parfaitement valides en JavaScript.

NaN comme valeur. `{"a":NaN}` échoue avec Unexpected token 'N', "{"a":NaN}" is not valid JSON. NaN existe en JavaScript pour représenter un résultat numérique invalide, mais le JSON n’a aucun moyen de l’encoder.

undefined comme valeur. De même, `{"a":undefined}` produit Unexpected token 'u', "{"a":undefined}" is not valid JSON. Le JSON connaît null pour représenter une absence de valeur, mais pas undefined.

Les clés en double, un piège silencieux. Contrairement aux erreurs précédentes, `{"a":1,"a":2}` est syntaxiquement valide et s’analyse sans la moindre erreur. Le résultat est `{"a":2}` : la plupart des parseurs, y compris celui de JavaScript, gardent silencieusement la dernière occurrence et jettent la première, sans jamais vous prévenir. C’est une source de bug particulièrement sournoise en pratique : un outil de build ou un fichier de configuration édité à la main se retrouve avec la même clé deux fois, et personne ne s’en aperçoit puisqu’aucune erreur n’est levée. La seule façon de l’attraper est de relire le JSON attentivement, ou de le faire passer par un outil qui affiche la structure finale telle qu’elle sera vraiment interprétée.

Questions fréquentes

Qu’est-ce que le JSON ? C’est un format texte pour représenter des données structurées à l’aide de six types de valeurs : chaînes de caractères, nombres, booléens, null, objets et tableaux. Il sert de langage commun entre serveurs, applications et API, indépendamment du langage de programmation utilisé de chaque côté.

Le JSON est-il identique à un objet JavaScript ? Non, même si les deux se ressemblent beaucoup. Le JSON impose des guillemets doubles sur toutes les clés, interdit les virgules finales, les commentaires et les guillemets simples, là où un objet littéral JavaScript tolère tout cela. Coller un objet JavaScript directement dans un fichier JSON est la cause la plus courante d’erreur de parsing.

Pourquoi une virgule en trop casse mon JSON ? Parce que la grammaire JSON n’autorise aucune virgule après le dernier élément d’un tableau ou la dernière propriété d’un objet. Le parseur s’attend à trouver une valeur ou une clé juste après une virgule, et s’il tombe sur une accolade ou un crochet fermant à la place, il échoue avec une erreur du type Expected double-quoted property name in JSON.

Le JSON accepte-t-il les commentaires ? Non, sous aucune forme, ni // ni /* */. C’est une limitation volontaire de la spécification : si vous avez besoin d’annoter un fichier de configuration, des formats comme JSON5 ou YAML l’autorisent, mais pas le JSON strict.

Quelle est la différence entre formater et minifier du JSON ? Formater ajoute une indentation et des retours à la ligne pour rendre la structure lisible par un humain, au prix d’un fichier plus volumineux (environ 35 % de plus dans notre exemple). Minifier fait l’inverse : retirer tous les espaces superflus pour obtenir la chaîne la plus compacte possible, ce qui réduit la taille des échanges réseau entre un client et une API.

Mes données sont-elles envoyées à un serveur quand j’utilise un formateur en ligne ? Sur pluri.tools, non. Le formateur JSON exécute JSON.parse et JSON.stringify directement dans votre navigateur, en JavaScript pur, sans le moindre appel réseau. Le JSON que vous collez ne quitte jamais votre appareil, ce qui rend l’outil utilisable même avec des données sensibles.