Validation & Debugging

Browsers silently fix broken HTML, so mistakes often go unnoticed — until a layout breaks, a script can't find an element, or a screen reader stumbles. Validators find these problems automatically, and browser developer tools show you what the browser actually built from your code.

Why validate?

When HTML contains errors, each browser "repairs" it in its own way. The result might look fine in one browser and broken in another, or work today and break after a small edit. Valid HTML gives predictable results, better accessibility and fewer mysterious CSS and JavaScript bugs.

Common mistakes validators catch

HTML mistakes.html
<p>Unclosed <strong>bold text
<p>A paragraph containing <div>a div</div></p>
<img src="photo.jpg">
<a href="#"><button type="button">Nested interactive</button></a>
<p id="intro">One</p>
<p id="intro">Duplicate id</p>
<ul><p>Not a list item</p></ul>
ProblemWhy it matters
Unclosed or misnested tagsThe browser guesses where elements end; styles leak
Block elements inside <p>The paragraph is closed early, leaving stray empty elements
Missing altScreen readers may read the file name instead
Interactive elements nested inside each otherUnpredictable clicks and focus; invalid
Duplicate idsgetElementById, labels and fragment links pick the wrong element
Wrong children (e.g. <p> directly in <ul>)Lists and tables are mis-announced and mis-styled

Validator tools

  • W3C Markup Validation Service (validator.w3.org) — paste HTML, upload a file or enter a URL.
  • Editor extensions — HTMLHint, or VS Code's built-in HTML checks, flag problems as you type.
  • Command-line tools — html-validate and the Nu HTML Checker (vnu) run in build pipelines, so invalid HTML never reaches production. (Every example in this course was checked with html-validate.)
$ terminal
npm install --save-dev html-validate
npx html-validate "src/**/*.html"
TXT Output
src/index.html
  12:5  error  <img> is missing required "alt" attribute  wcag/h37
  18:3  error  Duplicate ID "intro"                         no-dup-id

✖ 2 problems (2 errors, 0 warnings)

Reading validator messages

Messages give a line and column number. Fix the first error first: a single unclosed tag can cause a cascade of follow-on errors that disappear once the first one is fixed. Errors are real problems; warnings are suggestions worth considering.

Debugging with developer tools

Press F12 and open the Elements (Chrome, Edge) or Inspector (Firefox) panel.

  • The DOM tree shows what the browser actually built — after any automatic fixes. Compare it with your source: if an element appears in an unexpected place, your HTML probably has a nesting error there.
  • Hover an element in the tree to highlight it on the page, with its size, padding and margin.
  • Edit HTML and attributes live (double-click, or right-click → Edit as HTML) to test fixes instantly.
  • Styles panel shows which CSS rules apply and which are overridden.
  • Accessibility tab shows each element's role and accessible name — a quick way to check labels and alt text.
  • Console shows JavaScript errors and some HTML warnings, like a form field without an id or name.

View source vs the DOM

Try it yourself
Result

View Page Source (Ctrl+U) shows the HTML exactly as sent by the server. The Elements panel shows the live DOM, including elements added by the browser (like <tbody>) or by JavaScript. When they differ, the difference often explains the bug.

A debugging routine

  1. Validate the page and fix errors from the top.
  2. Inspect the problem element: is it where you expect in the DOM tree?
  3. Check its computed styles and box model.
  4. Check the console for errors.
  5. Reduce the problem: delete unrelated code until the smallest example that still shows the bug remains.

Try it yourself

This snippet has five errors. Find and fix them: an unclosed tag, a misnested tag, a missing alt, a duplicate id and an invalid list child.

Try it yourself
Result
PreviousLoading Performance