Saltar al contenido principal
Niquelao Accesibilidad web y desarrollo front-end en español: estándares WCAG, widgets accesibles y extensiones para Firefox, explicados con código real.

Algunos enlaces de este sitio son de afiliados: si compras a través de ellos, es posible que recibamos una comisión sin coste adicional para ti. Esto nunca afecta a nuestras recomendaciones. Consulta nuestra declaración de afiliados para más detalles. Divulgación de afiliados.

Mejor validador Xhtml: mejores selecciones comparadas (2026)

Un validador xhtml comprueba si el marcado está bien formado y es válido frente a una DTD o esquema, cubriendo tres niveles de verificación que muchas herramientas solo abordan parcialmente. XHTML 1.0 y 1.1 siguen siendo válidos como estándares publicados por el W3C, pero el desarrollo web moderno ha avanzado hacia HTML5 (el “living standard” del WHATWG). Esta guía compara los validadores que aún vale la pena usar en 2026, qué verifica cada uno y cómo integrarlos en su flujo de trabajo.

Antes de entrar en materia, una aclaración importante sobre el contexto: XHTML 1.0 y 1.1 siguen siendo válidos como estándares publicados por el W3C, pero el desarrollo web moderno ha avanzado hacia HTML5 (el “living standard” del WHATWG). Esto no significa que los validadores XHTML hayan muerto: siguen siendo útiles para mantener sitios heredados, para proyectos que requieren un cumplimiento estricto por contrato o regulación y como herramienta pedagógica para comprender la diferencia entre “bien formado” y “válido”. Si trabajas en un CMS antiguo, en un portal institucional con estrictos requisitos de accesibilidad, o simplemente quieres aprender en profundidad, esta guía es para ti.

Qué comprueba realmente un validador de XHTML

Es útil distinguir tres niveles de verificación, porque muchos validadores xhtml solo cubren uno o dos:

  1. Bien formado (well-formedness). Es la base de XML: todas las etiquetas cierran, los atributos van entre comillas, hay un único elemento raíz, los elementos anidados no se solapan. Un documento XHTML mal formado ni siquiera es XML válido.
  2. Validez respecto a una DTD o esquema. Aquí entra la definición de tipo de documento (DTD) de XHTML 1.0 (Strict, Transitional, Frameset) o el esquema de XHTML 1.1. El validador comprueba que cada elemento y atributo existe en esa DTD, que el anidamiento permitido se respeta y que los atributos obligatorios están presentes.
  3. Conformidad con otras capas. Validación de CSS, comprobación de accesibilidad (WCAG), enlaces rotos, etc. Esto ya no es “validación XHTML” en sentido estricto, pero es lo que de verdad necesitas para entregar un sitio sólido.

Un error común: confundir “válido” con “accesible” o con “correcto”. Un documento puede ser XHTML 1.0 Strict perfectamente válido y aún así permanecer inaccesible (imágenes sin alt, tablas utilizadas para el diseño, contraste insuficiente). La validación es una condición necesaria, no suficiente.

Los validadores de XHTML que merecen la pena en 2026

1. W3C Markup Validation Service (validador oficial)

El W3C Markup Validation Service (validador.w3.org) es la referencia. Lo mantiene el propio consorcio y es el que sirve de árbitro en la mayoría de las auditorías. Acepta validación por URI, cargando un archivo o pegando el código directamente, y permite elegir la DTD específica (XHTML 1.0 Strict, Transitional, Frameset, XHTML 1.1, etc.).

Ventajas:

Relacionado: — con plan gratuito para empezar hoy mismo.

  • Esta es la fuente de verdad para XHTML; si el W3C lo aprueba, nadie lo cuestionará.
  • Muestra el árbol del documento y señala exactamente la línea y columna del error.
  • Tiene una API pública a la que puedes llamar desde scripts.

Desventajas:

  • La interfaz es sobria y algo anticuada.
  • La API pública tiene límites de uso razonables; para una validación masiva, es recomendable instalar el validador localmente.
  • No incluye validación de CSS ni de accesibilidad; esto requiere herramientas separadas.

Cuándo usarlo: Siempre como verificación final, especialmente si tu proyecto requiere un cumplimiento formal.

2. Validador local (vnu / Nu Html Checker)

El Nu Html Checker (también conocido como vnu) es el motor que el W3C utiliza detrás de escena para HTML5, pero también valida XHTML y se puede ejecutar localmente. Se distribuye como un archivo JAR, como un paquete Docker y como un binario. Esta es la opción preferida para integrarlo en CI/CD.

Vale la pena echarle un vistazo: — Accesibilidad gestionada: automatización combinada con revisión humana.

Ventajas:

  • Sin límites de solicitudes ni dependencia de la red.
  • Salida en texto, JSON o XML, ideal para automatizar.
  • Detecta problemas que en ocasiones el validador xhtml online resume.

Desventajas:

  • Requiere Java o Docker instalado.
  • Configurar la DTD para XHTML clásico no es tan sencillo como en el validador en línea.

Cuándo usarlo: Equipos que desean validar en cada commit o build.

3. Validadores integrados en editores

Herramientas como la W3C Web Developer Extension para navegadores, o complementos de validación de editores como VS Code (extensiones que llaman a vnu o al servicio W3C), permiten la validación sin salir del entorno. Además, el antiguo HTML Tidy todavía está disponible y es útil para limpiar y reformatear el marcado heredado, incluso si su soporte para XHTML 1.1 es limitado.

Ventajas:

  • Retroalimentación inmediata mientras escribes.
  • Reduce la fricción: si validar cuesta un clic, lo harás.

Desventajas:

Relacionado: — La que acredita tu experiencia en accesibilidad..

  • Suelen utilizar una versión específica del validador y pueden quedar desactualizados.
  • No sustituyen a una validación final frente al servicio oficial.

4. Validación por línea de comandos con tidy y xmllint

Para quienes trabajan en la terminal, dos clásicos:

  • xmllint (parte de libxml2): verifica que el documento esté bien formado y, con --valid, que sea válido contra su DTD. Es muy rápido y perfecto para scripts.
  • HTML Tidy: reformatea e informa errores, pero su modelo es más el de un “limpiador” que el de un “validador estricto”.

Cuándo usarlos: Validación rápida en pre-commit hooks o en pipelines ligeros.

Tabla comparativa

HerramientaTipoValida XHTML clásicoAutomatizableCosteMejor para
W3C Markup Validation ServiceOnline oficialSí (todas las DTD)Vía APIGratisComprobación final y auditorías
Nu Html Checker (vnu)Local / DockerSí (con matices)Sí (JSON/XML)GratisCI/CD y validación masiva
Extensiones de navegador/editorIntegradoDepende del motorLimitadoGratisFeedback mientras escribes
xmllint (libxml2)Línea de comandosSí (bien formado + DTD)SíGratisScripts y hooks rápidos
HTML TidyLínea de comandos / libreríaParcialSíGratisLimpiar marcado heredado

Nota: Estas herramientas funcionan como validador xhtml según el caso de uso.

Si estás de compras: — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Cómo elegir según tu situación

No existe un “mejor validador” universal; depende de tres factores:

  • Volumen y frecuencia. Si validas un archivo de vez en cuando, el servicio online del W3C es suficiente. Si validas cientos de plantillas en cada despliegue, necesitas vnu o xmllint en tu pipeline.
  • Requisito formal. Si un cliente o una normativa solicita conformidad demostrable, el validador oficial del W3C es el que proporciona la prueba.
  • Qué más necesitas verificar. La validación XHTML es solo una pieza. Para accesibilidad, herramientas como axe, WAVE o Lighthouse cubren lo que el validador de marcado no ve. Para CSS, el W3C CSS Validation Service.

Mi recomendación práctica: utilice el validador xhtml oficial como criterio de aceptación, vnu o xmllint para el trabajo diario automatizado, y complemente siempre con una comprobación de accesibilidad. La validación del marcado detecta errores estructurales que muchas veces se traducen en problemas de accesibilidad, pero no los detecta todos.

Errores típicos que verás una y otra vez

Al validar XHTML heredado, estos avisos aparecen constantemente en el validador xhtml:

  • Atributos sin comillas o etiquetas sin cerrar. Típico de HTML antiguo migrado a XHTML sin revisión.
  • & sin escapar. En XHTML debe ser &; los validadores lo marcan como un error de bien formado.
  • Elementos vacíos cerrados incorrectamente. <br> debe ser <br /> en XHTML.
  • Atributos obsoletos. align, bgcolor y border en los elementos de presentación no existen en XHTML 1.0 Strict; deben moverse a CSS.
  • name en lugar de id. En XHTML 1.0 Strict, el atributo name en elementos como a o form está restringido; use id.
  • DTD incorrecta o faltante. Sin un DOCTYPE válido, el validador no sabe contra qué comprobar.

Comprender estos patrones le ahorra horas: la mayoría de los errores en los sitios heredados son de unos pocos tipos.

Integrar la validación en tu flujo de trabajo

Un flujo sensato para un proyecto XHTML usando un validador xhtml:

  1. Pre-commit: un hook que ejecuta xmllint --valid en archivos modificados. Rápido y sin grandes dependencias.
  2. Build/CI: vnu en modo JSON, fallando la compilación si hay errores. Así nadie introduce marcado no válido.
  3. Pre-publicación: validación contra el servicio oficial W3C de páginas clave, más un paso de accesibilidad con axe o WAVE.
  4. Auditoría periódica: Validación completa del sitio y revisión de enlaces rotos.

Este enfoque distribuye el esfuerzo: lo barato y frecuente localmente, lo formal y definitivo antes de publicar.

Conclusiones clave

  • Un validador xhtml comprueba el bien formado, la validez frente a DTD y, en algunos casos, otras capas; no comprueba la accesibilidad ni el CSS por sí solo.
  • El W3C Markup Validation Service es la referencia oficial y el criterio de aceptación en las auditorías; el Nu Html Checker (vnu) es la mejor opción para automatizar.
  • Para scripts rápidos, xmllint (libxml2) valida el bien formado y las DTD sin dependencias pesadas.
  • Validar no es lo mismo que ser accesible: complemente siempre con herramientas como axe, WAVE o Lighthouse.
  • La mayoría de los errores en XHTML heredado son de unos pocos tipos (atributos sin comillas, & sin escapar, atributos obsoletos, DTD faltante).
  • Integre la validación en pre-commit y CI para que se convierta en un hábito y no en una tarea pendiente.

Fuentes y lecturas adicionales

  • XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
  • Validator — Wikipedia: A validator is a computer program used to check the validity or syntactical correctness of a fragment of code or document. The term is commonly used in the context…
  • CSS HTML Validator — Wikipedia: CSS HTML Validator (previously named CSE HTML Validator) is an HTML editor and CSS editor for Microsoft Windows (and macOS, Linux and other Unix-like operating systems…

Preguntas frecuentes

¿Cuál es el mejor validador de XHTML?

Depende del uso. Para cumplimiento formal y auditorías, el W3C Markup Validation Service es el estándar de oro. Para automatizar CI/CD, el Nu Html Checker (vnu) es el más práctico. Para scripts rápidos, xmllint funciona perfectamente. No existe un único validador xhtml que gane en todos los escenarios.

¿Sigue teniendo sentido validar XHTML en 2026?

Sí, si mantiene sitios heredados, tiene requisitos de cumplimiento contractual o desea aprender los fundamentos del marcado. Para proyectos nuevos, lo habitual es HTML5, pero los validadores modernos también lo cubren. La validación como disciplina sigue siendo útil en cualquier caso.

¿Validar XHTML garantiza que mi sitio sea accesible?

No. La validación de marcado detecta errores estructurales que a veces afectan la accesibilidad, pero no verifica elementos como el texto alternativo de las imágenes, el contraste de color, la navegación con el teclado o las etiquetas de los formularios. Necesita herramientas de accesibilidad específicas (axe, WAVE, Lighthouse) además de la validación.

¿Puedo validar XHTML desde la línea de comandos?

Sí. xmllint --valid comprueba si está bien formado y es válido según la DTD, y el Nu Html Checker puede ejecutarse como un archivo JAR o contenedor Docker con salida en JSON o XML. Ambos son ideales para la integración en pre-commit hooks o pipelines de integración continua.

¿Qué diferencia hay entre “bien formado” y “válido”?

“Bien formado” significa que el documento cumple con las reglas sintácticas de XML: etiquetas cerradas, atributos entre comillas y anidamiento correcto. “Válido” es más estricto: además de estar bien formado, respeta las reglas de una DTD o esquema específico (qué elementos y atributos existen y cómo se pueden anidar). Un documento puede estar bien formado pero no ser válido.

¿El validador del W3C también valida CSS?

No. El W3C Markup Validation Service valida el marcado (HTML/XHTML). Para CSS, existe un servicio independiente, el W3C CSS Validation Service. Estas son herramientas distintas y es recomendable utilizar ambas si desea una verificación completa de sus hojas de estilo y su marcado.

Fuentes y lecturas recomendadas

  • Servicio de validación de marcado W3C: el validador xhtml oficial, en validador.w3.org.
  • Nu Html Checker (vnu): repositorio oficial de GitHub del W3C.
  • Especificación W3C XHTML 1.0 (recomendación).
  • Pautas de Accesibilidad al Contenido Web (WCAG) del W3C, para la capa de accesibilidad.
  • Documentación Libxml2 para xmllint.

¿Cumplir WCAG sin tocar el código?

Superposición de IA que promete cumplimiento WCAG en 48 horas