Validateur JSON, gratuit

Validation JSON : deux couches, deux questions différentes

Un validateur JSON répond à une question binaire, ce document JSON est-il bien formé ?, en confiant l'entrée au même parseur que le navigateur utilise en interne et en rapportant s'il accepte la syntaxe. Cet outil fait cela et rien d'autre. Il ne vérifie pas si les données à l'intérieur du document signifient ce que vous vouliez. Cette deuxième question, le document a-t-il la forme, les types et les contraintes attendus par votre application ?, est la validation de schéma, le territoire d'outils comme Ajv (traité plus bas). Les deux activités se complètent et répondent à des questions différentes ; utiliser l'une quand on voulait l'autre est une erreur de catégorie. Une analogie utile est la distinction correcteur-orthographique / correcteur-grammatical dans les traitements de texte : le correcteur orthographique (syntaxe) vous dit si chaque mot est un vrai mot ; le correcteur grammatical (schéma) vous dit si la phrase a du sens ; les deux sont utiles, aucun ne remplace l'autre, et aucun ne vous dit si l'essai est bon. {"phoneNumber": 12345} est du JSON bien formé, mais si votre application attendait une chaîne formatée "+1-555-555-1234", c'est faux, et un validateur de syntaxe ne peut pas le dire.

Au-delà de la vérification syntaxique, cet outil propose aussi une passe « Corriger les problèmes courants » au mieux qui réécrit les quatre façons les plus fréquentes dont les développeurs écrivent par inadvertance du JSON invalide : virgules finales, chaînes entre apostrophes, clés non quotées et littéraux undefined (réécrits en null). C'est une heuristique, pas un parseur, donc relisez toujours la sortie corrigée avant adoption.

Une brève histoire de JSON

JSON a une biographie remarquablement courte. L'acronyme a été inventé chez State Software, Inc., un petit cabinet de conseil que Douglas Crockford et Chip Morningstar ont co-fondé en mars 2001 pour construire ce qu'on appellerait plus tard des applications web Ajax. Le premier message JSON a été envoyé en avril 2001 depuis un ordinateur dans le garage Bay-Area de Morningstar. Crockford ne revendique pas avoir inventé JSON, le format existait déjà dans le langage JavaScript comme sous-ensemble d'objet-littéral ; sa contribution a été de l'isoler, de lui donner un nom, de monter un site (json.org est apparu en 2002 avec une description de la grammaire en trois notations et un parseur de référence en JavaScript) et de plaider pour son adoption. Décembre 2005 est le moment que la plupart des historiens désignent comme l'entrée de JSON dans le mainstream : ce mois-là, Yahoo! a commencé à proposer certains de ses services web en JSON. L'IETF a pris le relais ensuite : RFC 4627 (« The application/json Media Type for JSON »), de la plume de Crockford lui-même, a été publiée en juillet 2006 comme document informationnel, pas en Standards Track. Les organismes de normalisation ont rattrapé en 2013-2014 : ECMA-404 1re édition en octobre 2013 (délibérément minimale, six pages de contenu substantiel), RFC 7159 en mars 2014 (qui assouplit la restriction de plus haut niveau pour que toute valeur JSON, pas seulement objets et tableaux, puisse être un document complet), et la paire actuelle en décembre 2017 : RFC 8259 (désormais Internet Standard STD 90) et ECMA-404 2e édition alignée normativement avec elle. Les deux sont jumelles : chacune référence normativement l'autre et contient un engagement de cohérence. Aussi publiée comme ISO/IEC 21778:2017.

La grammaire JSON en 200 mots

Un document JSON est une seule valeur, optionnellement entourée d'espaces. Il existe exactement six types de valeurs : objet, une collection non ordonnée de zéro ou plusieurs paires nom/valeur, écrite {"k": v, "k2": v2} ; tableau, une séquence ordonnée, [v, v2, v3] (les tableaux préservent l'ordre par spec) ; chaîne, une séquence de caractères Unicode entourée de guillemets doubles (apostrophes interdites ; échappements antislash \", \\, \/, \b, \f, \n, \r, \t plus \uXXXX ; les caractères de contrôle U+0000 à U+001F doivent être échappés) ; nombre, une forme ASCII stricte (signe moins optionnel, partie entière sans zéros de tête, partie fractionnaire optionnelle, exposant optionnel avec e ou E) ; true / false, les booléens JSON, en minuscules uniquement ; null, l'absence de valeur, en minuscules uniquement. Les espaces entre tokens sont permis et ignorés. Pas de commentaires. Pas de virgules finales. Les clés d'objet doivent être des chaînes entre guillemets doubles. La grammaire tient sur une page. La forme stricte des nombres interdit l'hexa (0xFF), l'octal (0777), le signe +, Infinity, NaN et les points décimaux finaux comme 1. ; cela attrape quiconque écrit du JSON à la main dans des environnements qui acceptent les formes numériques ECMAScript plus laxes, le plus souvent, quiconque a déjà collé un code couleur hexa dans un fichier JSON.

Pourquoi la grammaire est si stricte, les choix de design de Crockford

Deux omissions délibérées expliquent l'essentiel de la friction que ressentent les utilisateurs en écrivant du JSON à la main. Pas de commentaires. JavaScript a // et /* */ ; JSON, sous-ensemble de JavaScript, n'a aucun des deux. La raison déclarée de Crockford, postée sur Google+ en 2012, a été citée des milliers de fois depuis : « J'ai retiré les commentaires de JSON parce que je voyais des gens les utiliser pour porter des directives de parsing, pratique qui aurait détruit l'interopérabilité. Je sais que l'absence de commentaires rend certains tristes, mais ça ne devrait pas. » L'argument est que les commentaires invitent à l'extension, si // @schema foo.json est dans votre config et que votre outil le lit, alors votre fichier de config n'est plus JSON. Pas de virgules finales. Une virgule est un séparateur, pas un terminateur. [1, 2, 3] est légal mais [1, 2, 3,] ne l'est pas. La raison est la même que pour les commentaires : simplicité de la grammaire et uniformité entre parseurs. Le coût est que quiconque édite un objet JSON multi-ligne, ajoute une propriété, réorganise des propriétés, supprime la dernière, doit penser à la virgule. Pas d'undefined. JavaScript a undefined ; JSON pas. Utilisez null ou omettez la propriété complètement. BOM en entrée. Un byte-order mark (U+FEFF) au début d'un document JSON est interdit en transmission JSON, mais les parseurs PEUVENT en ignorer un s'il apparaît. En pratique, les fichiers sauvegardés en « UTF-8 with BOM » par des éditeurs Windows plus anciens cassent silencieusement certains parseurs et marchent silencieusement avec d'autres.

Erreurs JSON courantes :

• Virgules finales : le dernier élément d'un objet ou d'un tableau ne peut pas avoir de virgule
• Apostrophes au lieu de guillemets doubles : le JSON n'autorise que les guillemets doubles pour les chaînes
• Clés sans guillemets : les clés d'objets doivent toujours être entre guillemets doubles
• Commentaires : le JSON ne prend pas en charge les commentaires (bien que certains outils les acceptent)
• Antislash non échappé. Dans une chaîne JSON, \ est le caractère d'échappement. "C:\Users\Alice" échoue parce que \U et \A ne sont pas des échappements reconnus. Le remède est de doubler chaque antislash : "C:\\Users\\Alice".
• Caractères de contrôle non échappés. Un retour à la ligne, une tabulation ou tout autre caractère en U+0000-U+001F littéral à l'intérieur d'une chaîne JSON est interdit. La plupart des utilisateurs tombent dessus en collant une chaîne multi-ligne dans une valeur JSON sans échapper les retours à la ligne en \n.
• NaN et Infinity. Hors de la grammaire JSON. Le JSON.parse du navigateur les rejette. JSON.stringify produit null quand on lui demande de sérialiser NaN ou Infinity, donc l'aller-retour perd silencieusement de l'information.
• Entrée vide. Lance « Unexpected end of JSON input. » Le piège est qu'une réponse HTTP revenue avec Content-Type: application/json mais un corps vide produit cette erreur dans les chaînes fetch().then(r => r.json()).

JSON Schema, le standard pour valider la forme

JSON Schema est un vocabulaire basé sur JSON pour décrire la structure et les contraintes de documents JSON. La première proposition a été soumise par Kris Zyp en octobre 2007 ; la série d'Internet-Drafts de l'IETF a commencé avec draft-zyp-json-schema-00 le 5 décembre 2009. Les drafts successifs ont évolué via une demi-douzaine d'auteurs et éditeurs sur la décennie et demie suivante. La version stable actuelle est le draft 2020-12 (le nom « 2020-12 » désigne le snapshot de développement dont il dérive ; la sortie formelle effective fut le 16 juin 2022). Les quatre mots-clés d'assertion les plus utilisés portent l'essentiel du travail quotidien : type (contraint une valeur à l'un des six types JSON ou à une liste de types acceptables), required (liste de noms de propriétés qu'un objet doit contenir), properties (carte de nom de propriété vers sous-schéma pour la valeur), et items (un schéma appliqué à chaque élément d'un tableau). Combinés avec minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, etc.) et les mots-clés composites (allOf, anyOf, oneOf, not), JSON Schema peut exprimer presque n'importe quelle contrainte de « forme » que vos données doivent satisfaire. Le schéma est lui-même un document JSON, ce qui est récursif d'une manière que certains trouvent élégante et d'autres étourdissante.

Ajv, le validateur de schéma JavaScript dominant

Si vous voulez faire de la validation de schéma en JavaScript, la réponse canonique est Ajv (Another JSON Schema Validator) d'Evgeny Poberezkin. Son astuce est de compiler le schéma en JavaScript optimisé : au lieu de parcourir le schéma et l'arbre de données à l'exécution, il génère une fonction qui code en dur chaque vérification et tourne à vitesse native. Cela le rend spectaculairement plus rapide que les validateurs naïfs sur de gros documents et sur les chemins de validation chauds. Ajv supporte les drafts JSON Schema 04, 06, 07, 2019-09 et 2020-12 ; c'est le validateur intégré dans express-validator, la validation de requêtes d'AWS API Gateway et nombre de frameworks Node.js majeurs. Pour Python, le choix canonique est jsonschema de Julian Berman ; pour Java, le json-schema-validator de Networknt. Le point est que la validation de schéma est un problème résolu, mature et bien outillé, mais c'est un problème dans lequel il faut entrer en écrivant le schéma. Cet outil n'écrit pas le schéma pour vous ; il fait uniquement la validation syntaxique.

JSON5 et JSONC, les sur-ensembles relâchés

JSON5 est un sur-ensemble formel de JSON spécifié sur json5.org, originellement conçu par Aseem Kishore en 2012 et désormais maintenu par Jordan Tucker. Il permet tout ce que le JSON strict interdit : les commentaires (// et /* */), virgules finales, chaînes entre apostrophes, clés d'objet non quotées (quand ce sont des identifiants ECMAScript valides), nombres hexadécimaux, points décimaux en début/fin (.5 ou 5.), Infinity et NaN, et nombres signés. Les documents JSON5 utilisent typiquement l'extension .json5 et sont parsés par des bibliothèques comme le package npm json5. JSONC est le mode informel « JSON with Comments » de Microsoft, utilisé dans les fichiers de réglages de VS Code (settings.json, launch.json, tasks.json). Les commentaires y sont autorisés par spec ; les virgules finales sont tolérées par le parseur de référence mais signalées par des avertissements. Les formes relâchées sont pour les fichiers de configuration édités à la main où la discipline du JSON strict gêne ; pour l'échange machine-à-machine, le JSON strict reste le bon choix. Cet outil utilise le JSON.parse strict du navigateur et rejettera donc les deux, retirez commentaires et virgules finales avant de coller, ou utilisez un parseur JSON5/JSONC pour convertir d'abord en JSON strict.

Validateurs streaming pour de très grandes entrées

JSON.parse du navigateur charge tout le document en mémoire comme un seul arbre d'objets. Pour la plupart des entrées c'est correct ; pour des fichiers de log, des exports d'API de plusieurs gigaoctets ou des dumps de données capteurs, ça ne l'est pas. L'approche streaming est de consommer le document comme un flux de tokens et d'émettre des événements (« début de tableau », « valeur chaîne », « clé d'objet ») sans jamais détenir la structure entière en mémoire. clarinet de Marak Squires est le parseur JSON streaming Node.js canonique, modelé sur le pattern du parseur SAX XML. Oboe.js de Jim Higson (originaire de sa thèse de 2013) est l'équivalent compatible navigateur, conçu pour consommer du JSON sur fetch à mesure qu'il arrive et émettre des événements pour chaque JSONPath correspondant ; il n'est plus activement maintenu mais la technique qu'il a inaugurée reste utile. JSONStream sur npm enveloppe clarinet pour un usage Node compatible pipes. Un outil pur navigateur comme celui-ci est borné par la mémoire disponible ; si vous validez du JSON à l'échelle du gigaoctet, exécutez un parseur streaming en Node ou utilisez jq --stream en ligne de commande.

Où la validation JSON compte dans des workflows réels

Les fichiers de configuration sont le cas à plus fort levier : tsconfig.json, package.json, configs ESLint et Prettier, Docker Compose, politiques AWS IAM. Un seul caractère invalide peut casser le build ; un validateur syntaxique l'attrape avant le build. Les réponses d'API ensuite : développer contre une API externe, c'est souvent fixer un payload et se demander « cette chose est-elle vraiment du JSON valide ? » avant de chasser un bug de parsing plus profond. Les charges utiles de webhooks, événements Stripe, déclencheurs GitHub Actions, webhooks entrants Slack, sont du JSON ; un coller-valider rapide attrape les cas où une signature malformée ou un octet errant a corrompu le corps. Les entrées de log (logs structurés Splunk, Datadog, Loki) sont du JSON ligne-à-ligne ; une mauvaise ligne casse tout le pipeline d'ingestion. Les fichiers JSON générés (lockfiles, manifestes de build, fixtures de tests) dérivent parfois de façon bruyante en dev normal ; un validateur syntaxique attrape les cas où l'étape de génération elle-même a échoué.

Les limites honnêtes d'un validateur de syntaxe seul

Un validateur syntaxique ne peut pas attraper les erreurs de logique. Il ne peut pas vous dire qu'un champ « phone number » contient un entier au lieu d'une chaîne ; qu'une chaîne « date » est malformée mais se trouve être une chaîne valide ; qu'un champ obligatoire manque ; qu'un nombre supposé positif est négatif ; que deux champs supposés correspondre ne correspondent pas. Tout cela relève de la validation de schéma. Le bon pipeline pour un système en production est : (1) validation syntaxique comme première barrière, est-ce que cela parse comme JSON tout court ? (2) validation de schéma comme deuxième barrière, a-t-il la forme attendue ? (3) validation de logique métier comme troisième barrière, les données ont-elles du sens compte tenu d'autres états ? Des outils existent pour les trois couches ; celui-ci gère seulement la première. L'avantage de coller un payload dans un validateur syntaxique d'abord est qu'il isole le mode de panne le moins cher et le plus commun (une virgule errante, une accolade manquante) des erreurs de schéma plus coûteuses qui les noieraient autrement.

Confidentialité : pourquoi le tout-navigateur compte ici

Valider du JSON sur un serveur exige de téléverser le document. Pour des exemples ordinaires de données publiques, c'est inoffensif. Pour des réponses d'API contenant des tokens d'authentification, des PII clients, des dossiers d'employés internes, des secrets de configuration ou des données produit non publiées, ce ne l'est pas. Même avec la politique de suppression la plus scrupuleuse, le téléversement reste dans les journaux serveur, possiblement dans un cache CDN, possiblement dans un pipeline d'analytique, possiblement dans une sauvegarde. Cet outil exécute JSON.parse dans votre navigateur via JavaScript. Le document collé ne traverse jamais le réseau, vérifiez dans l'onglet Network de DevTools en cliquant un bouton, ou mettez la page hors ligne (mode avion) après chargement et confirmez que le validateur fonctionne encore. Sûr pour valider des payloads de webhook avec secrets, des réponses d'API avec en-têtes d'authentification, des fichiers de config avec identifiants de base, ou tout autre JSON que vous ne voulez pas voir copié sur le disque dur d'un inconnu.

Foire aux questions

Qu'est-ce qu'un JSON valide ?

Un JSON valide doit être l'un de ces types : objet ({}), tableau ([]), chaîne (""), nombre, booléen (true/false) ou null. Toutes les chaînes et les clés d'objets doivent utiliser des guillemets doubles. Les nombres ne peuvent pas avoir de zéros en tête. Les espaces sont autorisés entre les éléments.

Que fait « Corriger les problèmes courants » ?

La correction tente de corriger automatiquement les erreurs fréquentes : virgules finales, apostrophes converties en guillemets doubles, clés sans guillemets, et valeurs undefined converties en null. C'est un outil heuristique qui peut ne pas tout corriger, relisez le résultat avec attention.

Comment valider du JSON dans mon application ?

En JavaScript : utilisez JSON.parse() et interceptez les erreurs. En Node.js : fs.readFileSync() + JSON.parse(). En Python : json.loads() ou json.load(). La plupart des langages disposent de bibliothèques JSON intégrées.

Puis-je valider du JSON5 ou JSONC (JSON avec commentaires) ?

Pas directement. Cet outil utilise le JSON.parse strict du navigateur, qui suit RFC 8259, commentaires, virgules finales, apostrophes et clés non quotées sont des erreurs de syntaxe. Si votre entrée est JSON5 (json5.org, Aseem Kishore 2012, maintenu par Jordan Tucker) ou JSONC de VS Code, installez le package npm json5 ou le package jsonc-parser, convertissez en JSON strict, puis validez. La passe « Corriger les problèmes courants » gère un sous-ensemble des différences mais n'est pas un parseur JSON5 / JSONC complet.

Y a-t-il une limite de taille ?

Pas de limite stricte, mais le JSON.parse du navigateur charge le document entier en mémoire comme un seul arbre d'objets. Des dizaines de milliers de lignes passent confortablement ; des dumps de log de plusieurs gigaoctets épuiseront la mémoire. Pour du JSON très grand, exécutez un parseur streaming comme clarinet (Marak Squires) ou Oboe.js (Jim Higson, 2013), ou utilisez jq --stream en ligne de commande, qui peut traiter des documents de taille arbitraire sans jamais charger tout le contenu.

Mes documents JSON sont-ils téléversés ?

Non. JSON.parse tourne dans votre navigateur via JavaScript. Le document collé ne traverse jamais le réseau, vérifiez dans l'onglet Network de DevTools en cliquant Validate, ou mettez la page hors ligne après chargement et confirmez que l'outil fonctionne encore. Sûr pour valider des payloads de webhook avec secrets, des réponses d'API avec en-têtes d'authentification, ou des fichiers de config avec identifiants de base.