Plak, formatteer en vergelijk twee XML-documenten naast elkaar. Pretty-print, validatie en namespace-bewuste highlights ingebouwd.
Een gratis tool in je browser om twee XML-documenten te vergelijken. Plak een oude pom.xml links, de nieuwe rechts, en de wijzigingen lichten op per element. Niets verlaat je apparaat.
De diff zelf werkt op tekenniveau, en validatie loopt via de native DOMParser van de browser. De Format-knop in elk paneel herformatteert je XML met consistente inspringing. De live-validatie meldt slecht gevormde markup, niet-passende tags en kapotte entity-referenties terwijl je typt.
Heb je ooit in een code review een Spring application context van 4.000 regels opengeklapt om de ene bean te vinden waarvan het class-attribuut veranderde, dan is dit de tool die je daar in seconden brengt. Voor gewone tekst is onze tekst-diff-tool de juiste keuze. Voor gestructureerde data met sleutel/waarde-paren handelt JSON diff herordening van objecten netter af dan XML.
De diff draait op tekenniveau, en daarna verschuift een semantische naverwerkingspas de markeringen zodat ze op tagnamen, attributen en tekstinhoud landen in plaats van op willekeurige leestekens. Toevoegingen verschijnen in groen rechts, verwijderingen in rood links.
XML heeft een paar eigenaardigheden die de spec uitdrukkelijk noemt, en ze bijten allemaal als je twee bestanden als tekst vergelijkt. De XML 1.0-specificatie zegt dat de volgorde van attributen op een element niet significant is, dus voor een parser zijn <img src="a.png" alt="x"/> en <img alt="x" src="a.png"/> hetzelfde. Een tekst-diff markeert de wisseling toch. Zonder structurele vergelijking is er geen oplossing; de praktische workaround is beide kanten met dezelfde tool formatteren zodat de attribuutvolgorde stabiel blijft.
Namespaces voegen er nog een laag aan toe. Twee documenten die dezelfde URI aan verschillende prefixes binden zijn equivalent volgens Namespaces in XML 1.0, maar een tekst-diff schildert elke ns1:-tegen-ns2:-wissel als een wijziging. Formatteer beide kanten, lijn de prefix in een ervan uit, en diff opnieuw. Voor een pipeline die namespaces en attribuutvolgorde normaliseert vóór het diffen, kijk naar XSLT 3.0 of een canonicalisatiestap volgens Canonical XML.
Twee tekstpanelen, één diff. Geen account, geen upload, geen serverronde.
Plak de oude XML links, de nieuwe rechts. Of klik aan een van beide kanten op Uploaden om direct een .xml-, .pom-, .config- of .svg-bestand te laden. De Voorbeeld-knop vult beide panelen met een klein pom.xml-voorbeeld als je de tool eerst in actie wilt zien.
Klik op Format in elk paneel om pretty-te-printen met consistente inspringing en regelafbreking. Dat normaliseert whitespace zodat de diff echte inhoudsveranderingen markeert en niet de format-ruis van een Windows-CRLF-bestand tegen een Unix-LF-bestand. De validatie-badge wordt groen zodra DOMParser je document als well-formed accepteert.
Verwijderingen verschijnen met rode markering links, toevoegingen met groene rechts. Scroll je aan een kant, dan volgt de ander. De wijzigingstellers in elke header vertellen hoeveel onderscheiden bewerkingen de diff vond over elementnamen, attribuutwaarden en tekstinhoud.
Een Dependabot-PR tilt vijftien Maven-coördinaten in één klap op. Plak de oude pom.xml tegen de nieuwe om de daadwerkelijke upgrades te bevestigen: spring-boot-starter-web ging van 3.1.5 naar 3.2.1, jackson-databind van 2.15.3 naar 2.16.0, en een nieuwe micrometer-registry-prometheus-dependency is toegevoegd. De diff maakt de versiesprongen duidelijk zodat je de changelog kunt kruisen voor je goedkeurt.
Als een service na een refactor begint te falen, is de oorzaak vaak één bean waarvan het class-attribuut of een constructorargument in applicationContext.xml veranderde. Plak de werkende revisie tegen HEAD; de diff laat meteen de wisseling van class="com.acme.OldDataSource" naar class="com.acme.HikariDataSource" opduiken, en de omliggende <property>-tags vertellen welke configuratie meeverhuisde.
Een SOAP-integratie die gisteren nog werkte, geeft vandaag een Fault terug. Pak beide envelopes uit je pakketlogger of WireMock-opnames, gooi ze in de diff en het schuldige element springt eruit: een <currencyCode> die van USD naar een ontbrekend element ging, of een namespace-declaratie op de soap:Envelope die de upstream-service stilletjes wijzigde. Zonder side-by-side is dit in 800 regels XML niet te vinden.
Voor het uitbrengen van een release diff je AndroidManifest.xml tegen de vorige tag om wildgroei aan permissies te vangen. Een nieuwe <uses-permission android:name="android.permission.READ_CONTACTS"/> die met een third-party SDK-update binnenglipte, is precies waar de Play Store bij review op aanslaat. De diff brengt ook wijzigingen in <intent-filter>-elementen en android:exported-flags aan het licht, vaste aandachtspunten in security reviews.
Een feedlezer breekt omdat de bron is overgestapt van RSS 2.0 naar Atom 1.0, of een publisher heeft een nieuwe <media:thumbnail>-namespace toegevoegd. Bewaar een snapshot van de werkende feed, diff hem tegen de live versie en de structurele verandering verschijnt in seconden. Zelfde flow voor OPML-imports en podcastfeeds waar metadata op channel-niveau tussen elementen verhuisde.
Een .docx is gewoon een zip met XML erin. Pak beide versies van een contract uit, draai een diff op word/document.xml en je ziet de echte tekstbewerkingen zonder dat de wijzigingsmarkering van Word ertussen komt. Handig wanneer een paralegal een "schone" kopie terugstuurt die zogenaamd overeenkomt met een redline; de XML vertelt je welke alinea-elementen verschoven en welke run-niveau-opmaak veranderde.
Een korte spiek voor de parsing-randgevallen die deze tool het vaakst aan het licht brengt. Allemaal gegrond in de W3C XML-specificaties.
| Topic | What this tool does |
|---|---|
| Attribuutvolgorde | Niet significant volgens de XML 1.0-spec. <a x="1" y="2"/> is voor een parser gelijk aan <a y="2" x="1"/>. Een tekst-diff markeert de wissel; formatteer beide kanten om de volgorde stabiel te houden. |
| Namespaces | URI-gebonden, prefix-gealiast. Twee documenten die dezelfde URI aan verschillende prefixes binden, zijn equivalent. Zie Namespaces in XML 1.0. |
| CDATA-secties | Letterlijke tekst gewikkeld in <![CDATA[ ... ]]>. De parser interpreteert tags noch entiteiten erbinnen. De reeks ]]> mag niet voorkomen binnen een CDATA-blok. |
| Mixed content | Elementen mogen tekst, kindelementen en whitespace in willekeurige volgorde bevatten. <p>Hallo <b>wereld</b>!</p> is mixed content en de whitespace daar is significant. |
| Comments | <!-- comment -->. Mogen intern geen -- bevatten. Worden door de meeste processors verwijderd, maar in deze diff bewaard als tekst. |
| Encoding en BOM | Gedeclareerd via <?xml version="1.0" encoding="UTF-8"?>. Het UTF-8 BOM is een verborgen eerste teken; veelvoorkomende oorzaak van eentekens-fantoom-diffs op regel 1. |
| XML 1.0 vs 1.1 | Bijna iedereen gebruikt XML 1.0. Versie 1.1 voegt ondersteuning toe voor extra Unicode-controlekarakters in element-inhoud; in de praktijk zelden gezien. |
| Entity-referenties | Vijf ingebouwde: & < > ' ". Numerieke karakterreferenties als é voor letters met accent zijn ook geldig. Zelf-sluitend <br/> en expliciet <br></br> zijn equivalent. |
Ja, beide doen dat. Een tekst-diff vergelijkt tekens regel voor regel, dus herformatteren, attributen herordenen of whitespace binnen elementen verschijnen als verschillen ook al is het document logisch identiek. Klik in beide panelen eerst op Format en de diff focust op echte inhoudsveranderingen. Voor element-bomen met diep geneste kinderen is een structurele vergelijking via XSLT of Canonical XML de volgende stap; deze tool dekt 95% van de praktische XML-reviews zonder die complexiteit.
Nee, niet voor een XML-parser. De XML 1.0-spec zegt dat attribuutvolgorde niet significant is, dus <img src="a.png" alt="x"/> en <img alt="x" src="a.png"/> staan voor hetzelfde element. Een teken-diff markeert de herordening toch omdat hij de ruwe tekst ziet. De oplossing is beide kanten vóór het diffen met dezelfde tool formatteren zodat de attribuutvolgorde consistent is, of Canonical XML-normalisatie toepassen als je de pipeline beheert.
Namespaces zijn URI-gebaseerd, maar je bindt ze in het document aan korte prefixes. Twee bestanden die http://maven.apache.org/POM/4.0.0 aan verschillende prefixes binden zijn equivalent volgens de Namespaces in XML-spec, maar de tekst-diff zal elke prefix-wissel als wijziging markeren. De praktische oplossing is beide bestanden formatteren en aan beide kanten gelijke prefixes gebruiken. Voor automatische pipelines normaliseert een Canonical XML-pas dit weg.
Ja. CDATA-secties zijn enkel tekstinhoud met de instructie aan de parser om hem niet te interpreteren, dus <![CDATA[<b>raw</b>]]> wordt vergeleken als de letterlijke tekens binnenin. Lange CDATA-blokken (script-tags, embedded HTML, SQL) diffen netjes. De enige valkuil is dat je geen ]]> binnen een CDATA-sectie mag hebben; bevatten je data die reeks, dan moet de bron hem in twee CDATA-blokken splitsen, wat de diff toont zoals geschreven.
Gebruik XSLT als je XML wilt transformeren of vóór de vergelijking wilt normaliseren (kinderen sorteren, comments weggooien, namespaces canonicaliseren). Gebruik deze diff als je wilt zien wat er tussen twee specifieke bestanden veranderde. De twee zijn complementair: een XSLT-voorpas plus deze diff is een sterke flow voor luidruchtige machinaal gegenereerde XML. Voor de meeste code-reviews (pom.xml, AndroidManifest, application context) volstaat de diff alleen.
Een beetje. De declaratie <?xml version="1.0" encoding="UTF-8"?> hoort bij de documenttekst, dus UTF-8 wisselen voor UTF-16 verschijnt als één regel diff. Een UTF-8 byte order mark (BOM) helemaal aan het begin is een verborgen teken dat sommige editors weghalen en andere bewaren, een veelvoorkomende oorzaak van fantoom-diffs. Lijken twee bestanden identiek maar toont de diff een wijziging op regel 1 teken 0, vermoed dan het BOM en sla opnieuw op met een bekende encoding-instelling.
Je XML verlaat je browser nooit. Parser, formatter en diff draaien allemaal lokaal op je apparaat. Geen analytics op je invoer, geen logs, geen "behulpzame" cloud-rondrit. Parsing en validatie gebruiken de native DOMParser van de browser, en de spec die we volgen is W3C XML 1.0. Achtergrondlectuur over het formaat zelf staat op Wikipedia.