Validating HTML (W3C Validator) — HTML

Validating HTML (W3C Markup Validator)

Browsers are remarkably forgiving of broken HTML—they'll silently auto-correct a missing closing tag or a duplicate ID rather than showing an error page. That forgiveness is a double-edged sword: your page might look fine while quietly confusing browsers, assistive technology, and other tools that parse your markup more strictly. Validation catches those hidden problems before they cause visible bugs.

The W3C Markup Validator

The W3C Markup Validator checks a document against the official HTML specification and reports every syntax error and warning it finds. It accepts input three ways:

By URL — validate a live, publicly accessible page.
By file upload — validate an HTML file from your computer.
By direct input — paste raw HTML into a textarea.

Why Valid HTML Matters

Validation isn't a bureaucratic box-ticking exercise—invalid markup causes real, if sometimes subtle, problems.

Consistent rendering — different browsers recover from broken markup differently, so invalid HTML can render one way in Chrome and subtly differently in Safari or Firefox.
Easier debugging — a validator points to the exact line and reason for an error, versus hunting for a rendering glitch caused by an unclosed tag three sections up.
Accessibility tooling — many automated accessibility checkers and screen readers assume roughly well-formed markup; malformed HTML can produce incorrect accessibility-tree output.
SEO crawling — while search engines are also forgiving, severely broken markup (like unclosed elements swallowing large chunks of a page) can hide content from crawlers unintentionally.
Future maintainability — valid markup is far easier for the next developer (or your future self) to read, edit, and reason about.

Common Validation Errors

Here are the errors you'll run into most often, and how to fix them.

Error	Cause	Fix
Element X not allowed as child of element Y	Invalid nesting, e.g. a block element inside <p>	Move the element outside, or use an element that permits it
Duplicate ID Z	The same id value used on more than one element	Make every id attribute unique on the page
Attribute X not allowed on element Y	Using an attribute the element does not support	Remove it or move it to the correct element
End tag X seen, but there were open elements	A tag was closed while other tags inside it were still open	Close inner tags before closing the outer one
Unclosed element X	A non-void element is missing its closing tag	Add the missing closing tag
The value of attribute X must not be empty	A required attribute (like alt or href) has an empty value where not intended	Provide a value, or intentionally leave alt="" for decorative images

Example: Finding and Fixing an Error

broken.html

HTML

<ul>
  <li>First item
  <li>Second item</li>
</ul>

<p>A paragraph with a <div>nested block</div> inside it.</p>

Running this through the validator reports two problems:

Error: End tag "li" implied, but there were open elements. (line 2)
Error: Element "div" not allowed as child of element "p" in this context. (line 5)

fixed.html

HTML

<ul>
  <li>First item</li>
  <li>Second item</li>
</ul>

<div>A block with a <div>nested block</div> inside it.</div>

Validate early and often

Run new pages through the validator while you're still building them, not only at the end. Fixing one nesting mistake is trivial; untangling a page full of them later is not.

Validating Directly from a Text Editor

Most editors have extensions that run validation-like linting as you type, catching issues before you ever open the W3C tool—useful for a tighter feedback loop during development.

VS Code: the built-in HTML language service flags many structural issues automatically.
ESLint plugins for JSX-based templates can catch some invalid attribute usage.
Browser DevTools console sometimes logs parser warnings for severely malformed markup.

A validator checks syntax, not semantics

A page can be 100% valid HTML and still use the wrong element for the job—a <div> where a <button> belongs is perfectly valid, just not semantic. Validation is a floor, not a ceiling—pair it with the semantic best-practices checklist.

Doctype is required for standards mode validation

Always include <!DOCTYPE html> at the very top of the document. Without it, the validator (and the browser) may fall back to quirks mode, which changes how errors are reported and how the page renders.