Free HTML validator: which errors actually matter
A validator will hand you 200 errors. Perhaps six of them affect a real visitor. Here is how to tell which, and why the rest are still worth clearing eventually.
By Sapun Lamichhane · Arcetis
Run any real website through a markup validator and you will get a long list. That list is not a ranked list, and treating it as a to-do to work through from the top is how people spend a day fixing things nobody would ever have noticed.
Errors fall into four groups, and only two of them change anything for a visitor.
Which HTML errors actually break something?
- Unclosed and mis-nested elements. These are the ones that matter, because the browser recovers by guessing — and different browsers guess differently. An unclosed element can put half your page inside a container it was never meant to be in, which changes styling, changes what a screen reader announces, and changes what a crawler thinks your content belongs to.
- Duplicate id attributes. An id must be unique. Duplicates silently break label-to-input association, in-page anchor links, and any script that queries by id. Nothing errors; things just quietly stop working.
- Missing required attributes. A missing alt is an accessibility failure with real consequences. A missing lang means a screen reader guesses pronunciation.
- Everything else — obsolete attributes, stray trailing slashes, deprecated elements. Worth clearing, but not before the three above.
Why one error becomes fifty
Validation errors cascade. A single unclosed div near the top of the document produces an error at every subsequent point where the parser's expectation and the markup diverge. Fix the original and the rest vanish.
This is why the error count is a poor measure of health, and why the only sensible method is to fix the first error, re-validate, and repeat. People who work bottom-up or by category end up chasing symptoms.
The rendered DOM is not the response body
Most validators fetch your URL and validate what the server returned. If any part of your markup is built by JavaScript — and on a modern site it usually is — that validator never sees it.
That matters in both directions. Markup conformance is best judged against the raw response, because that is the document the spec describes. But the accessibility and structure problems that affect real users live in the rendered DOM, because that is what a visitor and an assistive technology actually receive. Checking only one leaves a real class of problems invisible.
What this has to do with AI and search
Search engines tolerate bad markup. Answer engines are less forgiving, for a structural reason: an assistant lifting a passage has to work out where it begins and ends, and it uses your element structure to do it. A section that is technically inside the wrong container because of an unclosed element is a section that gets bounded incorrectly, or skipped.
So the cheapest AEO work available on most sites is not adding markup. It is fixing the structural errors that already prevent the markup you have from being read correctly.
What free means here
Our HTML validator is free to run, with no account needed for your first full scan and unlimited quick scans after that. It validates both the raw response and the rendered DOM, and every finding names the rule, quotes the offending markup, and links to the specification it comes from — so you can disagree with it if we are wrong.