Pega, formatea y compara dos documentos XML lado a lado. Pretty-print, validación y resaltado consciente de namespaces incluidos.
Una herramienta gratuita en el navegador para comparar dos documentos XML. Pega un pom.xml antiguo a la izquierda y el nuevo a la derecha, y los cambios se iluminan elemento por elemento. Nada sale de tu máquina.
El diff es a nivel de carácter, y la validación va por el DOMParser nativo del navegador. El botón Format de cada panel reformatea tu XML con sangría consistente. La validación en vivo señala marcado mal formado, etiquetas no emparejadas y referencias a entidades rotas mientras escribes.
Si alguna vez has abierto un application context de Spring de 4.000 líneas en una revisión de código intentando encontrar el único bean cuyo atributo class cambió, esta es la herramienta que te lleva ahí en segundos. Para prosa simple, nuestra herramienta de diff de texto es la opción correcta. Para datos estructurados con pares clave/valor, JSON diff maneja el reordenamiento de objetos con más limpieza que XML.
El diff corre a nivel de carácter, y luego una pasada de post-procesamiento semántico desplaza los resaltados para que aterricen sobre nombres de etiqueta, atributos y contenido de texto en lugar de puntuación arbitraria. Las inserciones se ven en verde a la derecha, las eliminaciones en rojo a la izquierda.
XML tiene unas cuantas peculiaridades que la spec señala, y todas dan guerra al comparar dos archivos como texto. La especificación XML 1.0 dice que el orden de los atributos en un elemento no es significativo, así que <img src="a.png" alt="x"/> y <img alt="x" src="a.png"/> son lo mismo para un parser. Un diff de texto seguirá señalando el cambio. No hay arreglo sin una comparación estructural; la solución práctica es formatear ambos lados con la misma herramienta para que el orden de atributos quede estable.
Los namespaces añaden otra capa. Dos documentos que vinculan el mismo URI a prefijos distintos son equivalentes según Namespaces in XML 1.0, pero un diff de texto pintará cada cambio de ns1: a ns2: como una modificación. Formatea ambos lados, ajusta el prefijo en uno de ellos y vuelve a hacer diff. Para una pipeline que normalice namespaces y orden de atributos antes del diff, mira XSLT 3.0 o un paso de canonicalización según Canonical XML.
Dos paneles de texto, un diff. Sin registro, sin subida, sin viaje al servidor.
Pega el XML antiguo a la izquierda, el nuevo a la derecha. O pulsa Subir en cualquiera de los lados para cargar directamente un archivo .xml, .pom, .config o .svg. El botón Ejemplo rellena ambos paneles con un pequeño pom.xml si quieres ver primero la herramienta en acción.
Pulsa Format en cada panel para imprimir con sangría y saltos de línea consistentes. Esto normaliza el espaciado para que el diff resalte cambios de contenido reales y no ruido de formato (un archivo Windows con CRLF frente a uno Unix con LF). El indicador de validación se pone verde cuando DOMParser acepta tu documento como bien formado.
Las eliminaciones aparecen en rojo a la izquierda, las inserciones en verde a la derecha. Si haces scroll en un lado, el otro le sigue. Los contadores de cambios en cada cabecera te dicen cuántas ediciones distintas encontró el diff entre nombres de elemento, valores de atributo y contenido de texto.
Un PR de Dependabot sube quince coordenadas de Maven a la vez. Pega el pom.xml viejo contra el nuevo para confirmar las actualizaciones reales: spring-boot-starter-web pasó de 3.1.5 a 3.2.1, jackson-databind de 2.15.3 a 2.16.0, y se añadió una nueva dependencia micrometer-registry-prometheus. El diff hace evidentes los saltos de versión para que puedas contrastar el changelog antes de aprobar.
Cuando un servicio empieza a fallar tras una refactorización, la causa suele ser un único bean cuyo atributo class o argumento de constructor cambió en applicationContext.xml. Pega la revisión que funcionaba contra HEAD; el diff saca al instante el cambio entre class="com.acme.OldDataSource" y class="com.acme.HikariDataSource", y las etiquetas <property> alrededor te dicen qué configuración se movió con él.
Una integración SOAP que ayer funcionaba hoy devuelve un Fault. Captura ambos sobres desde tu logger de paquetes o grabaciones de WireMock, pásalos al diff y el elemento ofensor salta a la vista: un <currencyCode> que pasó de USD a un elemento ausente, o una declaración de namespace en el soap:Envelope que el servicio remoto cambió en silencio. Sin una vista lado a lado, encontrar esto en 800 líneas de XML es imposible.
Antes de publicar una release, haz diff de AndroidManifest.xml contra el tag anterior para detectar permisos que se cuelan. Un nuevo <uses-permission android:name="android.permission.READ_CONTACTS"/> que entró con la actualización de un SDK de terceros es justo lo que la Play Store marcará en revisión. El diff también saca a la luz cambios en elementos <intent-filter> y flags android:exported, focos habituales de revisiones de seguridad.
Un lector de feeds se rompe porque la fuente cambió de RSS 2.0 a Atom 1.0, o un publicador añadió un nuevo namespace <media:thumbnail>. Guarda una instantánea del feed que funcionaba, comparalo contra el actual y el cambio estructural aparece en segundos. Mismo flujo para importaciones OPML y feeds de podcasts donde los metadatos a nivel de canal se movieron entre elementos.
Un .docx es solo un zip con XML dentro. Descomprime ambas versiones de un contrato, haz un diff de word/document.xml y verás las ediciones reales del texto sin que el marcado de control de cambios de Word se interponga. Útil cuando un asistente legal devuelve una copia "limpia" que supuestamente coincide con un redline; el XML te dice qué elementos de párrafo se movieron y qué formato a nivel de run cambió.
Una breve chuleta de los casos límite de parseo que esta herramienta saca a la luz con más frecuencia. Todo está fundamentado en las especificaciones XML del W3C.
| Topic | What this tool does |
|---|---|
| Orden de atributos | No es significativo según la spec XML 1.0. <a x="1" y="2"/> equivale a <a y="2" x="1"/> para un parser. Un diff de texto marcará el cambio; formatea ambos lados para mantener el orden estable. |
| Namespaces | Vinculados por URI, con alias por prefijo. Dos documentos que vinculan el mismo URI a prefijos distintos son equivalentes. Ver Namespaces in XML 1.0. |
| Secciones CDATA | Texto literal envuelto en <![CDATA[ ... ]]>. El parser no interpreta etiquetas ni entidades dentro. La secuencia ]]> no puede aparecer dentro de un bloque CDATA. |
| Contenido mixto | Los elementos pueden contener texto, elementos hijos y espacios en cualquier orden. <p>Hola <b>mundo</b>!</p> es contenido mixto y los espacios ahí son significativos. |
| Comentarios | <!-- comentario -->. No pueden contener -- internamente. Eliminados por la mayoría de procesadores pero conservados como texto en este diff. |
| Codificación y BOM | Declarada con <?xml version="1.0" encoding="UTF-8"?>. El BOM UTF-8 es un primer carácter oculto; causa habitual de diferencias fantasma de un carácter en la línea 1. |
| XML 1.0 vs 1.1 | Casi todo el mundo usa XML 1.0. La versión 1.1 añade soporte para caracteres de control Unicode adicionales en el contenido de elementos; raro de ver en la práctica. |
| Referencias a entidades | Cinco predefinidas: & < > ' ". Las referencias numéricas como é para letras acentuadas también son válidas. <br/> autocerrado y <br></br> explícito son equivalentes. |
Sí, ambos aparecerán. Un diff de texto compara caracteres línea por línea, así que reformatear, reordenar atributos o el espaciado dentro de los elementos aparece como diferencia aunque el documento sea lógicamente idéntico. Pulsa Format en ambos paneles primero y el diff se centra en cambios de contenido reales. Para árboles de elementos con hijos muy anidados, una comparación estructural vía XSLT o Canonical XML es el siguiente nivel; esta herramienta resuelve el 95% de las revisiones prácticas de XML sin esa complejidad.
No, no para un parser XML. La spec XML 1.0 dice que el orden de atributos no es significativo, así que <img src="a.png" alt="x"/> y <img alt="x" src="a.png"/> representan el mismo elemento. Un diff de caracteres seguirá marcando el reordenamiento porque ve el texto crudo. La solución es formatear ambos lados con la misma herramienta para que el orden de atributos sea consistente antes del diff, o aplicar normalización de Canonical XML si controlas la pipeline.
Los namespaces se basan en URIs, pero los enlazas a prefijos cortos en el documento. Dos archivos que vinculan http://maven.apache.org/POM/4.0.0 a prefijos distintos son equivalentes según la spec de Namespaces in XML, pero el diff de texto marcará cada cambio de prefijo como una diferencia. La solución práctica es formatear ambos archivos y usar prefijos coincidentes en los dos lados. Para pipelines automatizados, una pasada de Canonical XML normaliza esto.
Sí. Las secciones CDATA son simplemente contenido textual con la indicación al parser de no interpretarlo, así que <![CDATA[<b>raw</b>]]> se compara como los caracteres literales que hay dentro. Bloques CDATA largos (etiquetas script, HTML embebido, SQL) hacen diff sin problemas. La única pega es que no puedes tener ]]> dentro de una sección CDATA; si tus datos contienen esa secuencia, la fuente debe partirla en dos bloques CDATA, lo que el diff mostrará tal cual está escrito.
Usa XSLT cuando quieras transformar XML o normalizarlo antes de comparar (ordenar hijos, eliminar comentarios, canonicalizar namespaces). Usa este diff cuando quieras ver qué cambió entre dos archivos concretos. Las dos cosas son complementarias: una pasada previa de XSLT más este diff es un buen flujo para XML ruidoso generado por máquina. Para la mayoría de revisiones de código (pom.xml, AndroidManifest, application context) basta con el diff.
Un poco. La declaración <?xml version="1.0" encoding="UTF-8"?> es parte del texto del documento, así que cambiar UTF-8 por UTF-16 aparece como un diff de una línea. Una marca de orden de bytes (BOM) UTF-8 al inicio es un único carácter oculto que algunos editores quitan y otros conservan, fuente habitual de diferencias fantasma. Si dos archivos parecen idénticos pero el diff muestra un cambio en la línea 1 carácter 0, sospecha del BOM y vuelve a guardar con un ajuste de codificación conocido.
Tu XML nunca sale de tu navegador. El parser, el formateador y el diff se ejecutan en tu máquina, en local. Sin analítica de tu input, sin logs, sin viajes al cloud "para ayudar". El parseo y la validación usan el DOMParser nativo del navegador, y la spec que seguimos es W3C XML 1.0. Para lectura de fondo sobre el formato, en Wikipedia.