Erreurs JSON courantes et comment les corriger

Mis à jour : 28 septembre 2026

Le JSON est le format qu’utilisent de nombreuses API, fichiers de configuration et applications web pour échanger des données, et sa grammaire tient sur une seule page. C’est aussi pourquoi il ne pardonne rien : un texte est du JSON valide ou ne l’est pas, et une seule virgule de trop suffit pour qu’un analyseur (parser) rejette l’ensemble. La plupart des erreurs viennent des mêmes quelques habitudes, dont beaucoup sont héritées de JavaScript ou d’autres langages. Ce guide présente les règles, les erreurs qui les enfreignent le plus souvent, la façon de lire le message d’erreur, et quelques cas qui sont du JSON valide mais posent tout de même problème.

Les vraies règles du JSON

Les définitions actuelles sont la RFC 8259, publiée en décembre 2017, et ECMA-404. Elles décrivent la même syntaxe :

Les chaînes, y compris chaque nom de propriété, s’écrivent entre guillemets doubles. Les guillemets simples ne sont pas autorisés.
Les valeurs sont des chaînes, des nombres, des objets, des tableaux ou l’un des trois littéraux true, false et null, toujours en minuscules.
Les éléments des objets et des tableaux sont séparés par des virgules, sans virgule après le dernier.
Les nombres s’écrivent en décimal, sans zéros en tête, sans signe plus et sans NaN ni Infinity.
À l’intérieur d’une chaîne, le guillemet double, la barre oblique inverse et les caractères de contrôle comme le saut de ligne doivent être échappés.
Il n’existe aucune syntaxe pour les commentaires.

Entre les éléments syntaxiques, seuls quatre caractères d’espacement sont autorisés : l’espace, la tabulation, le saut de ligne et le retour chariot.

Les erreurs les plus courantes

Chacune d’elles est rejetée par un analyseur standard. La correction figure dans la description.

{"name": "Ana",}Virgule finale : supprimez la virgule après le dernier élément d’un objet ou d’un tableau.
{'name': 'Ana'}Guillemets simples : utilisez des guillemets doubles pour les noms de propriétés et les chaînes.
{name: "Ana"}Nom de propriété sans guillemets : chaque nom doit être une chaîne entre guillemets doubles.
{"a": 1 "b": 2}Virgule manquante entre deux éléments, souvent après avoir copié des lignes et les avoir mises bout à bout.
{“name”: “Ana”}Guillemets typographiques, que les traitements de texte et les applications de messagerie insèrent automatiquement : remplacez-les par des guillemets droits ".
{"note": 1 // total}Les commentaires ne font pas partie du JSON : supprimez-les ou déplacez la note dans une propriété.
{"active": True}Littéraux avec une majuscule : écrivez true, false et null en minuscules.
{"value": undefined}undefined, NaN et Infinity existent en JavaScript mais pas en JSON : utilisez null ou une chaîne.
{"code": 007}Les zéros en tête sont interdits dans les nombres : écrivez 7, ou "007" sous forme de chaîne si les zéros comptent.
{"path": "C:\Users"}Une barre oblique inverse seule commence une séquence d’échappement, et \U n’en est pas une. Pire, C:\new serait accepté et lu comme C:, un saut de ligne et ew. Écrivez \\ pour obtenir une barre oblique inverse littérale.
{"items": [1, 2}Une accolade ou un crochet jamais fermé, ou fermé par le mauvais caractère : chaque { doit avoir son } et chaque [ son ].

Formateur et convertisseur JSON

Lire le message d’erreur

Un analyseur lit le texte de gauche à droite et s’arrête au premier caractère qu’il ne peut pas accepter : la position indiquée dans le message d’erreur est donc l’endroit où il a abandonné, souvent juste après l’erreur réelle. Avec une virgule finale, l’analyseur signale l’accolade fermante, car après une virgule il attend un autre nom de propriété. S’il manque une accolade ou un crochet, l’erreur peut apparaître tout à la fin du texte, loin de l’endroit où le caractère manquant aurait dû se trouver.

La formulation varie selon les navigateurs et les langages, et beaucoup de messages indiquent une position, mais pas tous, soit sous forme de nombre de caractères depuis le début, soit sous forme de ligne et de colonne. Par exemple, le moteur JavaScript de Chrome signale {"name":"Ana",} ainsi :

Expected double-quoted property name in JSON at position 14 (line 1 column 15)En comptant à partir de 0, la position 14 correspond à l’accolade fermante ; la virgule à l’origine de l’erreur se trouve un caractère avant.

Lorsque la position n’est pas évidente, regardez le caractère juste avant, et vérifiez que chaque accolade, crochet ou guillemet ouvert avant ce point a bien son pendant. Un éditeur qui met en évidence les accolades et crochets correspondants permet souvent de repérer facilement celui qui manque.

Du JSON valide qui pose tout de même problème

Les grands nombres. Le JSON lui-même ne fixe aucune limite, mais JavaScript, ainsi que de nombreux analyseurs JSON dans d’autres langages, stockent les nombres en virgule flottante 64 bits, ce qui ne garantit des entiers exacts que jusqu’à 9 007 199 254 740 991. En JavaScript, JSON.parse transforme 9007199254740993 en 9007199254740992 sans le moindre avertissement. Les grands identifiants sont plus sûrs sous forme de chaînes.
Les noms de propriétés en double. La RFC 8259 indique que les noms devraient être uniques et que les logiciels qui reçoivent des doublons se comportent de façon imprévisible. JavaScript conserve la dernière valeur : {"a": 1, "a": 2} devient {"a": 2}.
Un indicateur d’ordre des octets (BOM). Certains éditeurs enregistrent les fichiers UTF-8 avec un caractère invisible U+FEFF au début. La RFC 8259 interdit de l’ajouter à du JSON transmis sur un réseau, et JSON.parse de JavaScript rejette un texte qui commence par ce caractère.
Une valeur seule au premier niveau. Les normes actuelles (ECMA-404, et les RFC publiées depuis la RFC 7159 de 2014) autorisent un texte JSON à être n’importe quelle valeur, comme "hello" ou 42, mais l’ancienne RFC 4627, de 2006, exigeait un objet ou un tableau, et certains analyseurs plus anciens l’exigent encore.

Le JSON n’est pas du JavaScript

La syntaxe du JSON est tirée des littéraux d’objet JavaScript, ce qui explique qu’on les confonde si facilement. Un littéral d’objet JavaScript accepte les guillemets simples, les noms sans guillemets, les virgules finales, les commentaires et des valeurs comme undefined ; le JSON n’accepte rien de tout cela. Un code qui fonctionne une fois collé dans un script peut donc échouer en tant que fichier JSON.

Certains outils acceptent des formats étendus comme JSON5, ou le « JSON avec commentaires » des fichiers de configuration. Ils sont pratiques là où ils sont pris en charge, mais ce n’est pas du JSON, et un analyseur standard, y compris le formateur nTools, les rejettera.

Questions fréquentes

Le JSON peut-il contenir des commentaires ?

Non. La spécification ne prévoit aucune syntaxe de commentaire. Si vous avez besoin de notes dans les données, placez-les dans une propriété comme "_comment", ou utilisez un format qui autorise les commentaires là où les outils le prennent en charge.

Pourquoi mon JSON fonctionne-t-il en JavaScript mais échoue-t-il dans un validateur ?

Parce qu’un littéral d’objet JavaScript autorise des choses que le JSON n’autorise pas, comme les guillemets simples, les virgules finales et les noms sans guillemets. Collé dans du code, il s’exécute ; enregistré en tant que JSON, il est invalide.

Comment conserver exactement un très grand nombre ?

Envoyez-le sous forme de chaîne, par exemple "9007199254740993", et convertissez-le à la réception avec un type capable de le contenir, comme BigInt en JavaScript.

Le formateur nTools envoie-t-il mon JSON quelque part ?

Non. Il est analysé et mis en forme dans votre navigateur, et lorsque le navigateur indique une position, le formateur l’affiche sous forme de ligne et de colonne.