Validador XML
Buena formación y validación con esquema. No se sube nada.
Todo se ejecuta en esta pestaña. Nada de lo que pegues se sube, se registra ni se envía a ningún sitio. Abre el panel de red y compruébalo.
Pega un documento arriba y se comprueba mientras escribes. Cada problema se informa con la línea, la columna y qué escribir en su lugar, y todos a la vez en lugar de parar en el primero. No se sube nada: el analizador, el motor de esquemas y el editor se ejecutan dentro de esta pestaña, y puedes confirmarlo abriendo el panel de red de tu navegador y viendo cómo sigue vacío mientras trabajas.
Eso último no es una frase de marketing. Varias de las herramientas que aparecen en esta búsqueda envían tu documento a un servidor para comprobarlo. Una de ellas te pide marcar una casilla confirmando que entiendes que tus datos se almacenan en sus servidores y pueden conservarse. Si estás depurando un envelope SOAP con un token de portador, o un archivo de configuración con una cadena de conexión, eso es un problema real y es la razón por la que existe este sitio.
El validador realiza las dos comprobaciones que define XML, y las mantiene separadas, porque responden a preguntas distintas y casi todas las herramientas gratuitas las confunden.
Bien formado y válido no son la misma comprobación
Un documento está bien formado cuando su sintaxis es correcta: las etiquetas se cierran y se anidan bien, hay exactamente un elemento raíz, los caracteres especiales están escapados y los valores de atributo van entrecomillados. Esto no necesita nada más que el propio documento, así que se ejecuta automáticamente mientras escribes.
Un documento es válido cuando está bien formado y además cumple un esquema: los elementos que deben estar están, en el orden correcto y con los tipos correctos. Esto necesita un segundo archivo, un XSD o una DTD, así que es una acción aparte que lanzas deliberadamente.
La distinción importa porque "XML válido" es lo que dice la gente cuando quiere decir cualquiera de las dos cosas. Si un sistema ha rechazado tu documento diciendo que no era válido, seguramente ejecutó una comprobación de esquema, y un tick verde de un comprobador de buena formación no te dirá por qué falló. El panel de resultados de aquí siempre dice qué comprobación ha hecho.
- Bien formado pero no válido: <note><to>Alice</to></note> frente a un esquema que además exige <from>. La sintaxis es perfecta; el contenido está mal.
- Válido pero no bien formado: imposible. La validez incluye la buena formación, y por eso la comprobación de esquema se niega a ejecutarse hasta que la sintaxis está limpia.
Qué te dicen realmente los errores
La carencia de esta categoría no está en las funciones, está en los mensajes de error. Los analizadores de los navegadores paran en el primer problema y lo expresan para quien escribió el analizador. Firefox informa de un ampersand sin escapar como "EntityRef: expecting ';'". libxml2 llama a lo mismo "xmlParseEntityRef: no name". Ninguno menciona ampersands, escapado, ni la cadena de consulta de una URL que casi con seguridad lo ha provocado.
Cada diagnóstico de aquí nombra el fallo con las palabras que usarías tú, da la posición exacta y propone la solución. Al pulsar el marcador línea:columna el cursor salta ahí. Cuando un error es lo bastante común como para merecerlo, hay un enlace a una página que explica qué lo causa, con el mensaje equivalente de otros seis analizadores para que lo reconozcas la próxima vez que lo reporte tu build.
Documentos grandes, y documentos hostiles
El análisis se ejecuta en un Web Worker, así que la interfaz sigue respondiendo mientras se examina un documento grande. Un archivo de 100 KB se comprueba en unos 20 milisegundos, 1 MB en unos 110 y 10 MB en algo más de un segundo. Por encima de 20 MB la herramienta se niega: todo vive en la memoria de esta pestaña, y un documento así de grande deja el navegador inservible, no simplemente lento.
XML tiene formas de denegación de servicio que JSON no tiene, y aquí se aplican límites en vez de suponer que no aparecerán. Un documento que declara entidades anidadas que se expanden exponencialmente, el patrón "billion laughs", se rechaza en unos dos milisegundos porque el coste de la expansión se calcula a partir de las declaraciones antes de expandir un solo carácter. La variante cuadrática, una entidad grande referenciada miles de veces, la detecta el mismo presupuesto. El anidamiento tiene tope, los ciclos de entidades se detectan en vez de recorrerse, y las entidades externas se informan pero nunca se descargan.
Los documentos que la gente pega aquí de verdad
Un validador es una herramienta de propósito general, pero los documentos que llegan a uno no se reparten de forma uniforme. Un puñado de formas concentra la mayor parte del tráfico, y cada una falla a su manera característica.
En casi todos estos casos, validar y formatear son la misma tarea. El archivo es ilegible porque llegó minificado, o indentado por tres herramientas distintas una detrás de otra, y el fallo es invisible hasta que se presenta bien. El botón Formatear de arriba lo reformatea en el sitio, sin pasar por otra web; el formateador XML es la versión completa, con control sobre el ancho de indentación y sobre qué se hace con los comentarios.
- Sitemaps XML. El validador de sitemaps comprueba el protocolo de sitemaps.org, no solo la sintaxis: los topes de 50.000 URL y 50 MB, el formato W3C Datetime que lastmod realmente exige, y la regla de que cada URL debe estar en el mismo host que el sitemap. Un sitemap de Google puede estar perfectamente bien formado y aun así ser rechazado, y casi siempre es una de esas tres cosas.
- SEPA y otros mensajes de pago ISO 20022. Una orden de adeudo directo pain.008 o un extracto camt.053 solo tienen sentido comprobados contra su XSD publicado, así que esos van al validador XSD con el esquema pegado al lado. Esta es la categoría donde la garantía de no subir nada deja de ser una abstracción: un archivo de prueba sigue llevando IBAN e identificadores de acreedor reales.
- Configuración de servidores de juego. DayZ, Arma y los servidores construidos sobre el mismo motor leen types.xml, cfgspawnabletypes.xml y events.xml al arrancar, y un solo elemento <type> sin cerrar detiene el servidor con un mensaje que no nombra ni el archivo ni la línea. Pegar el archivo aquí te da los dos, junto con la profundidad de anidamiento en el punto donde se rompió.
- Envelopes SOAP y las respuestas que vuelven de ellos. Son los documentos con más probabilidad de llevar un token de portador o una cadena de conexión, y esa es la razón de que el formateador SOAP exista como página aparte.
- Feeds RSS y Atom, donde el fallo habitual es un ampersand suelto dentro de una URL en un título, y el lector de feeds solo informa de que el feed está roto.
Si estás acostumbrado a validar en Notepad++
Notepad++ no trae soporte XML propio. El plugin XML Tools lo añade, y ese plugin es un enlace a libxml2, que es el mismo motor que este sitio compila a WebAssembly. Las comprobaciones de fondo, por tanto, coinciden. Lo que cambia es todo lo que las rodea.
El plugin informa de un fallo en un cuadro de diálogo en vez de sobre el documento, así que lees un número de línea y luego vas a buscarla. Es solo para Windows, porque Notepad++ lo es, y la compilación del plugin tiene que coincidir con la arquitectura de tu editor, que es el motivo habitual de que una instalación recién hecha tenga el menú en gris. La validación con esquema está, pero espera que el XSD sea alcanzable desde la propia declaración del documento, algo que un fragmento sacado de un archivo mayor casi nunca tiene.
Ninguna herramienta sustituye a la otra, y la división honesta tiene que ver con dónde está ya el documento. Si es un archivo en disco, ya estás en el editor y no tienes red, el plugin es el camino más corto. Si llegó en un ticket de soporte, en el portapapeles o en una pestaña del navegador, si quieres todos los errores en una pasada en vez de uno por diálogo, o si no estás en Windows, cargar una página es más rápido que instalar un plugin. Lo mismo vale para el caso del esquema: pegar un XSD en el segundo panel de aquí no necesita ninguna declaración dentro del documento.
Hacer esto desde código
La misma comprobación en los lenguajes que más consumen XML. Cada uno de estos ejemplos está en su forma segura: los valores por defecto de varias de estas bibliotecas resuelven alegremente entidades externas, que es la vulnerabilidad XXE, así que los flags de abajo son el meollo y no relleno.
// DOMParser does not throw on malformed input. It returns a document
// containing a <parsererror> element instead, which is why so much code
// silently accepts broken XML.
function parseXml(source) {
const doc = new DOMParser().parseFromString(source, 'application/xml');
const error = doc.querySelector('parsererror');
if (error) {
throw new Error(error.textContent.trim());
}
return doc;
}
// Browsers do not resolve external entities, so XXE is not reachable here.
// Internal entity expansion is, so cap the input size before parsing.# The standard library is not safe against entity-expansion attacks.
# defusedxml is the maintained answer and is a drop-in replacement.
from defusedxml.ElementTree import fromstring, ParseError
try:
root = fromstring(source)
except ParseError as e:
# e.position is a (line, column) tuple, 1-based line, 0-based column
line, column = e.position
raise SystemExit(f"XML error at line {line}, column {column + 1}: {e}")
# With lxml, disable resolution explicitly:
# parser = etree.XMLParser(resolve_entities=False, no_network=True,
# huge_tree=False, load_dtd=False)
# root = etree.fromstring(source.encode(), parser)import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// FEATURE_SECURE_PROCESSING caps entity expansion. The three
// disallow-doctype settings close XXE. None of this is the default.
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
var builder = factory.newDocumentBuilder();
try {
var document = builder.parse(new java.io.ByteArrayInputStream(bytes));
} catch (org.xml.sax.SAXParseException e) {
System.err.printf("XML error at line %d, column %d: %s%n",
e.getLineNumber(), e.getColumnNumber(), e.getMessage());
}using System.Xml;
var settings = new XmlReaderSettings
{
// Null resolver means external DTDs and entities are never fetched.
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
MaxCharactersFromEntities = 1024 * 1024,
MaxCharactersInDocument = 20L * 1024 * 1024,
};
try
{
using var reader = XmlReader.Create(new StringReader(source), settings);
var document = new XmlDocument { XmlResolver = null };
document.Load(reader);
}
catch (XmlException e)
{
Console.Error.WriteLine(
$"XML error at line {e.LineNumber}, column {e.LinePosition}: {e.Message}");
}<?php
// libxml_disable_entity_loader was deprecated in PHP 8.0 because external
// entity loading became off by default. On PHP 7 you still need it.
libxml_use_internal_errors(true);
$doc = new DOMDocument();
$loaded = $doc->loadXML($source, LIBXML_NONET | LIBXML_NOENT & ~LIBXML_NOENT);
if (!$loaded) {
foreach (libxml_get_errors() as $error) {
fprintf(
STDERR,
"XML error at line %d, column %d: %s\n",
$error->line,
$error->column,
trim($error->message)
);
}
libxml_clear_errors();
exit(1);
}# xmllint is part of libxml2 and is almost certainly already installed.
# --nonet stops it fetching a DTD referenced by the document.
xmllint --noout --nonet document.xml
# Validate against a schema:
xmllint --noout --nonet --schema schema.xsd document.xml
xmllint --noout --nonet --valid document.xml # against its own DTD
# Exit status is 0 when valid. Note that xmllint's exit code does not
# always reflect namespace errors, so check the output too.Todos estos ejemplos desactivan algo. No es casualidad: el comportamiento inseguro es el predeterminado en Java, en PHP anterior a 8.0 y en la biblioteca estándar de Python, y sobre esos valores por defecto corre la mayor parte del análisis XML en producción.
Preguntas frecuentes
¿Se sube mi XML a algún sitio?
No. El analizador, el formateador y el motor de esquemas son JavaScript y WebAssembly ejecutándose en esta pestaña. No hay ningún componente de servidor al que enviar nada.
No hace falta que te fíes. Abre las herramientas de desarrollo de tu navegador, ve a la pestaña Red, pega un documento y valídalo. Verás cargarse una vez los recursos de la propia página y después nada más. El sitio no tiene analítica con acceso al editor, ni scripts de terceros, ni servicio de reporte de errores.
¿Cuál es la diferencia entre bien formado y válido?
Bien formado significa que la sintaxis es correcta: etiquetas cerradas, anidamiento correcto, un solo elemento raíz, caracteres especiales escapados y valores de atributo entrecomillados. Válido significa bien formado y además conforme a un esquema, que es un archivo aparte que describe qué elementos se permiten y dónde.
Un documento puede estar bien formado sin ser válido. No puede ser válido sin estar bien formado. Cuando un sistema te dice que tu XML es "no válido", normalmente ha ejecutado una comprobación de esquema, así que un comprobador de sintaxis por sí solo no explicará el fallo.
¿Puede validar contra un XSD?
Sí, y es poco habitual que lo haga sin servidor. Los navegadores no traen validador de esquemas, así que las herramientas gratuitas o se saltan la validación de esquema o suben tus archivos. Este sitio ejecuta libxml2 compilado a WebAssembly, lo que da validación XSD 1.0 y DTD íntegramente en el navegador.
El motor ocupa unos 480 KB comprimido, así que solo se descarga cuando pides de verdad una comprobación de esquema, no al cargar la página. Ten en cuenta que libxml2 implementa solo XSD 1.0: los esquemas que usan funciones de XSD 1.1 como xs:assert no compilarán, y la herramienta lo dice en vez de dar un error estructural confuso.
¿Por qué informa de varios errores cuando otros validadores dan uno?
Porque un error rara vez es toda la historia, y porque un analizador que para en el primer problema te hace arreglar un documento grande de ida y vuelta en ida y vuelta.
El escáner se recupera tras un fallo y continúa, así que una sola pasada encuentra el atributo sin comillas de la línea 4, el ampersand suelto de la línea 12 y la etiqueta sin cerrar del final. Conviene algo de prudencia: un error temprano como una etiqueta sin cerrar puede hacer que todo lo que viene después parezca mal, así que arregla los primeros y vuelve a comprobar en vez de recorrer la lista desde abajo.
¿Qué tamaño de archivo admite?
Hasta 20 MB. Un documento de 10 MB se escanea en algo más de un segundo, y el análisis corre en un Web Worker, así que la página no se congela mientras trabaja.
El límite es deliberado, no descubierto a base de cuelgues. Todo se mantiene en la memoria de esta pestaña, y a partir de unos 20 MB el árbol de análisis puede consumir varios cientos de megabytes. Para archivos realmente grandes, la herramienta correcta es un analizador en flujo en tu propia máquina: xmllint, el iterparse de Python o un analizador SAX, ninguno de los cuales construye el árbol entero.
¿Gestiona bien los espacios de nombres?
Sí. Los prefijos se resuelven contra las declaraciones en ámbito, y usar un prefijo que no se ha vinculado se informa como error, junto con la declaración que necesitas añadir. Es un fallo habitual cuando se copia un fragmento de un documento mayor y la declaración xmlns se queda atrás, en el elemento raíz original.
El editor además atenúa el prefijo respecto al nombre local, así que soap:Body se lee como Body con andamiaje alrededor. Es un detalle pequeño, pero hace que un envelope SOAP muy anidado sea bastante más fácil de recorrer con la vista.
¿Es seguro pegar un documento que contiene credenciales?
Más seguro aquí que en cualquier herramienta que lo suba, porque no se transmite nada. El documento no sale de la pestaña, no se registra y no se incluye en ningún informe de error.
Una advertencia que conviene decir: tu entrada se guarda en el localStorage de este navegador para que un refresco no te haga perder el trabajo. Eso es local a tu máquina y nunca se transmite, pero significa que el documento persiste hasta que lo borres. El botón Limpiar lo elimina al instante, y los documentos de más de 300 KB no se guardan en absoluto.
¿Puedo validar un sitemap XML con esto?
Sí, y para un sitemap la página dedicada del validador de sitemaps es la mejor. Esta comprueba que el documento sea XML bien formado, que es necesario pero no suficiente: un sitemap que Google rechaza suele estar bien formado y estar incumpliendo una regla del protocolo.
Esa página comprueba las reglas en sí. Los límites de 50.000 URL y 50 MB sin comprimir, el espacio de nombres de sitemaps.org, lastmod en formato W3C Datetime en vez de lo que haya emitido tu framework, y la exigencia de que cada URL esté en el mismo host que el archivo de sitemap. También señala los elementos que Google ha dicho públicamente que ignora, para que dejes de ajustar valores que no hacen nada.
¿Admite SEPA y ficheros ISO 20022 como pain.008 o camt.053?
Sí. Un mensaje ISO 20022 es XML corriente con un esquema grande detrás, así que pega el mensaje en el validador XSD y el esquema pain.008 o camt.053 correspondiente en el segundo panel. La validación corre contra ese esquema en tu navegador, sin cuenta que crear y sin más tope que el límite general de 20 MB.
Este es el caso donde más importa adónde va el documento. Un fichero de pagos que es solo de prueba sigue llevando IBAN, identificadores de acreedor y referencias de mandato reales, y varios validadores gratuitos que aceptan ficheros ISO 20022 los suben antes a un servidor. Aquí no se transmite nada, y puedes confirmarlo en la pestaña Red mientras trabajas. Un límite que conviene saber: el motor implementa XSD 1.0, que es en lo que están escritos los esquemas ISO 20022 publicados.
¿Puedo usarlo para archivos de servidor de DayZ como types.xml?
Sí, y encaja bien. Los archivos de economía de DayZ (types.xml, cfgspawnabletypes.xml, events.xml y cfgeventspawns.xml) son XML plano, y el servidor se niega a arrancar cuando uno está mal formado. El mensaje que imprime no suele nombrar ni el archivo ni la posición, que es lo que convierte un corchete angular que falta en una tarde entera.
Pega el archivo aquí y cada error de sintaxis se informa de una vez con línea y columna, así que un archivo editado a mano a lo largo de varias sesiones se arregla en una pasada en vez de un reinicio cada vez. Dos advertencias que conviene decir: no hay XSD publicado para estos archivos, así que esto comprueba que el XML esté bien formado y no que un valor de atributo sea de los que el juego acepta; y un valor de nominal o lifetime que es XML legal pero incorrecto para tu economía de loot pasará aquí y seguirá comportándose mal en el juego.
¿Cómo se compara esto con el validador XML de Notepad++?
Usan el mismo motor. Notepad++ no trae soporte XML por sí solo; el plugin XML Tools lo aporta y está construido sobre libxml2, que es lo que este sitio ejecuta como WebAssembly. Así que los dos coinciden en si un documento está bien formado.
Las diferencias son prácticas. El plugin es solo para Windows y su compilación tiene que coincidir con la arquitectura de tu editor, y por eso una instalación recién hecha suele tener el menú en gris. Informa de los errores en un diálogo en vez de sobre el documento, y su validación con esquema espera que el XSD esté declarado dentro del archivo, algo que un fragmento copiado casi nunca tiene. Esta página acepta un XSD pegado en un segundo panel sin necesidad de declaración, informa de todos los errores de sintaxis en una pasada, y funciona en cualquier sitio donde haya navegador. Si el archivo ya está abierto en Notepad++ y no tienes red, usa el plugin; ese es el caso que gana.
¿Es gratis este validador XML? ¿Hay que registrarse?
Es gratis y no hay cuenta, ni petición de correo, ni cuota diaria, ni un plan de pago que retenga la validación con esquema. Nada del sitio está restringido.
Eso es más fácil de ofrecer de lo que parece, porque la economía es distinta. Un validador que corre en un servidor paga CPU por cada documento que compruebas, y por eso esas herramientas miden el uso, limitan el tamaño de archivo o te piden registrarte. Aquí el análisis ocurre en tu máquina, así que un archivo de 10 MB no le cuesta nada al sitio y no hay razón para contar cuántos validas.
¿Puedo validar XML en línea sin instalar nada?
Esta página es exactamente eso. Funciona en cualquier navegador actual en Windows, macOS, Linux, Android o iOS, sin nada que instalar, sin extensión y sin cuenta.
Conviene hacer una distinción, porque la palabra «en línea» hace ahí dos trabajos. La mayoría de los validadores en línea lo son en los dos sentidos: la página está en la web y tu documento se envía a su servidor para comprobarlo. Este solo lo es en el primer sentido. La página se entrega por la red una vez, y a partir de ahí el analizador, el motor de esquemas y el editor se ejecutan localmente en la pestaña. Cárgala una vez y sigue funcionando con la red apagada.
¿Es esto un validador y formateador XML, o necesito dos herramientas?
Están los dos aquí. El botón Formatear de la fila de arriba reformatea en el sitio lo que haya en el editor, así que la secuencia habitual de pegar algo ilegible, presentarlo bien y entonces encontrar el error ocurre sin moverse entre webs.
El formateador XML es la versión completa para cuando formatear es el trabajo y no un paso hacia otra cosa: indentar con dos espacios, cuatro espacios o tabuladores, decidir qué pasa con los comentarios, y minificar en la dirección contraria. La validación también corre en esa página, porque un documento tiene que estar bien formado antes de poder reformatearse siquiera.
¿Puede embellecer el XML además de validarlo?
Sí. Embellecer, imprimir con formato y formatear son la misma operación: se vuelve a indentar el documento para que el anidamiento se vea, que suele ser lo que hace localizable un fallo.
Hay un detalle que conviene saber, porque la mayoría de los embellecedores lo hacen mal. El espacio en blanco entre dos elementos es insignificante y se puede cambiar sin riesgo, pero el espacio en blanco dentro de un elemento que además contiene texto es datos, y reindentarlo cambia lo que el documento significa. Un embellecedor que parte <p>Hola <b>ahí</b></p> en tres líneas indentadas ha alterado el contenido, no solo su presentación. Este deja el contenido mixto exactamente como lo encontró, y por eso partes de un documento embellecido se quedan en una sola línea.
¿Cuál es el mejor validador XML?
Depende de dónde esté ya el documento y de qué haya que comprobar, y una respuesta honesta incluye los casos en los que este no es el indicado.
Para un documento que puedes pegar, una herramienta de navegador es el camino más corto, y las tres cosas que merece la pena comparar son si hace validación con esquema, si sube tu archivo para hacerlo, y si puedes actuar sobre los errores que informa. Para un archivo ya abierto en un proyecto, tu editor está más a mano: VS Code con la extensión XML de Red Hat, o IntelliJ, validan contra un esquema mientras escribes. Para archivos demasiado grandes para caber en memoria, o para un paso de la compilación, xmllint es la herramienta correcta y ya está instalada en casi todas las máquinas. Para una tubería de CI, el validador que corresponde es el del lenguaje en que esté escrita.
Para lo que está hecho este es el caso intermedio: validación con esquema sin servidor, todos los errores de sintaxis en una sola pasada en vez de solo el primero, y mensajes redactados para quien los lee y no para quien escribió el analizador.