Validateur de syntaxe JSON

1. 1Collez ou déposez du JSONCollez votre JSON dans l'éditeur, ou faites glisser un fichier .json, .jsonc, .json5, .ndjson, .geojson ou .webmanifest sur la zone de dépôt. Le JSON minifié comme le JSON formaté fonctionnent, et rien n'est téléversé nulle part.
2. 2Appuyez sur ValiderToutes les erreurs de syntaxe s'affichent d'un coup avec leur ligne, leur colonne et leur décalage en octets, et un curseur marque le caractère exact. Un JSON valide affiche à la place son type racine, sa taille et sa structure.
3. 3Lisez aussi les avertissementsLes clés dupliquées et les nombres qui perdent en précision sont du JSON parfaitement légal que tous les parseurs acceptent en silence. Ils apparaissent en avertissement avec un JSON Pointer vers chacun, car ce sont les fautes qui survivent jusqu'en production.
4. 4Corrigez, ou laissez l'outil corrigerCliquez sur un résultat pour y amener le curseur. Si le texte est du JSON5, du JSONC ou un dictionnaire Python plutôt que du JSON cassé, l'outil le dit et propose une copie réparée à appliquer ou à télécharger.

Vérifiez la validité de votre JSON en quelques secondes, avec la localisation exacte de l'erreur, le retour du parseur et un résumé structurel pour déboguer vite. Collez ou déposez du JSON et appuyez sur Valider pour obtenir immédiatement un succès ou un échec. Quand c'est valide, vous voyez le type racine, sa taille et un rapport complet de structure. Quand ça ne l'est pas, vous voyez toutes les erreurs d'un coup — chacune avec sa ligne, sa colonne, son décalage en octets et un curseur sous le caractère exact — plus les avertissements qu'aucun autre validateur ne vous montre : clés dupliquées et nombres qui changent discrètement de valeur à l'analyse. Tout s'exécute sur votre appareil : les charges utiles privées, les jetons et les schémas internes ne le quittent jamais.

• Toutes les erreurs, d'un coup — Un parseur s'arrête à la première faute. Celui-ci se resynchronise et continue : un fichier de quarante fautes coûte une passe, pas quarante.
• La même localisation partout — Ligne, colonne, décalage en octets et un curseur, calculés à partir des octets plutôt qu'extraits d'un message de navigateur — identiques sur Chrome, Firefox et Safari.
• Les fautes qui passent ailleurs — Les clés dupliquées et les nombres qui perdent en précision sont du JSON légal. C'est aussi ainsi que des données disparaissent en silence : elles sont signalées en avertissement.
• Schéma, dialectes et réparation — Vérifiez selon un JSON Schema, découvrez que votre fichier est en réalité du JSON5, et emportez une copie réparée en un clic.
• Coller ou déposer — Collez depuis le presse-papiers, déposez un fichier, ou parcourez. Réinitialiser efface l'entrée et le résultat ensemble.

La chose la plus utile qu'un validateur puisse vous dire, c'est où regarder — et c'est justement celle que la plupart des validateurs en ligne réussissent le moins bien. Ils rapportent ce que dit le parseur intégré du navigateur, et ces messages ne sont pas les mêmes partout.

Mesuré sur les trois moteurs réels : le parseur de Safari annonce « JSON Parse error: Expected '}' », sans position, sans ligne et sans colonne. Firefox donne une ligne et une colonne, mais aucun décalage. Seul Chrome donne les trois. Un validateur qui lit ces messages avec un motif fonctionne donc correctement sur un navigateur sur trois, et se dégrade en silence sur les autres.

• Ligne et colonne — Comptées en caractères, pas en octets, pour qu'une ligne commençant par un mot accentué n'annonce pas une colonne que votre éditeur conteste.
• Décalage en octets — Ce dont vous avez besoin quand le fichier est traité par un script plutôt que par un éditeur.
• Un curseur sous la faute — La ligne concernée, avec le caractère exact marqué. Sur une longue ligne, l'extrait est rogné autour de la faute et non au début.
• Un JSON Pointer — Où se situe la faute dans la structure du document — /users/3/email — et pas seulement dans le texte.

Un parseur JSON est fait pour produire une valeur : dès qu'il rencontre quelque chose d'inutilisable, il lève une exception et s'arrête. C'est le bon comportement pour un parseur et un comportement peu utile pour un validateur : corrigez la virgule manquante ligne 12, relancez, découvrez la clé sans guillemets ligne 40, relancez.

Ce validateur ne construit pas de valeur : il n'a rien à abandonner. Quand il rencontre un jeton qui ne va nulle part, il enregistre la faute et se resynchronise — traitant une virgule manquante comme si elle était là, fermant un conteneur qui a rencontré le mauvais crochet — et poursuit jusqu'à la fin du fichier. Le résultat, c'est toute la liste en une passe. Il cesse d'enregistrer à mille résultats, bien au-delà du point où un fichier vaut la peine d'être corrigé à la main plutôt que régénéré.

• Séparateurs manquants — Une virgule ou un deux-points absent est traité comme une faute de frappe et l'analyse continue, au lieu de se répercuter en erreur sur chaque membre suivant.
• Crochets mal appariés — Une fermeture qui ne correspond pas à son ouverture ferme quand même le conteneur, pour qu'un seul écart ne transforme pas le reste du fichier en bruit.
• Chaînes non terminées — Une chaîne à laquelle il manque un guillemet s'arrête à la fin de sa ligne au lieu d'avaler le reste du document.

JSON autorise la même clé deux fois dans un objet. La spécification se garde de dire ce qui devrait se passer, et la réponse pratique est que tous les parseurs courants gardent la dernière occurrence et écartent la première sans un mot.

Un fichier de configuration où une clé est définie deux fois est donc valide, et la moitié ne fait rien. Une réponse d'API fusionnée avec un champ répété est valide, et l'une des deux valeurs a disparu. Comme c'est légal, cela reste ici un avertissement et non un échec — le verdict doit s'accorder avec le parseur qui consommera réellement le fichier — mais c'est signalé avec un JSON Pointer vers chaque occurrence et le décalage de la première, pour que vous puissiez voir les deux.

• Exact, pas approximatif — Les clés sont comparées sur leur valeur décodée : une clé écrite "a" et la même écrite avec une séquence d'échappement sont correctement reconnues comme identiques.
• Par objet, pas par document — La même clé dans deux objets frères est normale et n'est pas signalée. Seule une répétition à l'intérieur d'un même objet l'est.
• À n'importe quelle profondeur — Un doublon vingt niveaux plus bas est trouvé, avec le pointeur qui y mène.

JSON n'impose aucune limite de taille ni de précision aux nombres, et presque tous les parseurs les lisent en flottant 64 bits. Au-delà de 9 007 199 254 740 991, un entier n'est plus représentable exactement : il est donc arrondi, en silence, sans erreur ni avertissement nulle part dans la chaîne.

Ce n'est pas un problème théorique. Les identifiants Snowflake, les identifiants à la Twitter, les numéros de commande et les montants comptables vivent tous dans cette plage, et le symptôme est un enregistrement introuvable parce que son identifiant est revenu décalé de quelques centaines. Le validateur examine chaque littéral numérique susceptible d'être touché et rapporte la valeur exacte à côté de celle qu'un parseur produira.

• Grands entiers — Comparés exactement, avec une arithmétique en précision arbitraire plutôt qu'avec la valeur flottante qui est justement en cause.
• Décimaux longs — Un décimal qui ne peut pas être retrouvé depuis le double qu'il devient est signalé avec la valeur à laquelle il sera réellement arrondi.
• Débordement et soupassement — 1e400 devient Infinity et 1e-400 devient zéro. Ni l'un ni l'autre n'est représentable en JSON, et aucun ne lève d'erreur ailleurs.
• Gratuit quand ça ne s'applique pas — Un littéral de quinze chiffres ou moins ne peut rien perdre : il est entièrement ignoré. Seuls ceux qui pourraient être touchés sont examinés.

Une grande partie des fichiers déclarés « JSON invalide » ne sont pas cassés du tout. Ils sont écrits dans un dialecte : JSONC, qui ajoute les commentaires et les virgules finales, ou JSON5, qui autorise en plus les clés sans guillemets, les apostrophes, les nombres hexadécimaux et NaN. Votre éditeur les lit sans broncher ; un parseur strict les refuse.

tsconfig.json, .eslintrc et la plupart des fichiers de réglages d'éditeurs sont du JSONC. Un dictionnaire copié depuis une session Python ressemble à du JSON mais utilise True, False et None. Plutôt que de déclarer tout cela cassé, le validateur nomme ce qu'il regarde, énumère les constructions responsables et propose une copie en JSON strict.

• Commentaires — Les commentaires de ligne et de bloc sont reconnus — et uniquement hors des chaînes, pour qu'une URL contenant une double barre oblique reste intacte.
• Virgules finales — Une virgule avant le crochet ou l'accolade de fermeture, signalée sur la virgule et non sur le crochet.
• Guillemets et clés nues — Chaînes entre apostrophes, clés sans guillemets, et les guillemets typographiques que laisse un traitement de texte.
• Littéraux non JSON — NaN et Infinity, nombres hexadécimaux, un plus ou un point décimal initial, et True, False et None de Python.

Chaque réparation vient d'un résultat que l'analyseur avait déjà localisé, jamais d'un motif appliqué à tout le document. Cette distinction compte plus qu'il n'y paraît : une expression régulière qui retire les commentaires supprime aussi la double barre oblique dans "https://example.com", et une qui retire les virgules finales supprime aussi la virgule dans "a, b,". L'analyseur sait quels octets étaient dans une chaîne et lesquels ne l'étaient pas : ni l'une ni l'autre de ces erreurs ne lui est accessible.

Le document réparé est ensuite revalidé avant d'être proposé, et s'il n'est toujours pas valide il est présenté comme une correction partielle, avec les fautes restantes énumérées. Un bouton « Corrigé » qui rend quelque chose qui ne s'analyse pas est pire que pas de bouton du tout.

• Ce qui est corrigé — Commentaires, virgules finales, apostrophes et guillemets typographiques, clés sans guillemets, nombres hexadécimaux, plus ou point initial, et True, False et None de Python.
• Ce qui est signalé comme lossy — NaN et Infinity n'ont pas d'écriture JSON. Ils deviennent null, et le changement est annoncé plutôt que fait en silence.
• Appliquer ou télécharger — Remettez le texte réparé directement dans l'éditeur, ou téléchargez-le en .json.

La syntaxe n'est que la moitié de la question. « Est-ce la bonne forme ? » est l'autre moitié, et c'est ce à quoi répond un JSON Schema. Collez-en un dans le panneau et le document est aussi vérifié par rapport à lui, chaque échec portant un JSON Pointer vers la valeur fautive et la ligne où elle se trouve.

Draft 2020-12 et draft-07 sont pris en charge, et le draft est lu depuis $schema — ou déduit quand le schéma ne le déclare pas, ce que ne font pas la plupart des schémas écrits avant 2020. Cette déduction compte : la forme tableau de items en draft-07 signifie autre chose en 2020-12, et lire l'une comme l'autre produit une réponse assurée et fausse au lieu d'une erreur.

• Tout le vocabulaire de validation — type, enum, const, les bornes numériques, longueur et motif des chaînes, contraintes de tableaux et d'objets, required et les mots-clés dépendants.
• Applicateurs — allOf, anyOf, oneOf, not, if/then/else, prefixItems, contains, propertyNames, ainsi que unevaluatedProperties et unevaluatedItems.
• Références — $ref, $defs, definitions, $anchor et la portée de $id se résolvent à l'intérieur du schéma que vous fournissez. Une référence vers un autre serveur est signalée par son nom et jamais téléchargée.
• format, tel que la spécification le définit — Une annotation par défaut, exactement comme le disent les deux drafts : un schéma avec "format": "email" ne refuse pas une adresse incorrecte, sauf si vous le demandez. Un interrupteur existe pour celles et ceux qui attendaient l'inverse.

Une valeur JSON par ligne : c'est ainsi que sont écrits les pipelines de logs, les exports BigQuery, les corps d'API en masse et les jeux d'entraînement. Lu comme un document JSON unique, un tel fichier produit exactement une erreur — du contenu excédentaire au début de la ligne deux — techniquement correcte et parfaitement inutile.

Le mode NDJSON valide chaque enregistrement séparément : une faute est rapportée contre l'enregistrement où elle se trouve. Le mode est proposé automatiquement quand un fichier ressemble à du délimité par lignes, et il est proposé plutôt qu'appliqué : un outil qui réinterprète votre entrée en silence est un outil sur lequel on ne peut pas raisonner.

• Résultats par enregistrement — Chaque faute porte son numéro d'enregistrement en plus de sa ligne et de sa colonne, et le nombre d'enregistrements valides est indiqué à côté.
• Le saut de ligne final — Tout producteur termine le dernier enregistrement par un saut de ligne. Cette dernière ligne vide n'est pas un enregistrement, et la traiter comme tel ajoute une erreur fantôme à presque tous les fichiers correctement écrits.
• Fins de ligne Windows — Un retour chariot laissé en fin d'enregistrement serait sinon un caractère de contrôle dans son dernier jeton — une erreur par ligne sur tout fichier écrit sous Windows.
• Enregistrements vides — Une ligne vide au milieu est signalée plutôt qu'ignorée. Le format n'a pas de séparateur : une ligne vide signifie qu'un enregistrement a été écrit vide.

Un fichier peut être du JSON parfaitement correct et échouer quand même à cause de trois octets invisibles. Une marque d'ordre des octets UTF-8 — ce qu'écrivent Out-File de PowerShell, StreamWriter de .NET et l'export « UTF-8 » d'Excel — se place devant l'accolade ouvrante, et un parseur strict signale un jeton inattendu en position 0 pour un document par ailleurs impeccable.

UTF-16 est pire, car c'est ce qu'écrit Windows PowerShell quand aucun encodage n'est précisé. Lu comme de l'UTF-8, cela ressemble à un octet NUL après chaque caractère, et l'erreur pointe vers quelque chose que personne ne peut voir. Les deux sont détectés et gérés ici, et l'encodage utilisé est indiqué pour que rien ne se passe à votre insu.

• UTF-8, avec ou sans marque — La marque est reconnue, retirée et signalée. Le document est validé comme si elle n'avait jamais été là.
• UTF-16, avec ou sans marque — Détecté par la marque, ou par l'endroit où tombent les octets NUL — les caractères structurels de JSON sont tous ASCII, donc le motif est concluant et non une supposition.
• Octets mal formés — Un octet qui n'est pas de l'UTF-8 valide est signalé en avertissement, pas en verdict : un navigateur le remplace avant qu'aucun parseur ne le voie, il ne peut donc pas invalider un document, mais il signifie que le fichier n'est pas dans l'encodage qu'il prétend.
• Pas du texte du tout — Une image renommée en .json est refusée pour ce motif, plutôt que de produire une erreur de syntaxe en position 0 pour quelque chose qui n'a jamais été du JSON.

Une seule passe sur les octets bruts, sans rien envoyer nulle part. Un document de 22 Mo est vérifié en environ 0,2 seconde sur un portable ordinaire — clés dupliquées et précision numérique comprises — parce que l'analyseur ne construit jamais les valeurs qu'il vérifie.

• Valide — Un verdict vert avec le type racine et la taille, et un rapport de structure : nœuds au total, profondeur maximale, nombre d'objets, de tableaux et de clés, la taille en lignes et en octets, et l'encodage utilisé.
• Invalide — Un verdict rouge avec toutes les erreurs énumérées — ligne, colonne, JSON Pointer, une description claire et un curseur sous le caractère exact — plus un lien vers le Formateur JSON.
• Avertissements — Clés dupliquées, nombres perdant en précision, séquences de substitution orphelines et imbrication anormalement profonde, chacun avec sa position. Ils ne changent pas le verdict, puisqu'un parseur les acceptera.
• Un dialecte, quand il y en a un — Si le texte est du JSON5, du JSONC ou un dictionnaire Python valide, c'est dit en toutes lettres, avec la possibilité de le convertir.

Un JSON invalide casse les API, les configurations et les pipelines de données, et il les casse généralement loin de l'endroit où se trouve la faute. Vérifier avant d'envoyer ou d'enregistrer attrape les fautes de frappe, les virgules manquantes, les virgules finales et les caractères non échappés pendant que le fichier est encore sous vos yeux. Les avertissements comptent davantage : une clé dupliquée ou un identifiant arrondi ne produit d'erreur nulle part, survit donc à tous les tests et réapparaît en données manquantes des semaines plus tard. Toutes les vérifications s'exécutent localement : vos données restent privées.

• Attraper les erreurs tôt — Trouvez les problèmes de syntaxe avant qu'ils ne cassent un déploiement ou une intégration, avec la ligne et la colonne exactes plutôt qu'une trace venue d'un serveur.
• Attraper les silencieuses — Les clés dupliquées et la perte de précision passent tous les parseurs et tous les validateurs existants. Ce sont les fautes qui atteignent la production.
• Vérifier la forme, pas seulement la syntaxe — Un JSON Schema transforme « ça s'analyse » en « c'est ce que le consommateur attend », avant que le consommateur ne le découvre.
• Confidentialité — Rien n'est téléversé. Réponses d'API privées, jetons d'accès et schémas internes se vérifient sans quitter votre appareil.

Tout ce qui décide de la validité d'un document est gratuit. Toutes les erreurs plutôt que la première, les clés dupliquées, les avertissements de précision, JSON Schema, la détection de dialecte, la réparation, le mode NDJSON et le rapport complet de structure sont disponibles gratuitement. Pro ajoute de l'échelle, pas des fonctionnalités.

• Gratuit — Un fichier à la fois, jusqu'à 25 Mo, plus le collage sans limite. Toutes les vérifications, tous les avertissements, la validation par schéma et la réparation incluses.
• Pro — Jusqu'à 100 fichiers en une passe, des tailles limitées par votre appareil et non par nous, un ZIP de rapports pour tout le lot, et des rapports JSON et CSV lisibles par une machine pour une étape de CI ou un ticket.
• Pourquoi 25 Mo — C'est une mesure, pas un chiffre rond. Un document de 22 Mo est vérifié en environ 0,2 seconde : la limite se place là où un mobile de milieu de gamme reste à l'aise.

• Formateur JSON
• Minifier JSON
• Visionneuse JSON
• Comparer JSON
• Trier les clés JSON
• Supprimer des clés JSON