Collez, formatez et comparez deux documents XML côte à côte. Pretty-print, validation et surlignage tenant compte des namespaces inclus.
Un outil gratuit dans le navigateur pour comparer deux documents XML. Collez un ancien pom.xml à gauche, le nouveau à droite, et les changements s'allument élément par élément. Rien ne quitte votre machine.
Le diff lui-même est au niveau caractère, et la validation passe par le DOMParser natif du navigateur. Le bouton Format de chaque panneau reformate votre XML avec une indentation cohérente. La validation en direct signale le balisage mal formé, les balises non fermées et les références d'entités cassées au fur et à mesure.
Si vous avez déjà ouvert un application context Spring de 4 000 lignes en revue de code en cherchant le seul bean dont l'attribut class a changé, c'est l'outil qui vous y mène en quelques secondes. Pour de la prose simple, notre outil de diff de texte est le bon choix. Pour des données structurées avec des paires clé/valeur, JSON diff gère le réordonnancement d'objets plus proprement que XML.
Le diff tourne au niveau caractère, puis une passe sémantique de post-traitement déplace les surlignages pour qu'ils tombent sur des noms de balise, des attributs et du contenu textuel plutôt que sur de la ponctuation au hasard. Les insertions apparaissent en vert dans le panneau de droite, les suppressions en rouge dans celui de gauche.
XML a quelques particularités que la spec mentionne, et qui mordent toutes quand vous comparez deux fichiers en tant que texte. La spécification XML 1.0 dit que l'ordre des attributs sur un élément n'est pas significatif, donc <img src="a.png" alt="x"/> et <img alt="x" src="a.png"/> sont identiques pour un parser. Un diff de texte signalera quand même la permutation. Pas de remède sans comparaison structurelle ; le contournement pratique consiste à formater les deux côtés avec le même outil pour que l'ordre des attributs reste stable.
Les namespaces ajoutent une couche supplémentaire. Deux documents qui lient le même URI à des préfixes différents sont équivalents selon Namespaces in XML 1.0, mais un diff de texte marquera chaque échange ns1: contre ns2: comme un changement. Formatez les deux côtés, alignez le préfixe sur l'un d'eux et relancez le diff. Pour une pipeline qui normalise les namespaces et l'ordre des attributs avant le diff, regardez XSLT 3.0 ou une étape de canonicalisation suivant Canonical XML.
Deux panneaux de texte, un diff. Pas d'inscription, pas d'envoi, pas d'aller-retour serveur.
Collez l'ancien XML à gauche, le nouveau à droite. Ou cliquez sur Téléverser sur l'un des côtés pour charger directement un fichier .xml, .pom, .config ou .svg. Le bouton Exemple remplit les deux panneaux avec un petit pom.xml si vous voulez d'abord voir l'outil en action.
Cliquez sur Format sur chaque panneau pour pretty-print avec une indentation et des sauts de ligne cohérents. Cela normalise les espaces pour que le diff montre les vrais changements de contenu, pas le bruit de format venant d'un fichier Windows CRLF face à un fichier Unix LF. Le badge de validation passe au vert quand DOMParser accepte votre document comme bien formé.
Les suppressions apparaissent surlignées en rouge à gauche, les insertions en vert à droite. Faites défiler un côté, l'autre suit. Les compteurs de changements dans chaque en-tête vous disent combien d'éditions distinctes le diff a trouvées sur les noms d'éléments, les valeurs d'attributs et le contenu textuel.
Une PR Dependabot bouge quinze coordonnées Maven d'un coup. Collez l'ancien pom.xml face au nouveau pour confirmer les vraies montées : spring-boot-starter-web est passé de 3.1.5 à 3.2.1, jackson-databind de 2.15.3 à 2.16.0, et une nouvelle dépendance micrometer-registry-prometheus a été ajoutée. Le diff rend les sauts de version évidents pour que vous puissiez recouper le changelog avant d'approuver.
Quand un service se met à échouer après un refactor, la cause est souvent un seul bean dont l'attribut class ou un argument de constructeur a changé dans applicationContext.xml. Collez la révision qui marchait face à HEAD ; le diff fait remonter immédiatement class="com.acme.OldDataSource" contre class="com.acme.HikariDataSource", et les balises <property> autour vous disent quelle configuration a bougé avec.
Une intégration SOAP qui marchait hier renvoie un Fault aujourd'hui. Capturez les deux enveloppes depuis votre logger de paquets ou des enregistrements WireMock, déposez-les dans le diff, et l'élément fautif saute aux yeux : un <currencyCode> passé de USD à un élément manquant, ou une déclaration de namespace sur le soap:Envelope que le service amont a discrètement changée. Sans vue côte à côte, retrouver ça dans 800 lignes de XML est sans espoir.
Avant de publier une release, faites un diff d'AndroidManifest.xml contre le tag précédent pour repérer la dérive des permissions. Un nouveau <uses-permission android:name="android.permission.READ_CONTACTS"/> qui s'est glissé avec la mise à jour d'un SDK tiers est exactement le genre de chose que le Play Store relèvera en revue. Le diff fait aussi ressortir les changements sur les éléments <intent-filter> et les flags android:exported, points fréquents en revue de sécurité.
Un lecteur de flux casse parce que la source est passée de RSS 2.0 à Atom 1.0, ou parce qu'un éditeur a ajouté un nouveau namespace <media:thumbnail>. Sauvegardez un instantané du flux qui marchait, faites le diff face au flux en ligne, et le changement structurel apparaît en quelques secondes. Même flux pour les imports OPML et les flux de podcasts où les métadonnées au niveau du channel ont bougé entre éléments.
Un .docx n'est qu'une archive zip avec du XML dedans. Décompressez les deux versions d'un contrat, lancez un diff sur word/document.xml, et vous voyez les vraies éditions de texte sans que le balisage de suivi des modifications de Word ne vienne s'interposer. Utile quand un parajuriste renvoie une copie « propre » censée correspondre à un redline ; le XML vous dit quels éléments de paragraphe ont bougé et quel formatage au niveau du run a changé.
Un court pense-bête sur les cas limites de parsing que cet outil fait remonter le plus souvent. Tout est ancré dans les spécifications XML du W3C.
| Topic | What this tool does |
|---|---|
| Ordre des attributs | Non significatif selon la spec XML 1.0. <a x="1" y="2"/> équivaut à <a y="2" x="1"/> pour un parser. Un diff de texte marquera la permutation ; formatez les deux côtés pour stabiliser l'ordre. |
| Namespaces | Basés sur URI, aliasés par préfixe. Deux documents qui lient le même URI à des préfixes différents sont équivalents. Voir Namespaces in XML 1.0. |
| Sections CDATA | Texte littéral entouré de <![CDATA[ ... ]]>. Le parser n'interprète ni balises ni entités à l'intérieur. La séquence ]]> ne peut pas apparaître dans un bloc CDATA. |
| Contenu mixte | Les éléments peuvent contenir du texte, des éléments enfants et des espaces dans n'importe quel ordre. <p>Bonjour <b>monde</b>!</p> est du contenu mixte et les espaces y sont significatifs. |
| Commentaires | <!-- commentaire -->. Ne peuvent pas contenir -- en interne. Supprimés par la plupart des processeurs mais conservés comme texte dans ce diff. |
| Encodage et BOM | Déclaré via <?xml version="1.0" encoding="UTF-8"?>. Le BOM UTF-8 est un premier caractère caché ; cause habituelle de diffs fantômes d'un caractère à la ligne 1. |
| XML 1.0 vs 1.1 | Quasiment tout le monde utilise XML 1.0. La version 1.1 ajoute la prise en charge de caractères de contrôle Unicode supplémentaires dans le contenu d'élément ; rare en pratique. |
| Références d'entités | Cinq prédéfinies : & < > ' ". Les références numériques comme é pour les lettres accentuées sont aussi valides. <br/> auto-fermant et <br></br> explicite sont équivalents. |
Oui, les deux apparaîtront. Un diff de texte compare les caractères ligne à ligne, donc reformater, réordonner les attributs ou les espaces à l'intérieur des éléments apparaissent comme des différences même quand le document est logiquement identique. Cliquez d'abord sur Format dans les deux panneaux et le diff se concentre sur les vrais changements de contenu. Pour des arbres d'éléments avec des enfants très imbriqués, une comparaison structurelle via XSLT ou Canonical XML est l'étape supérieure ; cet outil couvre 95 % des revues XML pratiques sans cette complexité.
Non, pas pour un parser XML. La spec XML 1.0 dit que l'ordre des attributs n'est pas significatif, donc <img src="a.png" alt="x"/> et <img alt="x" src="a.png"/> représentent le même élément. Un diff de caractères marquera quand même la permutation parce qu'il voit le texte brut. Le remède est de formater les deux côtés avec le même outil pour que l'ordre des attributs soit cohérent avant le diff, ou d'appliquer une normalisation Canonical XML si vous contrôlez la pipeline.
Les namespaces sont basés sur des URI, mais on les lie à de courts préfixes dans le document. Deux fichiers qui lient http://maven.apache.org/POM/4.0.0 à des préfixes différents sont équivalents selon la spec Namespaces in XML, mais le diff de texte marquera chaque permutation de préfixe comme un changement. Le remède pratique est de formater les deux fichiers et d'utiliser des préfixes identiques des deux côtés. Pour des pipelines automatisées, une passe Canonical XML normalise tout ça.
Oui. Les sections CDATA sont juste du contenu textuel avec une consigne au parser de ne pas l'interpréter, donc <![CDATA[<b>raw</b>]]> se compare comme les caractères littéraux à l'intérieur. De longs blocs CDATA (balises script, HTML embarqué, SQL) se diffent proprement. Le seul piège est que vous ne pouvez pas avoir ]]> à l'intérieur d'une section CDATA ; si vos données contiennent cette séquence, la source doit la couper en deux blocs CDATA, ce que le diff montrera tel quel.
Utilisez XSLT quand vous voulez transformer du XML ou le normaliser avant comparaison (trier les enfants, supprimer les commentaires, canonicaliser les namespaces). Utilisez ce diff quand vous voulez voir ce qui a changé entre deux fichiers précis. Les deux sont complémentaires : une passe préalable XSLT plus ce diff est un bon flux pour du XML bruyant généré par machine. Pour la plupart des revues de code (pom.xml, AndroidManifest, application context), le diff seul suffit.
Un peu. La déclaration <?xml version="1.0" encoding="UTF-8"?> fait partie du texte du document, donc remplacer UTF-8 par UTF-16 apparaît comme un diff sur une ligne. Une marque d'ordre des octets (BOM) UTF-8 tout au début est un caractère caché que certains éditeurs retirent et d'autres conservent, source habituelle de diffs fantômes. Si deux fichiers semblent identiques mais que le diff montre un changement à la ligne 1 caractère 0, suspectez le BOM et réenregistrez avec un réglage d'encodage connu.
Votre XML ne quitte jamais votre navigateur. Le parser, le formateur et le diff tournent tous sur votre machine, en local. Pas d'analyse de votre saisie, pas de logs, pas d'aller-retour cloud « pour vous aider ». Le parsing et la validation utilisent le DOMParser natif du navigateur, et la spec que nous suivons est W3C XML 1.0. Pour aller plus loin sur le format, voyez Wikipédia.