The W3C Markup Validator

Validate by URL (paste the page URL), by file upload, or by direct input (paste HTML). URL is best for production pages; direct input is useful during development when the file is not yet live anywhere.

Errors list a line number, a snippet of the offending markup, and an explanation. Fix top-down — many errors are cascading consequences of one earlier mistake. After fixing the first few, re-run to see how many warnings remained legitimate.

Errors are spec violations that may break rendering. Warnings are suspicious patterns that are technically valid but probably unintended (typo-suspicious attribute names, accessibility hints). Treat errors as must-fix and warnings as worth investigating.

Missing alt on img. Unclosed self-closing tag (<br> rather than the legacy <br/> which is also valid). Duplicate id on the page. Form label without a for-attribute matching an input id. Nested interactive elements (a button inside an a). These five account for most validator output.

If your HTML is generated by templates, validate the final output (the rendered page) rather than the template source. A {{ }} placeholder is not valid HTML — only what the engine produces matters. Run the validator in CI against rendered pages from a test build.

For CI integration, use the html-validate npm package: npx html-validate "public/**/*.html" validates every page in a build. Configure rules in .htmlvalidate.json. Use this to fail builds on validation regressions.

Linting at write-time (stylelint for CSS, eslint-plugin-jsx-a11y for React) catches many issues before they reach the validator. Combine with end-to-end validation in CI for layered defense — catch most issues early, catch the rest before deploy.

Validation checks markup correctness, not semantics. A page with every heading as <h6> is valid HTML but bad semantics. Lighthouse accessibility audits and manual review catch semantic issues that the validator does not.

Missing <!doctype html> triggers Quirks Mode — browsers use a legacy compatibility layer that breaks modern CSS. The validator flags missing doctype as the first error; never deploy a page without the doctype declaration.

Run validation on every PR via GitHub Actions: install html-validate, run it against the built site, fail the PR if errors are present. New errors get caught at review time instead of accumulating over months and becoming overwhelming to fix retroactively.

The W3C Markup Validator parses HTML against the spec and reports invalid markup. Use it via web UI for one-off checks and via html-validate CLI in CI for continuous coverage. Common issues: missing alt, duplicate ids, missing doctype, nested interactive elements. Validation catches markup errors; pair with Lighthouse and manual review for semantic and accessibility quality.