How to validate xhtml?

If you have been writing XHTML by hand for some time, you know that “it seems to work in the browser” is not the same as “it is valid”. Learning how to validate XHTML correctly—with the right tools, in the right order, and understanding what the errors mean—is one of those skills that separate the layout artist who patches from the one who builds solid foundations. This guide compares validators that are really in use today, explains how to interpret their messages, and adds the context that almost never appears in quick tutorials: what happens with XHTML5, why the W3C Validator is no longer what it used to be, and how to integrate validation into a real workflow.

Qué significa exactamente “validar XHTML”

Validating XHTML is checking that a document simultaneously complies with two layers of rules:

1. XML Syntax Rules: correctly nested tags, attributes in quotes, obligatory closing of all elements (including empty ones like <br />), a single root element, a consistent declared encoding, etc.
2. DTD rules or declared schema: what elements and attributes exist, in what context they can appear and what values are allowed. Here are the classic DTDs of XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic and XHTML Modularization.

A document can be well-formed XML and still be invalid: for example, if you use <a target="_blank"> in XHTML 1.0 Strict, the syntax is impeccable but the target attribute does not exist in that DTD. This distinction between well-formed and valid is the number one cause of confusion when someone sees an error and does not understand why.

It is also convenient to remember that XHTML 1.0 is a reformulation of HTML 4.01 in XML, defined by the W3C. Today, its practical value is twofold: it serves for legacy projects that are still served as application/xhtml+xml or text/html, and it serves as a mental discipline to write clean markup. If you want the complete normative context on how to validate XHTML, the especificación de XHTML 1.0 del W3C is the primary source.

Los validadores que merecen la pena (y cuándo usar cada uno)

There is no single “correct” validator. The choice depends on whether you are validating a fragment, a production page, an entire site, or a document that is already XHTML5.

Herramienta	Qué valida	Ideal para	Limitación principal
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Validación puntual por URL, archivo o pegado directo	El “Nu Html Checker” moderno prioriza HTML5; las DTD antiguas requieren selección manual
Nu Html Checker (vnu)	HTML5 y XHTML5	Proyectos nuevos, validación local y en CI	No valida DTD clásicas de XHTML 1.x
Validators locales (vnu.jar, tidy)	Según configuración	Automatización, pre-commit, pipelines	Requiere instalar Java o binarios; configuración inicial
xmllint	Well-formedness XML y validación contra DTD/XSD	Comprobar la capa XML pura	No conoce reglas específicas de HTML más allá del esquema
Extensiones de navegador / IDE	Marcado en vivo	Feedback inmediato mientras escribes	Suelen usar motores desactualizados o incompletos

El W3C Markup Validation Service

It remains the starting point for those wondering how to validate XHTML. It supports three modes: Validate by URI, Validate by File Upload and Validate by Direct Input. For classic XHTML, the trick is in the Document Type dropdown: if your document declares its own DTD via the DOCTYPE, the validator respects it; if not, you have to force it manually.

Related: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

A detail that many are unaware of: the modern W3C validator relies on the Nu Html Checker, which understands HTML5 and XHTML5 but treats old DTDs with less priority. For XHTML 1.0 Strict it still works, but it is advisable to verify that the result reflects the DTD you expect and not a lax interpretation.

Nu Html Checker (vnu)

This is the validator that the W3C itself uses internally. It exists as a web service, as a JAR executable, and as a Docker image. Its big advantage is that you can run it locally and in continuous integration, something essential if you maintain a large site. For XHTML served as application/xhtml+xml, vnu detects nesting and attribute errors that a tolerant HTML validator would let pass.

xmllint

If your concern is the pure XML layer — for example, because you generate XHTML from XSLT templates — then xmllint is irreplaceable. With --noout --valid documento.xhtml it checks well-formedness and validity against the referenced DTD. It’s fast, scriptable and doesn’t depend on the network.

Worth a look: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Validación en el editor

Extensions for VS Code, IDE plugins, and command-line tools offer instant feedback. They are convenient, but tend to fall behind regarding standards. Use them as a first line of defense, never as the sole verification.

How to validate XHTML step by step

1. Declara correctamente el DOCTYPE y la codificación

The DOCTYPE determines against which rules it is validated. For XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Ejemplo válido</title>
</head>

Two classic errors here: forgetting the xmlns attribute (obligatory in XHTML) and declaring a coding in the meta which does not coincide with the actual file. The validator detects both, but the second one sometimes only shows up as corrupted characters.

2. Comprueba la well-formedness antes que la validez

Before fighting with the DTD, make sure the XML is well-formed. xmllint --noout archivo.xhtml will tell you in seconds. If it fails here, no DTD validator will help you: first close tags, correct nesting and escape entities (&, <, >).

3. Valida contra la DTD

With the well-formed document, pass it through the W3C Validator or vnu. Review not only how many errors there are, but of what type. A single nesting error can generate a cascade of secondary errors that disappear upon correcting the first.

4. Valida el sitio completo, no solo la home

A common mistake is to validate the main page and assume the rest is good. Templates, components, and dynamically generated pages often introduce invalid markup. Automate: traverse the main URLs with a script and run vnu on each response.

Related: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

5. Integra la validación en tu flujo

Manual validation does not scale. Add a validation step in your pipeline (pre-commit hook, build task, or CI job) that fails if a new error appears. This way, invalid markup never reaches production.

Interpretar los errores: los que verás una y otra vez

• “end tag for X omitted, but OMITTED end tags are not allowed”: typical of <li>, <p> or <td> without closing. In XHTML, everything must be closed.
• “there is no attribute X”: the attribute does not exist in your DTD. Usual cases: target, name in some elements, data-* attributes in XHTML 1.0 (not in the classic DTD).
• “element X undefined”: uses an element that your DTD does not consider, often from copying HTML5 markup into an XHTML 1.0 document.
• “character data is not allowed here”: text content where the DTD expects only elements, or an & without escaping.
• “reference to entity X for which no system identifier could be generated”: named HTML entities that are not defined in XML (for example   without declaring). In pure XHTML use   or declare the entity.

The golden rule for how to validate xhtml: correct from top to bottom. The first error is usually the cause; the following are its consequence.

XHTML5: el matiz que cambia las reglas

If you serve XHTML5 —XHTML serialized according to HTML5 syntax—, the rules change. There is no longer a DTD: conformance is defined in the WHATWG HTML specification and the W3C specifications on HTML. The correct validator is Nu Html Checker, not the classic DTD validator.

If you are shopping: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Practical differences to be aware of regarding how to validate xhtml:

• The data-* attributes are valid in XHTML5, not in XHTML 1.0.
• The DOCTYPE is simplified to <!DOCTYPE html>.
• Validation is done against HTML5’s conformance checker, which is more permissible in some points and stricter in others (for example, in the use of certain obsolete elements).

Choosing between XHTML 1.0 and XHTML5 is not just technical: if your project is new, XHTML5 with vnu validation is the sensible path. If you maintain a legacy system with DTD, stay in XHTML 1.0 and validate against its DTD.

Validación y accesibilidad: dos capas distintas

A common error is believing that a valid document is automatically accessible. It is not. Validation checks syntax and schema conformance; accessibility is assessed against the WCAG del W3C, which covers perceptions, operability, and compatibility with assistive technologies.

That said, there is real overlap: invalid markup usually implies a deficient structure (poorly nested headings, broken lists, forms without correct labels), and this does affect accessibility. The sensible strategy for how to validate XHTML and other documents is to validate first (eliminate structural noise) and audit accessibility after with tools like axe, Lighthouse, or manual reviews. Validation is a necessary condition, but not sufficient.

Errores frecuentes al validar XHTML

When learning how to validate XHTML, avoid these common mistakes:

• Validate only the home. The problematic markup is usually on internal templates.
• Ignore encoding. A poorly declared charset produces ghost errors.
• Confuse well-formed with valid. They are distinct layers; resolve them in order.
• Use the wrong validator. vnu for XHTML5, DTD for XHTML 1.x.
• Fix cascading errors without reading the first one. You waste time and fix symptoms.
• No automation. Manual validation does not survive the second sprint.
• Assuming that valid = accessible. They are different standards with different purposes.

Key Takeaways

• Validating XHTML involves two layers: well-formedness XML and compliance with the declared DTD or schema.
• The W3C Markup Validation Service and Nu Html Checker (vnu) are the reference tools for how to validate xhtml; xmllint covers the pure XML layer.
• For XHTML 1.0/1.1, use validation against DTD; for XHTML5, use vnu and forget the classic DTDs.
• Correct the errors from top to bottom: the first one usually causes the following.
• Automate the validation in your pipeline; manual review does not scale.
• Valid is not synonymous with accessible: they are complementary standards, not equivalents.

Frequently Asked Questions

¿Cuál es la diferencia entre XHTML bien formado y XHTML válido?

A well-formed document follows the syntactic rules of XML: closed tags, correct nesting, and attributes in quotes. A valid document, furthermore, respects the DTD or schema that it declares: only using elements and attributes allowed in its context. You may have a well-formed but invalid document, for example if you use an attribute that does not exist in XHTML 1.0 Strict.

¿Sigue teniendo sentido validar XHTML en 2024?

Yes, for two reasons. First, many legacy projects continue serving XHTML and need to remain valid so as not to break in XML mode. Second, validation is a discipline that detects structural errors that affect accessibility and maintenance. If your project is new, it probably uses HTML5 or XHTML5, but the habit of validating still remains valuable.

¿Qué validador debo usar para XHTML5?

Nu Html Checker (vnu), available as a web service, executable JAR and Docker image. It is the same engine that the modern W3C Markup Validation Service uses and understands HTML5 syntax and its XHTML serialization. Do not use classic DTD validators for XHTML5: they will not recognize data-* attributes or other HTML5 features.

¿Por qué el validador del W3C me da errores que no entiendo?

Because many errors are the consequence of a previous one. Incorrect nesting can generate dozens of secondary messages. The correct strategy is to correct the first error, validate again and repeat. It also happens that the validator applies the DTD declared in the DOCTYPE; if that DTD is not what you expected, the errors will seem arbitrary.

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

Yes. If you are wondering how to validate XHTML via CLI, xmllint --noout --valid archivo.xhtml checks well-formedness and validity against the DTD. For HTML5/XHTML5, vnu.jar archivo.xhtml does the same. Both options are ideal for integrating into build scripts, pre-commit hooks, or continuous integration jobs, where manual validation does not scale.

¿Un sitio XHTML válido es automáticamente accesible?

No. Validation checks syntactic and schema conformity; accessibility is assessed against the WCAG, which cover aspects like contrast, keyboard navigation, alternative text or semantic structure. A document can be perfectly valid and still remain inaccessible. Validate first and audit accessibility after: they are complementary layers.

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; take a look here if you want the current details.