Beste xhtml validator online: topkeuzes vergeleken (2026)

Een xhtml-validator controleert of de opmaak goed is opgemaakt en geldig is ten opzichte van een DTD of schema, en omvat drie verificatieniveaus die door veel tools slechts gedeeltelijk worden aangepakt. XHTML 1.0 en 1.1 blijven geldig als standaarden gepubliceerd door het W3C, maar de moderne webontwikkeling is opgeschoven in de richting van HTML5 (de “levensstandaard” van de WHATWG). Deze gids vergelijkt de validators die in 2026 nog steeds de moeite waard zijn om te gebruiken, wat ze allemaal controleren en hoe u ze in uw workflow kunt integreren.

Voordat we op het materiaal ingaan, eerst een belangrijke verduidelijking over de context: XHTML 1.0 en 1.1 blijven geldig als standaarden gepubliceerd door het W3C, maar de moderne webontwikkeling is opgeschoven in de richting van HTML5 (de “levensstandaard” van de WHATWG). Dit betekent niet dat XHTML-validators zijn overleden: ze blijven nuttig voor het onderhouden van oudere sites, voor projecten die strikte naleving vereisen door contract of regelgeving, en als een pedagogisch hulpmiddel om het verschil tussen “goed gevormd” en “geldig” te begrijpen. Als u in een ouder CMS werkt, in een institutioneel portaal met strenge toegankelijkheidseisen, of gewoon diepgaander wilt leren, dan is deze gids iets voor u.

Wat een XHTML-validator echt controleert

Het is nuttig om drie controleniveaus te onderscheiden, omdat veel xhtml-validators er slechts één of twee bestrijken:

1. Goed gevormd (well-formedness). De XML-basis: alle tags worden gesloten, attributen staan tussen aanhalingstekens, er is één enkel wortelelement en geneste elementen overlappen elkaar niet. Een slecht gevormd XHTML-document is zelfs geen geldig XML.
2. Geldigheid ten opzichte van een DTD of schema. Hier komt de documenttype-definitie (DTD) van XHTML 1.0 (Strict, Transitional, Frameset) of het schema van XHTML 1.1 kijken. De validator controleert of elk element en attribuut bestaat in die DTD, of de toegestane nesting wordt gerespecteerd en of de verplichte attributen aanwezig zijn.
3. Conformiteit met andere lagen. CSS-validering, toegangscontrole (WCAG), gebroken links, etc. Dit is in strikte zin geen “XHTML-validatie” meer, maar het is wat u echt nodig heeft om een solide site op te leveren.

Een veelgemaakte fout: het verwarren van ‘geldig’ met ‘toegankelijk’ of met ‘juist’. Een document kan perfect geldig zijn XHTML 1.0 Strict en toch ontoegankelijk blijven (afbeeldingen zonder alt, tabellen gebruikt voor de opmaak, onvoldoende contrast). Validatie is een noodzakelijke voorwaarde, niet voldoende.

XHTML-validators die de moeite waard zijn in 2026

1. W3C Markup Validation Service (officiële validator)

De W3C Markup Validation Service (validador.w3.org) is de referentie. Het wordt onderhouden door het consortium zelf en wordt bij de meeste audits als scheidsrechter gebruikt. Het accepteert validatie via URI, door een bestand te laden of de code rechtstreeks te plakken, en maakt het mogelijk de specifieke DTD te kiezen (XHTML 1.0 Strict, Transitional, Frameset, XHTML 1.1, enz.).

Voordelen:

Gerelateerd: UserWay — Widget voor toegang met een gratis plan voor uw bedrijf.

• Dit is de bron van waarheid voor XHTML; als het W3C het goedkeurt, zal niemand het betwisten.
• Toont de documentboom en wijst precies op de foutregel en -kolom.
• Het heeft een openbare API die u vanuit scripts kunt aanroepen.

Nadelen:

• De interface is sober en enigszins verouderd.
• De openbare API heeft redelijke gebruikslimieten; voor massale validatie is het raadzaam om de validator lokaal te installeren.
• Geen CSS-validatie of toegankelijkheid; hiervoor zijn aparte hulpmiddelen nodig.

Wanneer gebruiken: Altijd als laatste controle, vooral als uw project formele naleving vereist.

2. Validador lokaal (vnu / Nu Html Checker)

De Nu Html Checker (ook bekend als vnu) is de engine die het W3C achter de schermen gebruikt voor HTML5, maar valideert ook XHTML en kan lokaal worden uitgevoerd. Het wordt gedistribueerd als JAR-bestand, als Docker-pakket en als binair bestand. Dit heeft de voorkeur voor integratie in CI/CD.

Een kijkje waard: AudioEye — Toegankelijkheidsbeheer: automatiseringscombinatie met menselijke herziening.

Voordelen:

• Zonder verzoeklimieten of netwerkafhankelijkheid.
• Uitvoer in tekst, JSON of XML, ideaal voor automatisering.
• Detecteert problemen die de online xhtml-validator soms samenvat.

Nadelen:

• Vereist dat Java of Docker is geïnstalleerd.
• Het configureren van de DTD voor klassieke XHTML is niet zo eenvoudig als in de online validator.

Wanneer gebruiken: Teams die elke commit of build willen valideren.

3. In editors geïntegreerde validators

Tools zoals de W3C Web Developer Extension voor browsers, of validatieplug-ins van editors zoals VS Code (extensies die vnu of de W3C-service aanroepen), maken validatie mogelijk zonder de omgeving te verlaten. Bovendien is de oudere HTML Tidy nog steeds beschikbaar en is handig voor het opschonen en opnieuw formatteren van verouderde markeringen, zelfs als de ondersteuning voor XHTML 1.1 beperkt is.

Voordelen:

• Onmiddellijke feedback tijdens het schrijven.
• Vermindert wrijving: als het valideren één klik kost, dan doet u het.

Nadelen:

Gerelateerd: IAAP CPACC / WAS Certification — Het professionele certificaat dat u ervaring en toegankelijkheid geeft.

• Ze gebruiken meestal een specifieke versie van de validator en kunnen verouderd raken.
• Ze vervangen geen definitieve validatie tegen de officiële dienst.

4. Validatie voor de opdrachtregel met tidy en xmllint

Voor wie in de terminal werkt, twee klassiekers:

• xmllint (onderdeel van libxml2): controleert of het document goed is opgemaakt en, met --valid, of het geldig is ten opzichte van zijn DTD. Het is erg snel en perfect voor scripts.
• HTML Tidy: formatteert en rapporteert fouten, maar het model is meer een “opschoner” dan een “strikte validator”.

Wanneer moet u ze gebruiken: Snelle validatie in pre-commit hooks of in lichtgewicht pipelines.

Vergelijkingstabel

Tool	Type	Valideert klassiek XHTML	Automatiseerbaar	Kosten	Beste voor
W3C Markup-validatieservice	Online officieel	Ja (alle DTD’s)	Via API	Gratis	Finale controle en audits
Nu HTML-checker (vnu)	Lokaal / Docker	Ja (met nuances)	Ja (JSON/XML)	Gratis	CI/CD en massale validatie
Navigatie-/editorextensies	Integraal	Afhankelijk van de motor	Beperkt	Gratis	Feedback tijdens het schrijven
xmllint (libxml2)	Lijn van comandos	Ja (goed gevormd + DTD)	Si	Gratis	Scripts en snelle hooks
HTML netjes	Lijn van comandos / bibliotheek	Partiaal	Si	Gratis	Oude markup opschonen

Opmerking: deze functie functioneert als xhtml-validator in het gebruiksgeval.

Als u aan het winkelen bent: accessiBe — Superpositie van IA die de cumplimiento WCAG in 48 uur stimuleert.

Hoe te kiezen op basis van uw situatie

Er is geen universele “beste validator”; het hangt van drie factoren af:

• Volume en frequentie. Als u af en toe een bestand valideert, is de W3C online service voldoende. Als u in elke implementatie honderden sjablonen valideert, heeft u vnu of xmllint in uw pijplijn nodig.
• Formele vereiste. Als een klant of een regelgeving om aantoonbare conformiteit vraagt, is de officiële W3C-validator degene die het bewijs levert.
• Wat u nog meer moet controleren. XHTML-validatie is slechts één onderdeel. Voor toegankelijkheid dekken tools als axe, WAVE of Lighthouse wat de markup-validator niet ziet. Voor CSS: de W3C CSS Validation Service.

Mijn praktische aanbeveling: gebruik de officiële xhtml-validator als acceptatiecriterium, vnu of xmllint voor geautomatiseerd dagelijks werk, en vul dit altijd aan met een toegankelijkheidscontrole. Markup-validatie detecteert structurele fouten die zich vaak vertalen in toegankelijkheidsproblemen, maar detecteert ze niet allemaal.

Typische fouten die u keer op keer zult zien

Bij het valideren van verouderde XHTML verschijnen deze mededelingen voortdurend in de xhtml-validator:

• Attributen zonder aanhalingstekens of niet-gesloten tags. Typisch voor oude HTML die zonder revisie naar XHTML is gemigreerd.
• & zonder te ontsnappen. In XHTML moet dit & zijn; de validators markeren het als een goedgevormde fout.
• Lege elementen zijn onjuist gesloten. <br> moet <br /> zijn in XHTML.
• Verouderde attributen. align, bgcolor en border in presentatie-elementen bestaan ​​niet in XHTML 1.0 Strict; ze moeten naar CSS worden verplaatst.
• name in plaats van id. In XHTML 1.0 Strict is het name attribuut in elementen als a of form beperkt; gebruik ‘id’.
• Onjuiste of ontbrekende DTD. Zonder een geldig DOCTYPE weet de validator niet waar hij op moet letten.

Als u deze patronen begrijpt, bespaart u uren: de meeste fouten op oudere sites zijn van een paar typen.

Validatie integreren in uw workflow

Een verstandige stroom voor een XHTML-project met behulp van een xhtml-validator:

1. Pre-commit: een hook die xmllint --valid uitvoert op gewijzigde bestanden. Snel en zonder zware afhankelijkheden.
2. Build/CI: vnu in JSON-modus, mislukt de build als er fouten zijn. Niemand introduceert dus ongeldige markup.
3. Pre-publicatie: validatie tegen de officiële W3C-service van belangrijke pagina’s, plus een toegankelijkheidsstap met ax of WAVE.
4. Periodieke audit: Volledige sitevalidatie en beoordeling van verbroken links.

Deze aanpak spreidt de inspanning: het goedkope en frequente lokaal, het formele en definitieve vóór publicatie.

Belangrijkste conclusies

• Een xhtml-validator controleert de goedgevormdheid, de geldigheid ten opzichte van DTD en, in sommige gevallen, andere lagen; het controleert zelf de toegankelijkheid of CSS niet.
• De W3C Markup Validation Service is het officiële referentie- en acceptatiecriterium bij audits; de Nu Html Checker (vnu) is de beste optie om te automatiseren.
• Voor snelle scripts valideert xmllint (libxml2) goedgevormdheid en DTD’s zonder zware afhankelijkheden.
• Valideren is niet hetzelfde als toegankelijk zijn: vul altijd aan met tools als Axe, WAVE of Lighthouse.
• De meeste fouten in oudere XHTML zijn van een handvol typen (attributen zonder aanhalingstekens, & zonder escape-tekens, verouderde attributen, ontbrekende DTD).
• Integreer validatie in pre-commit en CI, zodat het een gewoonte wordt en geen lopende taak.

Bronnen en verder lezen

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) maakt deel uit van de familie van XML-opmaaktalen die versies van de veelgebruikte HyperText Markup spiegelen of uitbreiden…
• Validator — Wikipedia: Een validator is een computerprogramma dat wordt gebruikt om de geldigheid of syntactische correctheid van een codefragment of document te controleren. De term wordt vaak gebruikt in de context…
• CSS HTML Validator - Wikipedia: CSS HTML Validator (voorheen CSE HTML Validator genoemd) is een HTML-editor en CSS-editor voor Microsoft Windows (en macOS, Linux en andere Unix-achtige besturingssystemen…

Veelgestelde vragen

Wat is de beste XHTML-validator?

Het hangt af van het gebruik. Voor formele compliance en audits is de W3C Markup Validation Service de gouden standaard. Om CI/CD te automatiseren is de Nu Html Checker (vnu) het meest praktisch. Voor snelle scripts werkt xmllint perfect. Er is geen enkele xhtml-validator die in elk scenario wint.

Heeft het in 2026 nog zin om XHTML te valideren?

Ja, als u oudere sites onderhoudt, heeft u contractuele nalevingsvereisten of wilt u de grondbeginselen van markup leren. Voor nieuwe projecten is HTML5 gebruikelijk, maar moderne validators dekken dit ook. Validatie als discipline blijft hoe dan ook nuttig.

Garandeert XHTML-validatie dat mijn site toegankelijk is?

Nee. Markup-validatie detecteert structurele fouten die soms de toegankelijkheid beïnvloeden, maar controleert geen zaken als alternatieve afbeeldingstekst, kleurcontrast, toetsenbordnavigatie of formulierlabels. Naast validatie heb je specifieke toegankelijkheidstools nodig (axe, WAVE, Lighthouse).

Kan ik XHTML valideren via de opdrachtregel?

Ja. xmllint --valid controleert of het goed is opgemaakt en geldig is ten opzichte van de DTD, en de Nu Html Checker kan worden uitgevoerd als een JAR- of Docker-container met uitvoer in JSON of XML. Beide zijn ideaal voor integratie in pre-commit hooks of continue integratiepijplijnen.

Wat is het verschil tussen “goed gevormd” en “geldig”?

“Goed opgemaakt” betekent dat het document voldoet aan de syntactische regels van XML: gesloten tags, attributen tussen aanhalingstekens en correcte nesting. “Geldig” is strenger: het is niet alleen goed gevormd, maar respecteert ook de regels van een specifieke DTD of schema (welke elementen en attributen er zijn en hoe ze kunnen worden genest). Een document kan goed opgemaakt zijn, maar niet geldig.

Is de validering van W3C de CSS-validering?

Nee. De W3C Markup Validation Service valideert de markup (HTML/XHTML). Voor CSS is er een aparte dienst, de W3C CSS Validation Service. Dit zijn verschillende tools en het is raadzaam om beide te gebruiken als u een volledige controle van uw stylesheets en uw markup wilt.

Bronnen en verdere lectuur

• W3C Markup Validation Service — de officiële xhtml-validator, op validador.w3.org.
• Nu Html Checker (vnu) — officiële W3C GitHub-repository.
• W3C XHTML 1.0-specificatie (aanbeveling).
• W3C Web Content Accessibility Guidelines (WCAG), voor de toegankelijkheidslaag.
• Libxml2-documentatie voor xmllint.