ToolDeck

Validador de XML

Valida la sintaxis XML y comprueba errores de estructura

Prueba un ejemplo

Entrada XML

Se ejecuta localmente · Es seguro pegar secretos

¿Qué es la validación de XML?

Un validador de XML comprueba si un documento XML sigue las reglas estructurales definidas por la especificación XML 1.0 (Recomendación W3C, quinta edición). Como mínimo, este validador confirma que el documento está bien formado: tiene un único elemento raíz, todas las etiquetas están correctamente anidadas y cerradas, los valores de atributos van entre comillas, y los caracteres reservados usan entidades predefinidas. Un documento que no supere alguna de estas comprobaciones hará que los analizadores XML lancen errores en lugar de producir silenciosamente una salida incorrecta.

La distinción entre buena formación y validez es importante. Un documento XML bien formado satisface las reglas sintácticas de la propia especificación XML. Un documento XML válido va más lejos: también se ajusta a las restricciones definidas en un esquema externo, como un DTD (Document Type Definition), un XSD (XML Schema Definition) o un esquema Relax NG. Esta herramienta comprueba la buena formación, que es el primer paso de validación y el más frecuente. Sin ella, nada de lo que venga después puede funcionar.

La validación de XML detecta errores antes de que lleguen a producción. Las etiquetas sin cerrar, los nombres de elementos que no coinciden, los ampersands sin escapar y los atributos duplicados son algunos de los errores más comunes en XML editado a mano. Los analizadores en distintos lenguajes gestionan estos errores de forma diferente: algunos fallan silenciosamente, algunos devuelven resultados parciales y otros lanzan excepciones. Pasar el XML por un validador elimina esta ambigüedad y te ofrece una respuesta clara de éxito o fallo con los detalles de la ubicación del error.

¿Por qué usar un validador de XML online?

Detectar errores de sintaxis XML cuanto antes previene fallos en cascada en las aplicaciones que consumen datos XML. Un validador en el navegador te da respuesta inmediata sin necesidad de instalar herramientas de línea de comandos ni configurar plugins del IDE.

Detección de errores instantánea
Pega tu XML y obtén un resultado de éxito o fallo con la ubicación exacta del error en menos de un segundo. Sin esperar a pipelines de compilación ni configurar herramientas CLI.
🔒
Procesamiento con privacidad primero
Todo el análisis y la validación ocurren en tu navegador mediante la API DOMParser. Tu XML nunca abandona tu máquina y nunca se transmite a ningún servidor.
🎯
Reporte de errores preciso
Ves la línea y columna exactas donde falla la validación, junto con una descripción del error. Esto es más rápido que leer un stack trace del analizador en el código de tu aplicación.
📋
Sin cuenta ni instalación requerida
Abre la página, pega tu XML y ve el resultado. Sin formularios de registro, sin software de escritorio, sin extensiones del navegador.

Casos de uso del Validador de XML

Desarrollo frontend
Valida archivos SVG y fragmentos XHTML antes de insertarlos en componentes React o Vue. Una sola etiqueta sin cerrar en un SVG puede romper todo el árbol de componentes.
Ingeniería backend
Comprueba respuestas SOAP, payloads XML-RPC y feeds RSS/Atom de APIs de terceros. Valida la respuesta en bruto antes de escribir la lógica de deserialización para evitar depurar excepciones del analizador en producción.
DevOps y CI/CD
Verifica que los archivos Maven pom.xml, .csproj o scripts de Ant estén bien formados después de ediciones automatizadas. Un error de sintaxis en una configuración de compilación puede fallar todo el pipeline con un mensaje de error críptico.
QA y pruebas
Valida los fixtures XML de prueba y los archivos de salida esperada antes de ejecutar pruebas de integración. Los fixtures mal formados provocan falsos negativos que desperdician tiempo de depuración.
Ingeniería de datos
Comprueba exportaciones XML de bases de datos, portales de datos abiertos gubernamentales y pipelines ETL. Validar la estructura antes de escribir consultas XPath o transformaciones XSLT evita esfuerzo perdido con datos fuente rotos.
Aprendiendo XML
Los estudiantes que siguen los tutoriales XML o XSLT del W3C pueden pegar los archivos de ejercicios en el validador para comprobar su sintaxis. Los mensajes de error señalan el problema exacto, lo que acelera el aprendizaje.

Reglas de buena formación XML

La especificación XML 1.0 define un conjunto estricto de reglas sintácticas. Un documento debe satisfacerlas todas para considerarse bien formado. La tabla siguiente muestra cada regla, lo que exige y un ejemplo correcto. La mayoría de los errores de validación se deben a alguna de estas reglas.

ReglaRequisitoEjemplo correcto
Single root elementDocument must have exactly one root<root>...</root>
Matched tagsEvery opening tag needs a closing tag<p>text</p>
Proper nestingTags must close in reverse order of opening<a><b>...</b></a>
Quoted attributesAttribute values must be in single or double quotes<el attr="val"/>
Entity escapingReserved characters must use predefined entities&lt; &gt; &amp; &quot; &apos;
Case sensitivityTag names are case-sensitive: <A> is not </a><Book>...</Book>
No duplicate attributesEach attribute name must appear once per element<el a="1" b="2"/>
Valid XML declarationIf present, must be the very first line<?xml version="1.0"?>

Bien formado vs. válido por DTD vs. válido por esquema

La validación de XML tiene tres niveles. Esta herramienta comprueba el primero (buena formación), que es requisito previo de los otros dos.

Bien formado
Cumple las reglas sintácticas de XML 1.0: un único elemento raíz, etiquetas emparejadas, atributos entre comillas y anidamiento correcto. Todos los analizadores XML comprueban esto primero. Si un documento no está bien formado, no es XML en absoluto.
Válido por DTD
Se ajusta a una Document Type Definition que especifica qué elementos y atributos están permitidos, su orden y su cardinalidad. Los DTDs se declaran en línea o mediante una referencia DOCTYPE. La validación por DTD es habitual en sistemas heredados y XHTML.
Válido por esquema (XSD / Relax NG)
Se ajusta a un XML Schema Definition (XSD) o esquema Relax NG. Estos esquemas admiten tipos de datos (integer, date, URI), espacios de nombres y modelos de contenido complejos. La validación XSD es estándar en servicios web SOAP, datos sanitarios HL7 e integración empresarial.

Ejemplos de código

Valida XML de forma programática en distintos lenguajes. Cada ejemplo comprueba la buena formación y devuelve el mensaje de error si el documento está mal formado.

JavaScript (DOMParser)
function validateXML(xmlString) {
  const parser = new DOMParser()
  const doc = parser.parseFromString(xmlString, 'application/xml')
  const error = doc.querySelector('parsererror')
  if (error) {
    return { valid: false, message: error.textContent }
  }
  return { valid: true, message: 'Well-formed XML' }
}

validateXML('<root><item>hello</item></root>')
// → { valid: true, message: "Well-formed XML" }

validateXML('<root><item>hello</root>')
// → { valid: false, message: "Opening and ending tag mismatch..." }
Python
import xml.etree.ElementTree as ET

def validate_xml(xml_string):
    try:
        ET.fromstring(xml_string)
        return True, "Well-formed XML"
    except ET.ParseError as e:
        return False, str(e)

valid, msg = validate_xml('<root><item>hello</item></root>')
# → (True, "Well-formed XML")

valid, msg = validate_xml('<root><item>hello</root>')
# → (False, "mismatched tag: line 1, column 27")

# With lxml — also supports XSD schema validation
from lxml import etree
schema = etree.XMLSchema(etree.parse('schema.xsd'))
doc = etree.fromstring(b'<root><item>hello</item></root>')
schema.validate(doc)  # → True or False
Go
package main

import (
    "encoding/xml"
    "fmt"
    "strings"
)

func validateXML(raw string) error {
    decoder := xml.NewDecoder(strings.NewReader(raw))
    for {
        _, err := decoder.Token()
        if err != nil {
            if err.Error() == "EOF" {
                return nil
            }
            return err
        }
    }
}

func main() {
    err := validateXML("<root><item>hello</item></root>")
    fmt.Println(err) // → <nil>

    err = validateXML("<root><item>hello</root>")
    fmt.Println(err) // → XML syntax error: unexpected end element </root>
}
CLI (xmllint)
# Check well-formedness (part of libxml2, pre-installed on macOS/Linux)
xmllint --noout document.xml
# Exit code 0 = valid, non-zero = errors printed to stderr

# Validate against an XSD schema
xmllint --noout --schema schema.xsd document.xml

# Validate against a DTD
xmllint --noout --dtdvalid schema.dtd document.xml

# Validate from stdin
echo '<root><unclosed>' | xmllint --noout -
# → :1: parser error : Premature end of data in tag unclosed line 1

Preguntas frecuentes

¿Cuál es la diferencia entre XML bien formado y XML válido?
El XML bien formado sigue las reglas sintácticas de la especificación XML 1.0: un único elemento raíz, etiquetas emparejadas y correctamente anidadas, atributos entre comillas. El XML válido va más lejos: también se ajusta a un DTD o esquema XSD que define qué elementos, atributos y tipos de datos están permitidos. Un documento puede estar bien formado pero no ser válido si tiene sintaxis correcta pero incumple una restricción del esquema.
¿Puede un documento XML ser válido pero no estar bien formado?
No. La buena formación es un requisito previo de la validez. Si un documento incumple alguna regla sintáctica de XML (etiqueta sin cerrar, atributo sin comillas, etc.), los analizadores no pueden construir un árbol a partir de él, por lo que la validación contra un esquema ni siquiera puede comenzar. Corrige primero los errores de buena formación y después comprueba contra el esquema.
¿Cuáles son los errores de validación XML más frecuentes?
Los cinco errores más frecuentes son: etiquetas sin cerrar o que no coinciden, ampersands sin escapar en el contenido de texto, valores de atributos sin comillas, elemento raíz ausente, y capitalización incorrecta en los nombres de etiquetas (XML distingue mayúsculas y minúsculas). La mayoría se deben a edición manual de XML o a concatenación de cadenas en el código en lugar de usar un serializador XML apropiado.
¿Es la validación de XML lo mismo que el linting de XML?
Se solapan, pero no son idénticos. La validación comprueba si un documento se ajusta a la especificación XML (buena formación) o a un esquema (DTD/XSD). El linting suele ir más lejos al señalar también problemas de estilo: indentación inconsistente, declaraciones de espacio de nombres no utilizadas o valores de atributos por defecto redundantes. xmllint de libxml2 combina ambos: --noout comprueba la buena formación, mientras que --schema añade la validación XSD.
¿En qué se diferencia la validación de XML de la de JSON?
XML tiene una gramática más estricta y compleja que JSON. XML requiere etiquetas de apertura y cierre emparejadas, admite atributos, espacios de nombres, contenido mixto (texto y elementos juntos) y dispone de múltiples lenguajes de esquema (DTD, XSD, Relax NG, Schematron). La validación de JSON comprueba el emparejamiento de llaves y corchetes, las claves entre comillas y la colocación de comas. JSON Schema existe, pero es más sencillo que XSD. Un documento XML suele ser entre 2 y 3 veces más grande que el JSON equivalente para los mismos datos.
¿Esta herramienta valida contra esquemas XSD o DTD?
Esta herramienta comprueba únicamente la buena formación: confirma que tu XML sigue las reglas sintácticas de la especificación XML 1.0. No valida contra DTD o esquemas XSD externos. Para la validación por esquema, usa xmllint --schema en la línea de comandos o lxml en Python, que admite tanto XSD como Relax NG.
¿Por qué mi XML falla la validación si parece correcto?
Las causas invisibles más frecuentes son: una marca de orden de bytes (BOM) antes de la declaración XML, un carácter fuera de lugar después de la etiqueta de cierre del elemento raíz, un ampersand sin escapar en el contenido de texto (usa &amp; en su lugar) o un prefijo de espacio de nombres que se usó pero nunca se declaró. Copia tu XML en un visor hexadecimal o ejecútalo con xmllint --noout para obtener el desplazamiento exacto en bytes del error.