100 % local — vos données ne quittent jamais votre navigateur

Validateur XML — trouvez où ça casse

Vérifiez qu’un XML est bien formé : une racine, des balises fermées et imbriquées, des noms légaux. La première rupture est signalée là où elle se produit.

Instantané Privé Zéro cookie

Entrée XML

Sortie Result

Ce que vérifie cet outil

La bonne formation, terme de la spécification pour « syntaxiquement du XML » :

  • exactement un élément racine ;
  • chaque balise refermée, et refermée dans l’ordre où elle a été ouverte ;
  • les valeurs d’attributs entre guillemets, et aucun attribut répété sur un élément ;
  • des noms d’éléments et d’attributs qui commencent légalement et ne contiennent que des caractères légaux ;
  • des entités et des références numériques correctement écrites ;
  • aucun caractère interdit par XML.

Quand le document passe, vous obtenez son élément racine et sa taille. Sinon, vous obtenez la plainte de l’analyseur, avec la ligne et la colonne où il a renoncé.

Bien formé n’est pas valide

Ce sont deux mots différents dans la spécification XML, et les confondre coûte du temps.

vérifie
Bien forméla syntaxe — ce que fait cet outil
Validela syntaxe et un schéma : DTD, XSD, RELAX NG

Un document peut être irréprochablement bien formé et faux de toutes les manières qui comptent : un élément requis absent, un élément mal placé, <prix>banane</prix> là où un décimal était déclaré. Rien dans ce rapport ne dit le contraire, et aucun vérificateur de bonne formation ne le peut.

Si c’est une validation par schéma qu’il vous faut, il vous faut le schéma — et un outil qui le lit.

Le DOCTYPE n’est pas suivi

Une référence <!DOCTYPE> est une URL. La résoudre signifierait une requête sortante, qui dirait que ce document existe et qui le consulte. Rien ne quitte votre navigateur ici : le DOCTYPE est vérifié comme syntaxe, et laissé où il est.

C’est aussi ce qui rend les attaques par entité externe sans objet ici : une entité qui pointe quelque part n’est jamais résolue.

Une instruction de traitement en tête ne pose pas de problème

<?xml-stylesheet href="style.xsl"?> avant l’élément racine est du XML ordinaire et valide, et le rapport nomme le véritable élément racine plutôt que l’instruction.

La seule règle d’ordre imposée est celle de la spécification : la déclaration XML, si elle est là, vient en premier. Ailleurs, ce n’est pas une déclaration mais une instruction de traitement nommée xml, et ce nom est réservé.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

Cet outil vérifie-t-il mon document contre son XSD ou sa DTD ?
Non, et la distinction compte. **Bien formé** signifie que la syntaxe tient : un élément racine, chaque balise refermée dans le bon ordre, les valeurs d’attributs entre guillemets, des noms et des caractères légaux. **Valide** signifie qu’il obéit en plus à un schéma : les éléments requis présents, dans l’ordre déclaré, avec les types déclarés. Un document peut être parfaitement bien formé et violer son schéma à chaque ligne.
Pourquoi le DOCTYPE n’est-il pas suivi ?
Parce que le suivre, c’est aller chercher ce qu’il désigne. Une référence de DTD est une URL, et la résoudre enverrait une requête — révélant que le document existe, et à qui. Tout se passe ici dans votre navigateur et rien n’en sort : le DOCTYPE est vérifié comme syntaxe, et laissé tranquille pour le reste.
Il dit que ma déclaration doit venir en premier. Pourquoi ?
Parce que la déclaration XML n’est une déclaration qu’en première position ; ailleurs, c’est une instruction de traitement nommée `xml`, un nom que la spécification réserve. Un `<?xml-stylesheet?>` placé avant en est la cause habituelle. Remettez la déclaration en tête et le document passe.

Convertisseurs associés