Un validateur XML vérifie si un document XML respecte les règles structurelles définies par la spécification XML 1.0 (recommandation W3C, cinquième édition). Au minimum, ce validateur XML confirme qu'un document est bien formé : il possède un unique élément racine, toutes les balises sont correctement imbriquées et fermées, les valeurs d'attributs sont entre guillemets, et les caractères réservés utilisent des entités prédéfinies. Un document qui ne satisfait pas l'une de ces règles provoquera des erreurs dans les parseurs XML, plutôt qu'une sortie silencieusement incorrecte.
La distinction entre bien-formé et valide est importante. Un document XML bien formé respecte les règles syntaxiques de la spécification XML elle-même. Un document XML valide va plus loin : il est également conforme aux contraintes définies dans un schéma externe, tel qu'un DTD (Document Type Definition), un XSD (XML Schema Definition) ou un schéma Relax NG. Cet outil vérifie le bien-formé, la première étape de validation et la plus courante. Sans elle, rien en aval ne peut fonctionner.
La validation XML détecte les erreurs avant qu'elles n'atteignent la production. Les balises non fermées, les noms d'éléments mal assortis, les esperluettes non échappées et les attributs en double figurent parmi les erreurs les plus fréquentes dans un XML édité à la main. Les parseurs de différents langages gèrent ces erreurs différemment : certains échouent silencieusement, d'autres retournent des résultats partiels, d'autres encore lèvent des exceptions. Passer votre XML dans un validateur en amont élimine cette ambiguïté et vous donne une réponse claire avec la localisation précise de l'erreur.
Pourquoi utiliser un validateur XML en ligne ?
Détecter les erreurs de syntaxe XML tôt évite les cascades de pannes dans les applications qui consomment des données XML. Un validateur dans le navigateur vous donne un retour immédiat sans avoir à installer des outils en ligne de commande ni à configurer des plugins d'IDE.
⚡
Détection instantanée des erreurs
Collez votre XML et obtenez un résultat valide/invalide avec la localisation exacte de l'erreur en moins d'une seconde. Pas d'attente pour les pipelines de build ni de configuration d'outil CLI.
🔒
Traitement respectueux de la confidentialité
L'analyse et la validation s'effectuent entièrement dans votre navigateur via l'API DOMParser. Votre XML ne quitte jamais votre machine et n'est jamais transmis à un serveur.
🎯
Rapport d'erreur précis
Voyez la ligne et la colonne exactes où la validation échoue, accompagnées d'une description de l'erreur. C'est plus rapide que de lire une trace de pile depuis un parseur dans votre code applicatif.
📋
Sans compte ni installation
Ouvrez la page, collez votre XML et consultez le résultat. Pas d'inscription, pas de logiciel à installer, pas d'extensions de navigateur.
Cas d'utilisation du validateur XML
Développement frontend
Validez des fichiers SVG et des fragments XHTML avant de les intégrer dans des composants React ou Vue. Une seule balise non fermée dans un SVG peut faire planter tout l'arbre de composants.
Ingénierie backend
Vérifiez les réponses SOAP, les charges utiles XML-RPC et les flux RSS/Atom provenant d'API tierces. Validez la réponse brute avant d'écrire la logique de désérialisation pour éviter de déboguer des exceptions de parseur en production.
DevOps et CI/CD
Vérifiez que les fichiers Maven pom.xml, .csproj ou les scripts de build Ant sont bien formés après des modifications automatisées. Une erreur de syntaxe dans une configuration de build peut faire échouer tout un pipeline avec un message d'erreur cryptique.
QA et tests
Validez les jeux de données XML de test et les fichiers de sortie attendus avant de lancer les tests d'intégration. Des fixtures malformées provoquent de faux négatifs qui font perdre du temps en débogage.
Ingénierie des données
Vérifiez les exports XML provenant de bases de données, de portails de données ouvertes gouvernementaux et de pipelines ETL. Valider la structure avant d'écrire des requêtes XPath ou des transformations XSLT évite de gaspiller des efforts sur des données sources cassées.
Apprentissage de XML
Les étudiants qui suivent les tutoriels XML ou XSLT du W3C peuvent coller des fichiers d'exercices dans le validateur pour vérifier leur syntaxe. Les messages d'erreur pointent vers le problème exact, ce qui accélère la boucle d'apprentissage.
Règles de bien-formé XML
La spécification XML 1.0 définit un ensemble strict de règles syntaxiques. Un document doit les respecter toutes pour être considéré comme bien formé. Le tableau ci-dessous liste chaque règle, ses exigences et un exemple correct. La plupart des erreurs de validation se ramènent à l'une de ces règles.
Règle
Exigence
Exemple correct
Single root element
Document must have exactly one root
<root>...</root>
Matched tags
Every opening tag needs a closing tag
<p>text</p>
Proper nesting
Tags must close in reverse order of opening
<a><b>...</b></a>
Quoted attributes
Attribute values must be in single or double quotes
<el attr="val"/>
Entity escaping
Reserved characters must use predefined entities
< > & " '
Case sensitivity
Tag names are case-sensitive: <A> is not </a>
<Book>...</Book>
No duplicate attributes
Each attribute name must appear once per element
<el a="1" b="2"/>
Valid XML declaration
If present, must be the very first line
<?xml version="1.0"?>
Bien formé vs. valide selon DTD vs. valide selon schéma
La validation XML comporte trois niveaux. Cet outil vérifie le premier (le bien-formé), qui est un prérequis pour les deux autres.
Bien formé
Respecte les règles syntaxiques XML 1.0 : racine unique, balises appariées, attributs entre guillemets, imbrication correcte. Tout parseur XML vérifie cela en premier. Si un document n'est pas bien formé, il n'est pas du XML du tout.
Valide selon DTD
Conforme à un Document Type Definition qui précise quels éléments et attributs sont autorisés, leur ordre et leur cardinalité. Les DTD sont déclarés en ligne ou via une référence DOCTYPE. La validation DTD est courante dans les systèmes anciens et XHTML.
Valide selon schéma (XSD / Relax NG)
Conforme à un XML Schema Definition (XSD) ou à un schéma Relax NG. Ces schémas prennent en charge les types de données (entier, date, URI), les espaces de noms et les modèles de contenu complexes. La validation XSD est standard dans les web services SOAP, les données de santé HL7 et l'intégration d'entreprise.
Exemples de code
Validez du XML par programmation dans différents langages. Chaque exemple vérifie le bien-formé et retourne le message d'erreur si le document est malformé.
import xml.etree.ElementTree as ET
def validate_xml(xml_string):
try:
ET.fromstring(xml_string)
return True, "Well-formed XML"
except ET.ParseError as e:
return False, str(e)
valid, msg = validate_xml('<root><item>hello</item></root>')
# → (True, "Well-formed XML")
valid, msg = validate_xml('<root><item>hello</root>')
# → (False, "mismatched tag: line 1, column 27")
# With lxml — also supports XSD schema validation
from lxml import etree
schema = etree.XMLSchema(etree.parse('schema.xsd'))
doc = etree.fromstring(b'<root><item>hello</item></root>')
schema.validate(doc) # → True or False
Go
package main
import (
"encoding/xml"
"fmt"
"strings"
)
func validateXML(raw string) error {
decoder := xml.NewDecoder(strings.NewReader(raw))
for {
_, err := decoder.Token()
if err != nil {
if err.Error() == "EOF" {
return nil
}
return err
}
}
}
func main() {
err := validateXML("<root><item>hello</item></root>")
fmt.Println(err) // → <nil>
err = validateXML("<root><item>hello</root>")
fmt.Println(err) // → XML syntax error: unexpected end element </root>
}
CLI (xmllint)
# Check well-formedness (part of libxml2, pre-installed on macOS/Linux)
xmllint --noout document.xml
# Exit code 0 = valid, non-zero = errors printed to stderr
# Validate against an XSD schema
xmllint --noout --schema schema.xsd document.xml
# Validate against a DTD
xmllint --noout --dtdvalid schema.dtd document.xml
# Validate from stdin
echo '<root><unclosed>' | xmllint --noout -
# → :1: parser error : Premature end of data in tag unclosed line 1
Questions fréquemment posées
Quelle est la différence entre un XML bien formé et un XML valide ?
Un XML bien formé respecte les règles syntaxiques de la spécification XML 1.0 : un seul élément racine, des balises appariées et correctement imbriquées, des attributs entre guillemets. Un XML valide va plus loin en étant également conforme à un schéma DTD ou XSD qui définit quels éléments, attributs et types de données sont autorisés. Un document peut être bien formé sans être valide s'il a une syntaxe correcte mais viole une contrainte de schéma.
Un document XML peut-il être valide sans être bien formé ?
Non. Le bien-formé est un prérequis à la validité. Si un document enfreint une règle syntaxique XML (balise non fermée, attribut sans guillemets, etc.), les parseurs ne peuvent pas en construire un arbre, donc la validation de schéma ne peut même pas démarrer. Corrigez d'abord les erreurs de bien-formé, puis vérifiez la conformité au schéma.
Quelles sont les erreurs de validation XML les plus courantes ?
Les cinq erreurs les plus fréquentes sont : des balises non fermées ou mal assorties, des esperluettes non échappées dans le contenu textuel, des valeurs d'attributs sans guillemets, un élément racine manquant, et une casse incorrecte dans les noms de balises (XML est sensible à la casse). La plupart sont causées par l'édition manuelle de XML ou par la concaténation de chaînes dans le code au lieu d'utiliser un sérialiseur XML approprié.
La validation XML est-elle la même chose que le linting XML ?
Elles se recoupent mais ne sont pas identiques. La validation vérifie si un document est conforme à la spécification XML (bien-formé) ou à un schéma (DTD/XSD). Le linting va généralement plus loin en signalant aussi les problèmes de style : indentation incohérente, déclarations d'espaces de noms inutilisées ou valeurs d'attributs par défaut redondantes. xmllint de libxml2 combine les deux : --noout vérifie le bien-formé, tandis que --schema ajoute la validation XSD.
En quoi la validation XML diffère-t-elle de la validation JSON ?
XML a une grammaire plus stricte et plus complexe que JSON. XML requiert des balises ouvrantes/fermantes appariées, prend en charge les attributs, les espaces de noms, le contenu mixte (texte et éléments ensemble) et dispose de plusieurs langages de schéma (DTD, XSD, Relax NG, Schematron). La validation JSON vérifie l'appariement des accolades et crochets, les clés entre guillemets et le placement des virgules. JSON Schema existe mais est plus simple que XSD. Un document XML est généralement 2 à 3 fois plus volumineux que le JSON équivalent pour les mêmes données.
Cet outil valide-t-il par rapport à des schémas XSD ou DTD ?
Cet outil vérifie uniquement le bien-formé : il confirme que votre XML respecte les règles syntaxiques de la spécification XML 1.0. Il ne valide pas par rapport à des schémas DTD ou XSD externes. Pour la validation de schéma, utilisez xmllint --schema en ligne de commande, ou lxml en Python, qui prend en charge à la fois XSD et Relax NG.
Pourquoi mon XML échoue-t-il à la validation alors qu'il semble correct ?
Les causes invisibles les plus fréquentes sont : un byte order mark (BOM) avant la déclaration XML, un caractère parasite après la balise de fermeture racine, une esperluette non échappée dans du contenu textuel (utilisez & à la place), ou un préfixe d'espace de noms utilisé mais jamais déclaré. Copiez votre XML dans un éditeur hexadécimal ou passez-le dans xmllint --noout pour obtenir le décalage en octets exact de l'erreur.