Une erreur de jeton inattendu dans JSON signifie que votre analyseur a rencontré un caractère inattendu lors de la lecture de ce qui était censé être du JSON valide. Ce n'est presque jamais un bug mystérieux. Cela provient de l'une des six causes concrètes : une virgule finale, des guillemets simples, une réponse HTML, un BOM invisible, des clés non guillemetées ou des commentaires. Ce guide détaille chacune d'elles et, plus important encore, montre comment trouver la ligne et la colonne exactes au lieu de deviner.
Ce qui est frustrant, c'est que le message d'erreur pointe rarement vers le vrai problème. Jeton inattendu < dans JSON à la position 0 ne signifie pas que votre JSON est cassé. Cela signifie que vous ne regardez pas du tout du JSON. Une fois que vous savez lire ce que l'analyseur vous dit, la plupart de ces corrections prennent moins d'une minute.
Ce que signifie réellement "Unexpected Token in JSON"#
JSON est un format strict. L'analyseur lit votre chaîne caractère par caractère et construit une valeur. Dès qu'il rencontre quelque chose qui ne peut pas légalement apparaître à cette position, il s'arrête et lève une SyntaxError. Le "token" est le caractère qui a provoqué l'erreur.
Les moteurs modernes formulent le message différemment, ce qui ajoute à la confusion :
- V8 (Chrome, Node 20+):
Unexpected token 'x', "...contexte..." is not valid JSON - Node / Chrome plus anciens:
Unexpected token x in JSON at position 42 - Firefox:
JSON.parse: unexpected character at line 2 column 5 of the JSON data - Safari:
JSON Parse error: Unexpected identifier
Le champ le plus utile est la position ou le numéro de ligne/colonne. Firefox donne directement la ligne et la colonne. V8 donne une position en octets et un extrait du texte environnant. Lisez cela en premier, avant toute autre chose.
Le moyen le plus rapide de transformer une position cryptique en un problème visible est de coller la chaîne brute dans un validateur qui surligne la ligne défaillante. Notre formateur et validateur JSON gratuit marque l'endroit exact et vous indique ce qui était attendu, ce qui réduit la plupart des étapes de débogage ci-dessous à un simple coup d'œil.
Les 6 vraies causes (et comment corriger chacune)#
Voici la répartition honnête. Dans le débogage réel, la grande majorité de ces erreurs sont les causes 1 à 3. Les trois dernières sont plus rares mais font perdre des heures car elles sont invisibles ou contre-intuitives.
| Cause | Message typique | Indice |
|---|---|---|
| HTML au lieu de JSON | Unexpected token < à la position 0 | Le premier caractère est < (un <!DOCTYPE ou <html>) |
| Virgule finale | Unexpected token } ou ] | Une virgule se trouve avant une accolade ou un crochet fermant |
| Guillemets simples | Unexpected token ' | Les clés ou chaînes utilisent ' au lieu de " |
| BOM / caractères cachés | Unexpected token à la position 0 sur un JSON valide en apparence | A l'air parfait mais erreur au tout début |
| Clés non guillemetées | Unexpected token près d'une clé | Une clé comme nom: n'a pas de guillemets |
| Commentaires | Unexpected token / | Un commentaire // ou /* */ existe dans le fichier |
Cause 1 : Vous avez du HTML, pas du JSON (le cas « token < »)#
C'est celui qui déroute le plus, et presque aucun autre guide ne l'explique. Si vous voyez Unexpected token < in JSON at position 0, le < est l'ouverture d'une balise HTML. Votre appel fetch attendait du JSON mais le serveur a renvoyé une page HTML.
Cela signifie généralement l'une de ces choses :
- Le point d'accès a renvoyé une page d'erreur 404 ou 500 (HTML), pas votre charge utile API.
- Vous avez atteint la mauvaise URL et obtenu le
index.htmlde l'application. - Un proxy, un mur de connexion ou un limiteur de débit a intercepté la requête et servi une page HTML.
La correction n'est pas dans votre JSON. Enregistrez le texte brut de la réponse avant de l'analyser :
const res = await fetch(url);
const text = await res.text();
console.log(res.status, text.slice(0, 200)); // voir ce que vous avez réellement reçu
const data = JSON.parse(text);
Si text commence par <!DOCTYPE html>, vous avez trouvé. Vérifiez le code d'état et l'URL. Confirmez également que le Content-Type de la réponse est application/json, pas text/html.
Cause 2 : Virgule finale#
JSON n'autorise pas de virgule après le dernier élément d'un objet ou d'un tableau. Les littéraux d'objet JavaScript le font, ce qui explique pourquoi cela passe inaperçu. Vous écrivez du JSON à la main comme vous écrivez du JS, et l'analyseur le rejette.
{
"nom": "Ada",
"role": "ingénieur", // cette virgule finale est invalide
}
Supprimez la virgule après "ingénieur". La même chose s'applique aux tableaux : [1, 2, 3,] est un JSON invalide. Un formateur les signale instantanément car la virgule incriminée se trouve juste avant un } ou ].
Cause 3 : Guillemets simples au lieu de guillemets doubles#
JSON exige des guillemets doubles pour les clés et les valeurs de chaîne. Les guillemets simples sont une habitude JavaScript que JSON ne partage pas.
{ 'nom': 'Ada' } // invalide : guillemets simples partout
{ "nom": "Ada" } // valide
Si vous contrôlez la source, remplacez chaque ' par ". Si la chaîne incorrecte provient d'un endroit que vous ne pouvez pas modifier, ne faites pas de remplacement par regex aveuglément (les apostrophes dans les valeurs casseront tout). Utilisez plutôt un outil qui comprend la structure.
Cause 4 : La BOM invisible (et les CRLF Windows)#
Celle-ci déroute les gens pendant des heures car le JSON a l'air parfait. Vous voyez un JSON valide, vous le collez, et l'analyseur génère toujours une erreur à la position 0. Le coupable est une marque d'ordre des octets, un caractère caché U+FEFF que certains éditeurs (et la redirection > de PowerShell sous Windows) ajoutent au début des fichiers UTF-8.
L'analyseur lit la BOM comme le premier jeton et la rejette. Pour confirmer, vérifiez les premiers octets :
const text = fs.readFileSync("data.json", "utf8");
console.log(text.charCodeAt(0)); // 65279 signifie qu'une BOM est présente
const clean = text.replace(/^/, "");
JSON.parse(clean);
Enregistrez le fichier en UTF-8 sans BOM dans votre éditeur (VS Code affiche l'encodage dans la barre d'état ; cliquez dessus et choisissez "Enregistrer avec l'encodage"). Sous Windows, préférez Out-File -Encoding utf8NoBOM ou Set-Content à la redirection >, qui peut injecter la BOM. Des retours chariot parasites provenant des fins de ligne CRLF peuvent causer des bizarreries similaires à la position 0 lorsque le JSON est concaténé ou diffusé en continu.
Cause 5 : Clés non guillemetées#
En JavaScript, { nom: "Ada" } est correct. En JSON, la clé doit être guillemetée : { "nom": "Ada" }. Cela se produit surtout quand quelqu'un copie un littéral d'objet JavaScript dans un fichier .json ou un corps d'API.
La correction consiste à entourer chaque clé de guillemets doubles. Si vous avez un grand objet, un formateur ne guillemettera pas automatiquement les clés pour vous (cela reviendrait à deviner votre intention), mais il pointera la clé exacte qui a échoué pour que vous puissiez la corriger rapidement.
Cause 6 : Commentaires#
JSON n'a pas de commentaires. Ni //, ni /* */. Les gens les ajoutent aux fichiers de configuration par habitude, puis un analyseur strict échoue.
{
// paramètres de l'application <- invalide, JSON interdit les commentaires
"port": 3000
}
Supprimez les commentaires. Si vous avez vraiment besoin de commentaires dans la configuration, utilisez un format conçu pour cela (JSON5 ou JSONC, que VS Code utilise pour ses propres paramètres) et analysez-le avec une bibliothèque qui prend en charge ce dialecte, pas avec JSON.parse simple.
Comment trouver la ligne et la colonne exactes de l'erreur#
C'est la compétence qui transforme une chasse de 30 minutes en une correction de 30 secondes, et c'est la partie que la plupart des résultats de recherche ignorent complètement. L'erreur vous donne une position ; voici comment la convertir en un emplacement réel.
Étape 1 : Lire la position ou la ligne/colonne depuis l'erreur#
Capturez l'erreur complète, pas seulement le premier mot. Dans Node ou le navigateur, enveloppez l'analyse :
try {
JSON.parse(raw);
} catch (e) {
console.error(e.message); // inclut la position ou ligne:colonne
}
Firefox vous donne déjà ligne X colonne Y. V8 vous donne une position en octets. Notez ce nombre, vous l'utiliserez ensuite.
Étape 2 : Aller à cette position dans la chaîne brute#
Si vous avez une position en octets (par exemple 142), découpez autour pour voir le contexte qu'a vu l'analyseur :
console.log(raw.slice(130, 160));
Le caractère à la limite est votre coupable. Voir 15 caractères de chaque côté rend presque toujours la cause évidente : une virgule parasite, un guillemet simple, une balise HTML.
Étape 3 : Collez-la dans un validateur qui surligne l'endroit#
Examiner les positions dans une longue chaîne est lent et sujet aux erreurs. Collez le JSON brut dans le formateur et validateur JSON, qui met en forme la structure et marque la ligne en échec avec un message clair sur ce qui était attendu. La reformatation elle-même révèle souvent le problème, car une virgule mal placée ou une parenthèse non fermée devient visuellement évidente une fois l'imbrication correctement indentée.
Étape 4 : Corriger, revalider, puis retester dans le code#
Appliquez la correction, validez à nouveau pour confirmer que la chaîne est maintenant propre, puis exécutez votre chemin de code réel. Si le JSON provient d'une API, corrigez-le à la source si possible plutôt que de patcher la chaîne côté client. Une réponse propre bat une chaîne de .replace() défensive à chaque fois.
Prévenir l'erreur avant qu'elle ne survienne#
La plupart de ces erreurs sont évitables avec quelques bonnes habitudes. L'objectif est de ne jamais écrire manuellement du JSON que vos outils peuvent générer correctement pour vous.
- Ne construisez jamais du JSON par concaténation de chaînes. Utilisez
JSON.stringify()pour que les guillemets et les virgules soient toujours corrects. Si vous n'êtes pas sûr du résultat attendu, notre guide sur comment formater du JSON en JavaScript couvreJSON.stringifyet ses pièges. - Enregistrez toujours la réponse brute avant de l'analyser lors d'un appel API, afin qu'un
<(HTML) apparaisse immédiatement au lieu d'une mystérieuse erreur de jeton. - Vérifiez d'abord le code HTTP. Si
res.okest faux, lisez-le sous forme de texte et affichez la page d'erreur plutôt que de l'analyser aveuglément. - Enregistrez les fichiers de configuration en UTF-8 sans BOM et gardez un formateur dans votre flux de travail quotidien. Si vous travaillez souvent avec du JSON, découvrez pourquoi le formateur JSON est un outil quotidien pour les développeurs pour détecter ces problèmes avant leur mise en production.
- Validez votre JSON dans l'intégration continue. Un schéma ou une simple étape d'analyse dans votre pipeline détecte une virgule finale avant qu'elle n'atteigne la production.
Conclusion : Lisez la position, puis identifiez la cause#
Une erreur de jeton inattendu dans du JSON semble aléatoire jusqu'à ce que vous réalisiez qu'il s'agit d'un des six problèmes prévisibles, et que l'analyseur vous a déjà indiqué où chercher. Commencez par la position ou la ligne et la colonne, puis faites correspondre le caractère en échec à la cause : < signifie HTML, une virgule avant } signifie une virgule finale, un ' signifie des guillemets simples, et une erreur à la position 0 sur un JSON d'apparence parfaite indique presque toujours un BOM caché.
Lorsque vous voulez arrêter de plisser les yeux sur des décalages d'octets, collez la chaîne dans un validateur qui met en évidence la ligne exacte et montre ce qui était attendu. Cette seule étape remplace la plupart des recherches manuelles et vous permet de reprendre le développement.
Foire Aux Questions#
Que signifie "Unexpected token < in JSON at position 0" ?
Cela signifie que la réponse que vous avez essayé d'analyser commence par un <, qui est l'ouverture d'une balise HTML, et non du JSON. Votre code attendait du JSON mais le serveur a renvoyé une page HTML, généralement une page d'erreur 404 ou 500, une redirection de connexion ou une mauvaise URL. Enregistrez le texte brut de la réponse et vérifiez le code d'état pour confirmer.
Pourquoi mon JSON apparemment valide génère-t-il une erreur à la position 0 ?
La cause la plus courante est un marqueur d'ordre des octets (BOM) invisible, un caractère caché U+FEFF que certains éditeurs et shells Windows ajoutent aux fichiers UTF-8. Le JSON semble parfait mais l'analyseur lit d'abord le BOM et le rejette. Supprimez-le avec text.replace(/^/, "") ou enregistrez le fichier en UTF-8 sans BOM.
Les virgules finales sont-elles autorisées en JSON ?
Non. Une virgule après le dernier élément d'un objet ou d'un tableau est invalide en JSON, même si les littéraux d'objet JavaScript l'autorisent. C'est l'une des causes les plus fréquentes d'erreurs de jeton inattendu. Supprimez la virgule située juste avant un } ou un ].
Puis-je utiliser des guillemets simples en JSON ?
Non. JSON exige des guillemets doubles pour chaque clé et chaque valeur de chaîne. Les guillemets simples sont valides en JavaScript mais pas en JSON, donc { 'name': 'Ada' } générera une erreur, tandis que { "name": "Ada" } s'analyse correctement.
Comment trouver la ligne exacte à l'origine de l'erreur JSON ? Lisez d'abord la position ou la ligne et la colonne dans le message d'erreur, car l'analyseur vous indique où il a échoué. Découpez la chaîne brute autour de cette position pour voir le contexte, ou collez la chaîne entière dans le formateur et validateur JSON pour mettre en évidence la ligne défaillante et montrer le caractère attendu.
Le JSON prend-il en charge les commentaires ?
Le JSON pur ne prend en charge aucun type de commentaire, donc // et /* */ provoqueront une erreur de jeton inattendu. Si vous avez besoin d'une configuration commentée, utilisez JSON5 ou JSONC (le dialecte utilisé par VS Code pour ses paramètres) et analysez-le avec une bibliothèque qui comprend ces formats plutôt qu'avec JSON.parse.
