Professional Workflow›Extra· 30 min read

Validating Your HTML (W3C Validator)

Run your markup through the official W3C Validator to catch unclosed tags, typos and mistakes a browser silently hides — professional hygiene before you ship.

What you will learn

Explain why valid HTML matters even when the page “looks fine”
Validate a page with the W3C Markup Validation Service
Read a validator error message and fix the markup

Why bother, if it already looks right?

Browsers are extremely forgiving. If you forget a closing </li> or misspell a tag, the browser quietly guesses what you meant and shows something. That sounds helpful, but it hides bugs: a different browser might guess differently, a screen reader might get confused, and search engines may misread your page. Validating means asking an official checker to confirm your HTML follows the rules exactly.

Note: To validate is to check your code against the official HTML specification. The free tool that does this is the W3C Markup Validation Service at validator.w3.org — run by the W3C, the organisation that defines what HTML is.

A page that “works” but is actually broken

Here is markup that a browser will happily display, yet it contains three real mistakes: a list item with no closing tag, an unquoted attribute value, and a misspelled tag. Read it and see if you can spot them before the validator does.

Looks okay in a browser — but it is not valid

<h1>My Courses</h1>
<ul>
  <li>HTML
  <li>CSS</li>
</ul>
<img src=logo.png alt="Logo">
<strang>Important note</strang>

Reading it line by line: the first <li>HTML is never closed; the <img> uses src=logo.png with no quotes around the value; and <strang> is a typo for <strong> — there is no such tag as strang. A browser shrugs and shows the page anyway, which is exactly why these slip through unnoticed.

Note: Output: In a browser this still renders a heading, a two-item list, an image and some text — so nothing looks obviously wrong. The errors are invisible until a validator points them out.

How to validate your page

The validator gives you three ways to submit your HTML. Pick whichever fits where your page lives:

Go to validator.w3.org in your browser.
Choose a tab: Validate by URI (paste a live web address), Validate by File Upload (choose an .html file from your computer), or Validate by Direct Input (paste the code straight in).
For practice, click Validate by Direct Input, paste the broken code above, and press Check.
Read the list of errors and warnings it returns — each one names the line and the problem.

For the broken snippet above, the validator reports roughly this — three problems, each tied to a line:

Typical W3C Validator output for the broken page

Error: An img element must have an alt attribute... (passes — alt is present)
Error: End tag "li" implied, but there were open elements.   (line 3)
Error: Quote " or apostrophe expected for attribute value.    (line 6)
Error: Element "strang" not allowed; unknown element.         (line 7)

Each error is a to-do item. “End tag li implied” means line 3’s <li>HTML was never closed — add </li>. “Quote expected for attribute value” means wrap logo.png in quotes: src="logo.png". “Unknown element strang” means fix the typo to <strong>. Fix all three, re-run, and you want to see the green “Document checking completed. No errors or warnings to show.”

Note: Output: After fixing all three mistakes and re-validating, the page shows a green success bar: “Document checking completed. No errors or warnings to show.”

When to validate

Before you hand a page to a client or push it live.
When something renders oddly and you cannot see why — an unclosed tag is often the culprit.
Whenever you copy markup from the internet, to confirm it is clean before trusting it.

Tip: Validation checks structure, not good taste. A page can be 100% valid and still use <h4> for the main title or skip alt text in spirit. Pair validation with the Style Guide and Accessibility lessons for truly professional markup.

Watch out: Do not chase every warning to zero — warnings are advice, not errors. Always fix the red errors (real rule violations); read the yellow warnings and apply the ones that make sense.

Q. Why validate HTML if the page already looks correct in your browser?

Answer: Browsers forgive and guess around mistakes, so a page can look fine while hiding real errors. The validator surfaces those so you can fix them before they cause trouble elsewhere.

✍️ Practice

Paste the broken snippet above into validator.w3.org (Direct Input), then fix every error until you get the green “No errors” message.
Validate one of your own earlier project pages by File Upload and fix anything it flags.

🏠 Homework

Take your Personal Profile Page, run it through the validator, and make it pass with zero errors. Keep a note of what you had to fix.