Comprueba que un documento XML esté bien formado, aplica una sangría legible y conserva atributos, namespaces, comentarios y contenido CDATA.
Revisar código XML
Local en tu navegador
0 caracteres
Pega XML o abre un archivo de hasta 5 MB.
XML procesado
Cómo formatear y validar XML
Pega el contenido o abre un archivo XML.
Selecciona la sangría que prefieras.
Usa Solo validar para comprobar la estructura o Formatear XML para organizarla.
Copia o descarga el resultado validado.
Ejemplo real
Una respuesta XML compacta de una integración puede reorganizarse para revisar con claridad productos, atributos, namespaces y valores antes de utilizarla.
Seguridad: la herramienta no ejecuta el XML y rechaza declaraciones DOCTYPE o entidades externas. No corrige errores automáticamente para evitar modificar tus datos.
Qué significa validar y formatear XML
La validación confirma que el documento está bien formado: un solo elemento raíz, etiquetas anidadas correctamente, atributos entre comillas y caracteres especiales escapados. No comprueba por sí sola que el archivo cumpla un XSD, una DTD o las reglas particulares de tu sistema.
La sangría no cambia el modelo
Formatear agrega saltos y espacios para facilitar la lectura. No ordena elementos ni modifica nombres. En documentos con contenido mixto, los espacios pueden ser significativos; por eso conviene comparar y probar el resultado con el consumidor real antes de reemplazar el original.
Namespaces, CDATA y entidades
Los prefijos de namespace distinguen vocabularios y no deberían eliminarse. CDATA contiene texto que no se interpreta como marcado, mientras que entidades como < representan caracteres. Convertir o reconstruir XML sin una convención puede perder esas diferencias.
Forma segura de diagnosticar
Conserva una copia exacta del XML recibido.
Valida sintaxis antes de minimizar o convertir.
Revisa el error y las etiquetas inmediatamente anteriores.
Confirma namespaces y esquema esperado.
Compara el documento procesado con una muestra conocida.
Ejemplos para encontrar errores de XML sin alterar los datos
Un documento puede verse ordenado y aun así ser inválido. Por ejemplo, <cliente><nombre>Ana</cliente> abre una etiqueta nombre que nunca se cierra. La herramienta detiene el proceso en lugar de inventar un cierre, porque no puede saber si faltaba </nombre> o si la estructura esperada era otra.
Caracteres reservados y atributos
El carácter & debe escribirse como & cuando forma parte del texto; los valores de atributos deben ir entre comillas; y un documento solo puede tener un elemento raíz. Una entrada como <precio moneda="USD">10 & impuestos</precio> sí conserva el símbolo como contenido.
Documento bien formado no significa documento correcto para tu sistema
<pedido><total>abc</total></pedido> está bien formado, pero una API puede exigir que total sea decimal. El formateador comprueba sintaxis; el XSD o las reglas de negocio determinan nombres, orden, tipos y elementos obligatorios. Mantener separadas ambas comprobaciones evita interpretar un resultado “válido” como aprobación completa.
Codificación y declaración XML
Si el documento declara encoding="UTF-8", el archivo descargado y el sistema que lo consume deben leerlo con esa codificación. Caracteres dañados como ñ suelen indicar que los mismos bytes fueron interpretados con otra codificación, no un problema de sangría.
Comprobación posterior al formato
Conserva la entrada original para poder compararla.
Valida antes de formatear y corrige únicamente el error identificado.
Comprueba el elemento raíz, atributos y namespaces.
Busca contenido mixto donde los espacios puedan ser significativos.
Prueba el resultado con el sistema o esquema que finalmente lo utilizará.
Caso práctico documentado
Estudio de caso: revisar un catálogo XML compacto
Situación ficticia: un sistema heredado exporta un catálogo válido en una sola línea. Antes de revisarlo, una persona necesita aplicar sangría sin cambiar identificadores, precios, atributos ni comentarios. También quiere confirmar que la herramienta rechace un documento mal cerrado en lugar de “repararlo” silenciosamente.
Objetivo y decisiones tomadas
Usar una sangría de dos espacios para facilitar la comparación entre versiones.
Conservar la declaración XML y el orden original de los nodos.
Mantener id y moneda como atributos.
Preservar el comentario <!--revisado-->.
No utilizar DOCTYPE, entidades externas ni información real.
Se analizó la entrada con DOMParser como application/xml.
Se aplicó la sangría solo después de confirmar que el documento estaba bien formado.
El resultado se analizó una segunda vez para comprobar que siguiera siendo XML válido.
Se contaron una raíz catalogo, cuatro elementos, dos atributos y un comentario.
Se compararon los valores antes y después: A-101, Monitor, USD y 249.90 permanecieron iguales.
Control negativo: XML mal cerrado
<catalogo><producto></catalogo>
El control se rechazó como XML no válido y no produjo una descarga. El texto exacto de línea y columna puede variar entre navegadores porque procede de su analizador XML; el comportamiento comprobado es que la herramienta no intenta corregir la estructura.
Límites: se comprueban sintaxis, estructura y conservación de este ejemplo; no conformidad con XSD ni reglas del negocio. Los documentos con DOCTYPE se rechazan por seguridad. La selección del caso sigue la metodología de Nexo Útil.