HTML Best Practices and Validation: Write Clean, Correct HTML

What you will learn

You’ve spent this whole course learning individual rules — close your tags, write unique ids, always add alt. This lesson is about tying that all together into a habit: how to actually check your HTML is correct using a real tool, what the most common errors look like across a whole page, consistent code style, and a practical pre-launch checklist you can genuinely use on your own projects going forward.

Why valid HTML actually matters

It’s tempting to think “if it looks right in my browser, it’s fine.” Three real reasons say otherwise:

1. Browsers guess when your HTML is broken, and different browsers don’t always guess the same way. Invalid HTML that happens to render correctly in Chrome today isn’t guaranteed to render identically in every browser, on every device, forever.
2. Broken HTML actively breaks accessibility. A missing closing tag, mismatched nesting, or a duplicate id doesn’t just risk a rendering glitch — it can make content genuinely unreachable or misread by a screen reader, even when it looks perfectly fine visually.
3. Clean HTML is dramatically easier to maintain. Six months from now, editing a well-structured, valid page is fast; editing a tangle of unclosed tags and guesswork is slow and error-prone, especially once someone else (or future-you) has to work in it.

The W3C Markup Validator

The official, authoritative tool for checking HTML is the W3C Markup Validator, at validator.w3.org. It’s free, and it checks your actual HTML against the real specification — not a guess, not a linter’s opinion, the actual standard.

You can check your page three ways:

• By URL — paste a live, publicly accessible page’s address.
• By file upload — upload an .html file directly from your computer.
• By direct input — paste raw HTML text straight into a box.

The validator returns a list of errors (things that genuinely violate the HTML specification) and warnings (things that are technically allowed but worth double-checking), each pointing at the exact line number where the problem is.

Make this a real habit, not a one-time exercise. Running a finished page through the validator before considering it “done” — the same way you’d proofread an essay before submitting it — catches real problems you’d otherwise only discover by accident, much later.

The most common validation errors

Here are the errors you’ll actually run into most, most of which you’ve already met individually across this course — this section is about recognising them together, as a full checklist.

1. Unclosed or mismatched tags

<!-- Wrong -->
<p>Welcome to my site.
<div>Some content</div>

<!-- Right -->
<p>Welcome to my site.</p>
<div>Some content</div>

The single most common error of all. Every element that needs a closing tag must have one, and tags must close in the reverse order they opened.

2. Improper nesting

<!-- Wrong: a div cannot go inside a p -->
<p>Some text <div>a box</div> more text</p>

<!-- Right -->
<div>
  <p>Some text</p>
  <p>more text</p>
</div>

You met this specifically with <p> back in your very first lessons — the validator will flag it directly by name.

3. Duplicate id values

<!-- Wrong -->
<div id="card">First card</div>
<div id="card">Second card</div>

<!-- Right -->
<div id="card-1">First card</div>
<div id="card-2">Second card</div>

Every id on a page must be genuinely unique. The validator catches this reliably — a mistake that’s otherwise easy to miss just by looking, since nothing visually looks wrong.

4. Missing required attributes

<!-- Wrong -->
<img src="photo.jpg">

<!-- Right -->
<img src="photo.jpg" alt="A description of the photo">

The validator flags a missing alt on <img> directly, along with a handful of other genuinely required attributes on specific elements (like a <label>’s for, when it isn’t wrapping its input).

5. Invalid attribute values

<!-- Wrong -->
<input type="emial" name="email">

<!-- Right -->
<input type="email" name="email">

A simple typo in an attribute value (as opposed to a broken tag) can be surprisingly hard to spot by eye, since the input still renders as a normal text box either way — the validator catches it instantly.

6. Using an obsolete element or attribute

<!-- Wrong: deprecated -->
<center>Welcome</center>
<font color="red">Warning</font>

<!-- Right: use CSS instead -->
<div style="text-align: center;">Welcome</div>
<span style="color: red;">Warning</span>

You met one of these already — <big> in the text-formatting lesson. <center>, <font>, and several others were removed from the standard the same way, and the validator will flag any of them if they show up in your code (often copied from very old tutorials).

A consistent code style

Beyond strict validity, professional HTML also follows consistent style conventions — not enforced by the browser, but expected by any team (or your own future self) reading the code:

• Lower case tags and attributes. <div class="card">, not <DIV CLASS="card">. Both work, but lower case is the universal convention.
• Double quotes for attribute values. class="card", not class='card' — pick one and stay consistent; double quotes are the more common convention.
• Consistent indentation, typically 2 spaces per nesting level, matching what you’ve been doing since the elements-and-tags lesson.
• Always write the closing tag, even on the rare elements where HTML technically allows you to omit it (you met this “optional closing tags” quirk early on — never rely on it).
• One clear <h1> per page, semantic landmark elements over generic <div>s, and meaningful alt/id/class names — all the habits this entire course has been building toward.

Editor tools that catch errors as you type

You don’t have to wait until you’re done to catch problems — most modern code editors (like VS Code) show many of these errors live, underlined in red, as you type, often before you’d even think to check the validator. Look for a built-in HTML language feature or a linting extension in whichever editor you use — it turns “catch it at the end” into “catch it immediately,” which is a much faster feedback loop while you’re learning.

A pre-launch checklist

Before calling any real page “finished,” run through this list — it pulls together the most important habits from across this entire course:

1. Run it through the W3C validator and fix every error (warnings are worth a look, but errors are non-negotiable).
2. Every <img> has meaningful alt text (or alt="" for decorative images).
3. Headings are in correct order, one <h1>, no skipped levels.
4. Every form input has a connected <label>.
5. Every id on the page is unique.
6. Semantic landmarks are used — <header>, <nav>, <main>, <footer> — not an all-<div> structure.
7. Test keyboard navigation: Tab through the whole page and confirm focus is visible and the order makes sense.
8. Check <title> and meta description are present, accurate, and unique to this specific page.
9. Check the browser console (right-click → Inspect → Console tab) for any errors your JavaScript or resource loading might be throwing.
10. View the page on an actual phone-sized viewport (or your browser DevTools’ device toolbar) to confirm the viewport meta tag and your layout genuinely hold up.

A complete example of clean, valid HTML

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My Portfolio</title>
  <meta name="description" content="Web developer portfolio showcasing recent projects.">
</head>
<body>
  <header>
    <h1>My Portfolio</h1>
    <nav aria-label="Main navigation">
      <a href="#projects">Projects</a>
      <a href="#contact">Contact</a>
    </nav>
  </header>

  <main>
    <section id="projects">
      <h2>Projects</h2>
      <ul>
        <li>Project One</li>
        <li>Project Two</li>
      </ul>
    </section>
  </main>

  <footer>
    <p>&copy; 2026 My Portfolio</p>
  </footer>
</body>
</html>

This page validates cleanly, uses semantic landmarks correctly, has one <h1>, and includes the meta tags you learned earlier — a genuinely solid template to build any future page from.

Common mistakes

• Only checking that a page “looks right” in one browser, without ever validating the underlying markup.
• Ignoring validator warnings entirely — many are genuinely worth a second look, even if they’re not hard errors.
• Copy-pasting old code containing obsolete elements (<center>, <font>) from outdated tutorials without checking whether the validator flags them.
• Inconsistent quote style or indentation across a single project, making it noticeably harder for anyone (including future-you) to read and maintain.
• Treating validation as a one-time task instead of a habit run on every page before considering it finished.
• Never checking the browser console, missing real errors that a validator (which only checks markup, not JavaScript) wouldn’t catch anyway.

Interview-style questions

Why does HTML validity matter even if a page looks correct in your browser? Browsers silently guess how to render broken HTML, and different browsers don’t always guess the same way — what happens to look fine in one browser today isn’t guaranteed to render consistently everywhere, and invalid markup often breaks accessibility even when it visually appears fine.

What is the W3C Markup Validator, and what three ways can you check a page with it? The official tool (at validator.w3.org) for checking HTML against the real specification. You can check a page by URL, by file upload, or by pasting raw HTML directly.

Name three of the most common HTML validation errors. Unclosed or mismatched tags, improper nesting (like a block element inside a <p>), and duplicate id values are among the most frequent — along with missing required attributes like alt on images.

Why is a consistent code style important even though it isn’t enforced by the browser? It makes code significantly easier to read and maintain, both for other developers and for your own future self returning to the project later.

Practice

1. Use the Practice in Editor button. This example is already clean and valid — try breaking it on purpose (remove a closing tag, duplicate an id) and imagine what the validator would report.

2. Take an HTML file from earlier in this course and run it through validator.w3.org (paste the code directly). Note any warnings, even if there are no hard errors.

3. Go through the 10-point pre-launch checklist against one of your own real pages, and fix anything it surfaces.

4. Fix this code (it has three mistakes: an unclosed tag, a duplicate id, and an obsolete element):

   <div id="box">
     <p>Hello
     <div id="box">Another box</div>
   </div>
   <center>Old-style centering</center>

Recap

• Valid HTML renders more consistently across browsers, supports accessibility properly, and is far easier to maintain long-term.
• The W3C Markup Validator (validator.w3.org) checks your HTML by URL, file upload, or direct input, and flags real errors and warnings with line numbers.
• The most common errors are unclosed/mismatched tags, improper nesting, duplicate ids, missing required attributes like alt, invalid attribute values, and obsolete elements like <center>.
• Consistent style — lower case tags, consistent quotes, consistent indentation, always writing closing tags — makes code easier for anyone to maintain.
• Run a real pre-launch checklist (validation, alt text, heading order, labels, unique IDs, landmarks, keyboard testing, meta tags, console errors, mobile check) before considering any page finished.