Validateur JSON Schema en ligne : erreurs avec chemin et raison
Avec ce validateur JSON Schema, vous collez un schéma et les données JSON à vérifier, et vous voyez tout de suite si elles correspondent. Sinon, chaque erreur est listée avec le chemin vers la valeur en échec et une raison claire, par exemple $.users[0].email. Les versions draft-07, 2019-09 et 2020-12 sont prises en charge, et les deux zones restent sur votre appareil.
Validation JSON Schema en ligne : mode d’emploi
- Collez votre schéma dans la zone Schéma JSON (elle affiche « Collez ici votre schéma JSON... »).
- Collez les données à vérifier dans la zone Données JSON.
- Lisez le Résultat. Il se met à jour au collage, ou environ 300 millisecondes après la dernière frappe : il n’y a rien sur quoi appuyer.
- Un Valide vert accompagné de « Les données JSON respectent le schéma. » signifie que les données passent. Un « Non valide : 3 erreurs » rouge liste chaque échec.
- Corrigez les données (ou le schéma) : le résultat change au fil de vos modifications.
Tant que les deux zones ne sont pas remplies, le résultat affiche « Collez un schéma et les données JSON pour les vérifier. » Si une zone contient du texte qui n’est pas du JSON, un encadré rouge JSON non valide donne la raison et « Ligne X, colonne Y », et le résultat vous dit quelle zone corriger. Pour remettre d’abord un document en ordre, « Formateur JSON » affiche les mêmes ligne et colonne pour un JSON cassé.
Lire les erreurs : chemin et raison
Chaque erreur comporte deux parties : un chemin et une raison. Le chemin commence à $, la racine de vos données, puis suit les noms de propriété avec des points et les positions de tableau entre crochets, en comptant à partir de 0. Exemple : le schéma exige id comme entier à partir de 1, email au format email et des tags sans doublon ; les données sont {"id":"7","email":"ana@","tags":["a","a"]}. Le résultat indique « Non valide : 3 erreurs » :
$.id: Doit être un entier, mais c’est une chaîne.$.email: Doit respecter le format « email ».$.tags: Les éléments [0] et [1] sont identiques, mais chaque élément doit être différent.
Toutes les erreurs sont listées, pas seulement la première : vous corrigez un document entier en une passe. Après 100 erreurs, la liste se termine par une ligne du type « et 250 autres erreurs non affichées » ; le nombre dans le titre reste exact. Si une propriété obligatoire (required) manque, l’erreur apparaît au chemin de l’objet qui devrait la contenir, par exemple $.users[0]. Les mots-clés plus rares (not, contains, propertyNames, dependentRequired et if/then/else) ont eux aussi une raison claire.
Mode strict : additionalproperties false
Par défaut, un schéma autorise les propriétés en plus : des données avec un champ nick que le schéma ne mentionne jamais passent quand même. Activez Mode strict (« Échoue si les données contiennent des propriétés que le schéma ne liste pas. ») pour repérer fautes de frappe et restes. Avec le schéma ci-dessus et les données {"id":1,"email":"ana@example.com","nick":"x"}, le résultat est « Valide » sans le mode, et « Non valide : 1 erreur » avec lui, à $ : Propriété inattendue « nick ».
Derrière l’interrupteur, l’outil ajoute unevaluatedProperties: false au schéma racine et à chaque schéma de propriété ou d’élément qui décrit un objet, y compris à travers $ref. Votre texte dans la zone n’est jamais modifié.
- Un schéma qui définit déjà
additionalPropertiesouunevaluatedPropertiesgarde son choix. - Un
{"type":"object"}libre, sansproperties, reste ouvert. - Les branches de
allOf,anyOfetoneOf, ainsi que les entrées de$defs, ne sont pas verrouillées d’elles-mêmes : des branches sœurs peuvent donc déclarer chacune leurs propriétés.
Vérificateur JSON Schema : versions, $ref et formats
L’outil lit la ligne "$schema" de votre schéma et vérifie les données avec les règles correspondantes : http://json-schema.org/draft-07/schema# est traité comme draft-07, https://json-schema.org/draft/2019-09/schema comme 2019-09 et https://json-schema.org/draft/2020-12/schema comme 2020-12. Sans "$schema", c’est 2020-12, ou 2019-09 si la syntaxe est ancienne, par exemple un tableau dans items. Draft-04, draft-06 ou toute autre adresse ne sont pas pris en charge, et le résultat indique l’adresse déclarée par le schéma. Cela compte, car certains mots-clés ont changé d’une version à l’autre : prefixItems relève de 2020-12, et definitions est devenu $defs en 2019-09. Les deux écritures du chemin de référence fonctionnent : #/$defs/name et #/definitions/name.
$refn’est suivi qu’à l’intérieur du même schéma. Rien n’est téléchargé : une référence distante commehttps://example.com/address.jsonest donc signalée comme une référence que le schéma ne définit pas. Collez ce schéma dans votre$defset faites pointer le$refdessus.formatest vérifié, pas ignoré : email, date, date-time, uri, uuid et les autres formats courants échouent avec « Doit respecter le format ».- Un schéma cassé affiche « Le schéma lui-même n’est pas valide » avec les problèmes et des chemins qui pointent dans le schéma, par exemple
"type": "strng". Les données ne sont pas vérifiées tant que le schéma n’est pas corrigé. Un motif qui n’est pas une expression régulière valide affiche « Le schéma n’a pas pu être utilisé ».
Limites et confidentialité
- Chaque zone accepte jusqu’à 5 000 000 de caractères. Au-delà, le résultat vous demande de coller un extrait plus petit.
- Les 100 premières erreurs sont listées ; le total est toujours compté.
- JSON uniquement : YAML et fichiers OpenAPI entiers doivent d’abord être convertis. L’outil valide ; il ne génère pas de schéma à partir des données et ne corrige pas vos données.
- Les nombres sont lus comme dans tout
JSON.parse: les entiers supérieurs à 9 007 199 254 740 991 perdent en précision avant d’être vérifiés. - Votre schéma et vos données sont vérifiés dans votre navigateur. Rien n’est envoyé ni enregistré.
Questions fréquentes
Comment utiliser un validateur JSON Schema en ligne ?
Collez le schéma dans la zone « Schéma JSON » et les données à vérifier dans « Données JSON ». Le résultat apparaît tout de suite au collage, ou environ 300 millisecondes après la dernière frappe. Un « Valide » vert signifie que les données correspondent ; un « Non valide » rouge liste chaque erreur avec son chemin et sa raison. Il n’y a aucun bouton sur lequel appuyer.
Quelles versions de schéma JSON sont prises en charge : draft-07, 2019-09 ou 2020-12 ?
Les trois. La version vient de la déclaration de version que contient votre schéma. Un schéma sans cette déclaration est vérifié comme 2020-12, ou comme 2019-09 s’il utilise une syntaxe ancienne, par exemple un tableau dans items. Les schémas qui déclarent draft-04, draft-06 ou une autre adresse de version sont signalés comme non pris en charge.
Que signifie un chemin comme $.users[0].email ?
C’est l’emplacement de la valeur en échec. $ est la racine de vos données JSON, .users est la propriété users, [0] est le premier élément de ce tableau (le comptage commence à 0) et .email est la propriété qu’il contient. Un chemin comme $.users[2].address.zip mène à la valeur de la même façon, pas à pas.
Pourquoi une propriété obligatoire manquante est-elle signalée sur l’objet parent ?
Parce que la propriété est absente et qu’il n’y a rien à désigner. L’erreur est affichée au chemin de l’objet qui devrait la contenir, par exemple $.users[0], avec la raison « La propriété obligatoire « email » est absente. » Ajoutez la propriété à cet objet et l’erreur disparaît.
Comment faire rejeter les propriétés en trop par le schéma (additionalproperties false) ?
Activez « Mode strict ». Il ajoute unevaluatedProperties: false à la racine et à chaque schéma de propriété ou d’élément qui décrit un objet : toute propriété que le schéma ne liste pas échoue alors avec « Propriété inattendue ». Les schémas qui définissent déjà additionalProperties ou unevaluatedProperties gardent leur choix.
Les formats comme email, date-time, uri et uuid sont-ils vérifiés ?
Oui. Le mot-clé « format » est vérifié : une adresse comme ana@ échoue sur une chaîne avec « format » : « email » et affiche « Doit respecter le format « email ». » Les formats courants sont couverts, dont email, date, date-time, time, uri, uuid, ipv4, ipv6 et hostname.
Peut-on tester JSON Schema avec un $ref vers un autre fichier ou une URL ?
Seulement à l’intérieur du même schéma, comme #/$defs/name ou #/definitions/name. Rien n’est téléchargé : une référence comme https://example.com/address.json est donc signalée comme une référence que le schéma ne définit pas. Copiez le schéma référencé dans votre $defs et faites pointer le $ref dessus.
Que signifie « Le schéma lui-même n’est pas valide » ?
Le schéma enfreint les règles des schémas JSON, par exemple avec « type » : « strng » ou un « minimum » écrit sous forme de texte. Le résultat liste les problèmes avec des chemins qui pointent dans le schéma. Les données ne sont pas vérifiées tant que le schéma n’est pas corrigé.
Ce JSON Schema validator online envoie-t-il mon schéma ou mes données quelque part ?
Non. Le schéma et les données sont vérifiés entièrement dans votre navigateur. Rien n’est envoyé ni enregistré, et aucun compte n’est nécessaire.
Recommandés
-
Support d'ordinateur portable pliable Amazon BasicsRemontez l’écran à hauteur des yeux pendant que vous faites défiler une longue liste d’erreurs.
-
Écran ultra-large Samsung ViewFinity 34"Le schéma à gauche, la réponse à droite, sans jongler entre les onglets.
-
Tableau blanc magnétique de bureau avec feutresDessinez le contrat et les champs en erreur avant de toucher au code.
Aide à garder les outils gratuits. ✨
Images non contractuelles. En tant que Partenaire Amazon, je réalise un bénéfice sur les achats remplissant les conditions requises.
