Bester xhtml validator: Top-Picks im Vergleich (2026)

Dieser Leitfaden vergleicht die Validatoren, die sich auch im Jahr 2026 noch lohnen, was sie jeweils prüfen und wie Sie sie in Ihren Workflow integrieren.

Bevor wir uns mit dem Material befassen, eine wichtige Klarstellung zum Kontext: XHTML 1.0 und 1.1 bleiben als vom W3C veröffentlichte Standards gültig, aber die moderne Webentwicklung hat sich in Richtung HTML5 (dem „Living Standard“ der WHATWG) bewegt. Dies bedeutet nicht, dass XHTML-Validatoren ausgestorben sind: Sie sind weiterhin nützlich für die Pflege älterer Websites, für Projekte, die eine strikte Einhaltung durch Verträge oder Vorschriften erfordern, und als pädagogisches Werkzeug, um den Unterschied zwischen „wohlgeformt“ und „gültig“ zu verstehen. Wenn Sie in einem älteren CMS oder in einem institutionellen Portal mit strengen Barrierefreiheitsanforderungen arbeiten oder einfach nur tiefergehende Kenntnisse erlangen möchten, ist dieser Leitfaden genau das Richtige für Sie.

Was ein XHTML-Validator tatsächlich prüft

Es ist sinnvoll, drei Prüfebenen zu unterscheiden, da viele XHTML-Validatoren nur eine oder zwei abdecken:

1. Wohlgeformtheit (well-formedness). Dies ist die Basis von XML: Alle Tags werden geschlossen, Attribute stehen in Anführungszeichen, es gibt ein einziges Wurzelelement und verschachtelte Elemente überlappen sich nicht. Ein schlecht geformtes XHTML-Dokument ist nicht einmal gültiges XML.
2. Gültigkeit gegenüber einer DTD oder einem Schema. Hier kommt die Definition des Dokumenttyps (DTD) von XHTML 1.0 (Strict, Transitional, Frameset) oder das Schema von XHTML 1.1 ins Spiel. Der Validator prüft, ob jedes Element und Attribut in dieser DTD existiert, ob die zulässige Verschachtelung eingehalten wird und ob die obligatorischen Attribute vorhanden sind.
3. Konformität mit anderen Ebenen. CSS-Validierung, Barrierefreiheitsprüfung (WCAG), defekte Links usw. Dies ist im strengen Sinne keine „XHTML-Validierung“ mehr, aber es ist das, was Sie wirklich benötigen, um eine solide Website zu liefern.

Ein häufiger Fehler: „gültig“ mit „barrierefrei“ oder mit „korrekt“ zu verwechseln. Ein Dokument kann perfekt gültiges XHTML 1.0 Strict sein und dennoch unzugänglich bleiben (Bilder ohne alt, Tabellen für das Layout, unzureichender Kontrast). Validierung ist eine notwendige, aber keine hinreichende Bedingung.

Die XHTML-Validatoren, die sich 2026 lohnen

1. W3C Markup Validation Service (offizieller Validator)

Der W3C Markup Validation Service (validator.w3.org) ist die Referenz. Er wird vom Konsortium selbst gepflegt und dient bei der Mehrheit der Audits als Schiedsrichter. Er akzeptiert die Validierung per URI, durch Hochladen einer Datei oder durch direktes Einfügen des Codes und ermöglicht die Auswahl der spezifischen DTD (XHTML 1.0 Strict, Transitional, Frameset, XHTML 1.1 usw.).

Vorteile:

Verwandte: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

• Dies ist die „Source of Truth“ für XHTML; wenn das W3C es genehmigt, wird es niemand bestreiten.
• Zeigt den Dokumentenbaum an und weist genau auf die Fehlerzeile und -spalte hin.
• Verfügt über eine öffentliche API, die über Skripte aufgerufen werden kann.

Nachteile:

• Die Benutzeroberfläche ist schlicht und etwas veraltet.
• Die öffentliche API hat angemessene Nutzungslimits; für massive Validierungen empfiehlt es sich, den Validator lokal zu installieren.
• Keine CSS-Validierung oder Barrierefreiheitsprüfung; hierfür sind separate Tools erforderlich.

Wann man ihn einsetzt: Immer als abschließende Prüfung, insbesondere wenn Ihr Projekt eine formelle Konformität erfordert.

2. Lokaler Validator (vnu / Nu Html Checker)

Der Nu Html Checker (auch bekannt als vnu) ist die Engine, die das W3C im Hintergrund für HTML5 verwendet, aber er validiert auch XHTML und kann lokal ausgeführt werden. Er wird als JAR-Datei, als Docker-Paket und als Binärdatei verteilt. Dies ist die bevorzugte Option für die Integration in CI/CD.

Einen Blick wert: AudioEye — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.

Vorteile:

• Keine Anfrage-Limits oder Netzwerkabhängigkeit.
• Ausgabe in Text, JSON oder XML, ideal für die Automatisierung.
• Erkennt Probleme, die der Online-XHTML-Validator manchmal nur zusammenfasst.

Nachteile:

• Erfordert die Installation von Java oder Docker.
• Die Konfiguration der DTD für klassisches XHTML ist nicht so einfach wie im Online-Validator.

Wann man ihn einsetzt: Teams, die bei jedem Commit oder Build validieren möchten.

3. In Editoren integrierte Validatoren

Tools wie die W3C Web Developer Extension für Browser oder Validierungs-Plugins von Editoren wie VS Code (Erweiterungen, die vnu oder den W3C-Dienst aufrufen), ermöglichen die Validierung, ohne die Umgebung zu verlassen. Zudem ist das ältere HTML Tidy weiterhin verfügbar und nützlich, um Legacy-Markup zu bereinigen und neu zu formatieren, auch wenn die Unterstützung für XHTML 1.1 begrenzt ist.

Vorteile:

• Sofortiges Feedback während des Schreibens.
• Reduziert Reibungsverluste: Wenn die Validierung nur einen Klick kostet, wird man sie durchführen.

Nachteile:

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

• Sie verwenden meist eine spezifische Version des Validators und können veralten.
• Sie ersetzen keine abschließende Validierung über den offiziellen Dienst.

4. Validierung über die Befehlszeile mit tidy und xmllint

Für diejenigen, die im Terminal arbeiten, gibt es zwei Klassiker:

• xmllint (Teil von libxml2): Prüft, ob das Dokument wohlgeformt ist und mit --valid, ob es gegenüber seiner DTD gültig ist. Es ist sehr schnell und perfekt für Skripte.
• HTML Tidy: Formatiert neu und meldet Fehler, aber sein Modell ist eher das eines „Cleaners“ als das eines „strikten Validators“.

Wann man sie einsetzt: Schnelle Validierung in Pre-Commit-Hooks oder in leichtgewichtigen Pipelines.

Vergleichstabelle

Tool	Typ	Validiert klassisches XHTML	Automatisierbar	Kosten	Bestens geeignet für
W3C Markup Validation Service	Offiziell Online	Ja (alle DTDs)	Via API	Gratis	Abschlussprüfung und Audits
Nu Html Checker (vnu)	Lokal / Docker	Ja (mit Nuancen)	Ja (JSON/XML)	Gratis	CI/CD und Massenvalidierung
Browser-/Editor-Erweiterungen	Integriert	Abhängig von Engine	Limitiert	Gratis	Feedback beim Schreiben
xmllint (libxml2)	Befehlszeile	Ja (wohlgeformt + DTD)	Ja	Gratis	Schnelle Skripte und Hooks
HTML Tidy	Befehlszeile / Lib	Teilweise	Ja	Gratis	Bereinigen von Legacy-Markup

Hinweis: Diese Tools fungieren je nach Anwendungsfall als XHTML-Validator.

Wenn Sie einkaufen: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Wie man je nach Situation wählt

Es gibt keinen universellen „besten Validator“; es hängt von drei Faktoren ab:

• Volumen und Häufigkeit. Wenn Sie gelegentlich eine Datei validieren, reicht der W3C-Onlinedienst aus. Wenn Sie bei jedem Deployment hunderte Vorlagen validieren, benötigen Sie vnu oder xmllint in Ihrer Pipeline.
• Formale Anforderungen. Wenn ein Kunde oder eine Vorschrift eine nachweisbare Konformität verlangt, ist der offizielle W3C-Validator derjenige, der den Beweis liefert.
• Was sonst noch geprüft werden muss. XHTML-Validierung ist nur ein Teil. Für die Barrierefreiheit decken Tools wie axe, WAVE oder Lighthouse ab, was der Markup-Validator nicht sieht. Für CSS gibt es den W3C CSS Validation Service.

Meine praktische Empfehlung: Nutzen Sie den offiziellen XHTML-Validator als Akzeptanzkriterium, vnu oder xmllint für die automatisierte tägliche Arbeit und ergänzen Sie dies immer durch eine Barrierefreiheitsprüfung. Die Markup-Validierung erkennt strukturelle Fehler, die sich oft in Barrierefreiheitsproblemen niederschlagen, aber sie erkennt nicht alle.

Typische Fehler, die immer wieder auftreten

Bei der Validierung von Legacy-XHTML erscheinen diese Hinweise ständig im XHTML-Validator:

• Attribute ohne Anführungszeichen oder nicht geschlossene Tags. Typisch für altes HTML, das ohne Überarbeitung nach XHTML migriert wurde.
• & ohne Escaping. In XHTML muss es & sein; Validatoren markieren dies als Fehler der Wohlgeformtheit.
• Leere Elemente werden falsch geschlossen. <br> muss in XHTML <br /> sein.
• Veraltete Attribute. align, bgcolor und border in Präsentationselementen existieren in XHTML 1.0 Strict nicht; sie müssen in CSS verschoben werden.
• name statt id. In XHTML 1.0 Strict ist das name-Attribut in Elementen wie a oder form eingeschränkt; verwenden Sie id.
• Falsche oder fehlende DTD. Ohne einen gültigen DOCTYPE weiß der Validator nicht, worgegen er prüfen soll.

Das Verständnis dieser Muster spart Stunden: Die meisten Fehler auf Legacy-Seiten gehören zu wenigen Typen.

Validierung in den Workflow integrieren

Ein sinnvoller Ablauf für ein XHTML-Projekt unter Verwendung eines XHTML-Validators:

1. Pre-commit: Ein Hook, der xmllint --valid auf geänderten Dateien ausführt. Schnell und ohne schwere Abhängigkeiten.
2. Build/CI: vnu im JSON-Modus, wobei der Build fehlschlägt, wenn Fehler vorliegen. So führt niemand ungültiges Markup ein.
3. Vor der Veröffentlichung: Validierung wichtiger Seiten über den offiziellen W3C-Dienst, plus ein Barrierefreiheits-Schritt mit axe oder WAVE.
4. Periodisches Audit: Vollständige Website-Validierung und Überprüfung defekter Links.

Dieser Ansatz staffelt den Aufwand: das Günstige und Häufige lokal, das Formelle und Definitive vor der Veröffentlichung.

Key Takeaways

• Ein XHTML-Validator prüft die Wohlgeformtheit, die Gültigkeit gegenüber der DTD und in einigen Fällen weitere Ebenen; er prüft Barrierefreiheit oder CSS nicht eigenständig.
• Der W3C Markup Validation Service ist die offizielle Referenz und das Akzeptanzkriterium bei Audits; der Nu Html Checker (vnu) ist die beste Option zur Automatisierung.
• Für schnelle Skripte validiert xmllint (libxml2) Wohlgeformtheit und DTDs ohne schwere Abhängigkeiten.
• Validieren ist nicht dasselbe wie barrierefrei zu sein: Ergänzen Sie es immer mit Tools wie axe, WAVE oder Lighthouse.
• Die meisten Fehler in Legacy-XHTML gehören zu einer Handvoll Typen (Attribute ohne Anführungszeichen, & ohne Escaping, veraltete Attribute, fehlende DTD).
• Integrieren Sie die Validierung in Pre-Commit und CI, damit sie zur Gewohnheit wird und nicht zu einer ausstehenden Aufgabe.

Quellen & weiterführende Literatur

• 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…

Häufig gestellte Fragen

Welcher ist der beste XHTML-Validator?

Es kommt auf die Nutzung an. Für formelle Compliance und Audits ist der W3C Markup Validation Service der Goldstandard. Zur Automatisierung von CI/CD ist der Nu Html Checker (vnu) am praktischsten. Für schnelle Skripte funktioniert xmllint perfekt. Es gibt keinen einzelnen XHTML-Validator, der in jedem Szenario gewinnt.

Macht es 2026 noch Sinn, XHTML zu validieren?

Ja, wenn Sie Legacy-Seiten pflegen, vertragliche Compliance-Anforderungen haben oder die Grundlagen des Markups erlernen möchten. Für neue Projekte ist HTML5 üblich, aber moderne Validatoren decken dies ebenfalls ab. Validierung als Disziplin bleibt in jedem Fall nützlich.

Garantiert die XHTML-Validierung, dass meine Seite barrierefrei ist?

Nein. Die Markup-Validierung erkennt strukturelle Fehler, die manchmal die Barrierefreiheit beeinflussen, prüft aber keine Dinge wie Alt-Texte für Bilder, Farbkontraste, Tastaturnavigation oder Formularbeschriftungen. Zusätzlich zur Validierung benötigen Sie spezifische Barrierefreiheits-Tools (axe, WAVE, Lighthouse).

Kann ich XHTML über die Befehlszeile validieren?

Ja. xmllint --valid prüft, ob es wohlgeformt und gegenüber der DTD gültig ist, und der Nu Html Checker kann als JAR oder Docker-Container mit Ausgabe in JSON oder XML ausgeführt werden. Beide sind ideal für die Integration in Pre-Commit-Hooks oder CI-Pipelines.

Was ist der Unterschied zwischen „wohlgeformt“ und „gültig“?

„Wohlgeformt“ bedeutet, dass das Dokument den syntaktischen Regeln von XML entspricht: geschlossene Tags, Attribute in Anführungszeichen und korrekte Verschachtelung. „Gültig“ ist strenger: Zusätzlich zur Wohlgeformtheit werden die Regeln einer spezifischen DTD oder eines Schemas eingehalten (welche Elemente und Attribute existieren und wie sie verschachtelt werden dürfen). Ein Dokument kann wohlgeformt, aber nicht gültig sein.

Validiert der W3C-Validator auch CSS?

Nein. Der W3C Markup Validation Service validiert das Markup (HTML/XHTML). Für CSS gibt es einen separaten Dienst, den W3C CSS Validation Service. Dies sind unterschiedliche Tools, und es ist ratsam, beide zu verwenden, wenn Sie eine vollständige Prüfung Ihrer Stylesheets und Ihres Markups wünschen.

Quellen und weiterführende Literatur

• W3C Markup Validation Service – der offizielle xhtml-Validator, unter validador.w3.org.
• Nu Html Checker (vnu) – offizielles W3C-GitHub-Repository.
• W3C XHTML 1.0-Spezifikation (Empfehlung).
• W3C Web Content Accessibility Guidelines (WCAG) für die Barrierefreiheitsebene.
• Libxml2-Dokumentation für „xmllint“.