Standards

The Nu Html Checker is the tool behind validator.w3.org/nu, and it is the closest thing the web has to a reference implementation for conformance checking. It is also considerably more modest about itself than the people who rely on it. Its own documentation describes it as an ongoing experiment in better HTML checking, and adds that its behavior remains subject to change.

What the tool says about itself

That sentence has a practical consequence most teams never plan for. The documentation spells it out: there is no guarantee that if the checker reports zero errors for a document at one point in time, it will report zero errors for that same document later. New checks are added over time. A page that passed last quarter can fail today without anyone having touched it.

The project is equally explicit about what it is not. It states that the checker should not be used to unilaterally enforce pass/fail conformance to any particular specification, and that it is intended solely as a checker, not as a pass/fail certification mechanism. Treating a green result as a certificate reads more into it than its own authors do.

Ask a different question

None of this is an argument for skipping validation. It is an argument for wiring it in with the right expectations. The useful question is not whether the site validates, but whether this change introduced new errors. That is a comparison, not a verdict.

Running your own instance

You are also not obliged to use the public instance. The checker ships as vnu.jar and runs from the command line against files, a directory or a URL. It runs as a standalone HTTP service equivalent to the public one, or as a .war deployed to a servlet container. Docker images, an npm package and a Homebrew formula are published too. The project is MIT licensed, and the jar requires Java 17 or later.

Running your own instance solves two problems at once. It removes a dependency on a public service you do not control, and it pins the version, so the checker only changes when you decide to upgrade it. That answers the stability caveat directly: your build stops moving under you.

The scope is also wider than the name suggests. The checker covers HTML, CSS and SVG, so a single pass catches classes of problems that teams often split across separate tools.

A workable setup

A workable setup follows from all this. Pin a version in your own infrastructure. Run it over the built output rather than the templates, since what ships is what users receive. Record the current error count as a baseline and fail the build when that count rises, rather than when it is merely non-zero. Then upgrade the checker deliberately, and treat the errors that surface as their own piece of work instead of a broken pipeline.

That keeps the real value of validation, which is catching regressions cheaply, without claiming a guarantee the tool explicitly declines to give.