Site icon All About HTML

Debugging HTML: W3C Validator Errors and How to Fix Them

All About Html
W3c validator

Table of Contents

Toggle

Debugging HTML: W3C Validator Errors and How to Fix Them

A w3c validator check is the fastest way to find out whether your HTML is actually correct — not whether it looks right in your browser, but whether it follows the rules of the language. Browsers are forgiving: they will render a page with unclosed tags, duplicate IDs, missing attributes and invalid nesting, and they will usually make it look fine. That forgiveness is the problem. Invalid markup hides bugs that only show up later, in a different browser, on a phone, in a screen reader, or in a search engine’s parser. A validator finds those bugs in seconds, points at the exact line, and tells you what the standard expects instead.

This guide walks through the whole debugging loop: which validator to use, how to run it three different ways, how to read its report without panicking at a wall of red, and how to fix the twelve errors it reports most often — each one with the broken code, the fixed code, and the reason the rule exists. By the end you will have a repeatable workflow that keeps every page you ship at zero errors, including a local checker you can run before anything reaches the server.

Quick Takeaways

1. What the W3C Validator Is — and Which One to Use

1.1 A validator checks your code against the standard

The World Wide Web Consortium (W3C) publishes the rules of HTML. The w3c validator is the free tool that checks a document against those rules and reports every place where the document breaks them. It is not a linter with opinions and it is not a design review: it answers one narrow question — does this document conform to the HTML specification? A page can pass validation and still look terrible, and a page can fail validation and still look perfect in Chrome. Validation is about correctness of the markup, and correctness is what makes a page behave the same everywhere instead of only in the browser you happened to test.

1.2 Nu Html Checker vs the legacy validator

There are two W3C validators, and using the wrong one is the first mistake most beginners make. The modern checker is the Nu Html Checker, at validator.w3.org/nu/. It is the checker for HTML5 — the living HTML standard — and it is the one you should use for every page you write today. The older Markup Validation Service at validator.w3.org is the legacy checker: it validates pre-HTML5 documents against a document type definition (DTD), which is how validation worked before HTML5 removed DTDs. If you paste a modern <!doctype html> page into the legacy validator, you will get confusing results or be redirected to Nu anyway. Bookmark the Nu checker and ignore the old one.

The Nu checker is open source (the vnu project on GitHub) and it is the same engine behind the API, the command-line tool, and the hosted service, so a check you run locally gives the same verdict as the website. That matters when you automate validation later in this guide.

1.3 What validation does — and does not — tell you

Validation catches syntax and structure problems: elements used where they are not allowed, attributes that do not exist on an element, duplicate IDs, unclosed tags, bad character encoding, and obsolete features. It does not catch logic bugs (a form that submits to the wrong URL is perfectly valid HTML), it does not judge your design, and it is not a full accessibility audit — though it does enforce the parts of accessibility that the HTML specification itself requires, such as alt on images and valid ARIA attribute names. It also does not check your CSS or JavaScript; the W3C runs separate validators for those. Treat a clean validation report as a foundation, not a finish line: it means the markup is sound, so the bugs that remain are yours to find another way.

1.4 Why bother if browsers render broken HTML anyway?

Because browsers do not all repair broken HTML the same way. When a browser meets an unclosed <div>, it has to guess where you meant to close it, and different engines guess differently. The result is a layout that works in Chrome on your laptop and breaks in Safari on a phone, or a heading that a screen reader announces as part of the wrong section. Search engines parse your markup too, and malformed structure can confuse the parser that extracts your headings, your structured data, and your content. Valid HTML removes that entire category of risk for free: the same document, parsed the same way, everywhere.

2. Three Ways to Run the W3C Validator

The Nu checker offers three input methods on its front page, and each one fits a different moment in your workflow.

2.1 Validate by URI — check a live page

Paste the page’s public URL and the checker fetches it and validates what the server returns. This is the right method for a page that is already live, because it checks the HTML your visitors actually receive — including anything your server, your CMS, or a plugin injected into the page. The catch is that the page must be publicly reachable: a page behind a login, on your local machine, or on a staging server with basic authentication cannot be fetched. If you see a fetch error instead of a report, the checker could not reach the URL at all, and that is a hosting problem, not a markup problem.

2.2 Validate by file upload — check a page before it goes live

Upload the .html file from your computer. This is the method for work in progress: a template you are building, a page your static site generator just produced, or a file a colleague sent you. It validates exactly the bytes in the file, so it is also the most honest check of a page that a CMS will later modify — if the file is clean and the live page is not, the problem is in the CMS or the theme, not in your markup.

2.3 Validate by direct input — the fastest debugging loop

Paste the code straight into the text area and check it. This is the method to use while you are fixing errors: paste, check, fix the first error, paste again. There is nothing to upload and no URL to wait for, so the loop takes seconds. It is also the method for testing a fragment — a snippet of a component, a form, or a card — because you can wrap the fragment in a minimal document and validate it in isolation, which is how you prove whether the bug is in the component or in the page around it.

2.4 Reading the options before you check

Two options on the form are worth knowing about. Show source displays your document with the offending lines highlighted next to each message, which is the fastest way to see what the checker is complaining about. Show outline lists the heading structure the checker derived from your document — a quick way to spot a broken heading hierarchy. The message filtering options let you hide warnings and show only errors when you are triaging, which is the view you want on a first pass.

3. How to Read a Validator Report

3.1 Errors, warnings, and info messages

Every message in a report has a severity, and the severity tells you how to prioritise. An error means the document violates the HTML standard: an element used where it is not allowed, an attribute that does not exist, a duplicate ID. Errors must be fixed. A warning means something is suspicious but not invalid: a section with no heading, a document that declares no language, a character encoding declared late. Warnings deserve attention but some of them are deliberate — a page with no heading in a section may be exactly what you intended. Info messages are context, not problems: they tell you which document type was detected or which encoding was used. Read the errors first, decide on the warnings second, and ignore the info lines.

3.2 Line numbers, columns, and source extracts

Each message gives a line and column number and a short extract of the source around the problem, with the offending characters highlighted. The line number points at where the checker noticed the problem, which is not always where the problem started — an unclosed tag on line 40 can be reported as an error on line 120, where the checker finally realised something was wrong. When a message does not make sense at the line it cites, look backwards for an unclosed element above it.

3.3 The golden rule: fix the first error, then re-validate

A single mistake early in a document can cascade into dozens of messages. One unclosed <div> shifts the nesting of everything after it, so the checker reports every element inside the wrong parent as a separate error. Fixing the first error in the list and re-validating often clears half the report in one move. Never work through a long report from the bottom up, and never try to fix twenty errors in one pass before re-checking — you will fix things that were never broken and miss the one real mistake at the top. The loop is: fix one, re-validate, repeat until the report is green.

4. The 12 Most Common W3C Validator Errors — and How to Fix Each One

These twelve account for the large majority of errors on real sites. Each entry shows the message the Nu checker reports, the broken code, the fixed code, and why the rule exists.

4.1 Error 1: Unclosed element

The message: Unclosed element div — or, more confusingly, End tag for body seen, but there were unclosed elements.

Broken code:

<div class="card">
  <h2>Our services</h2>
  <p>We build websites, shops and landing pages.
</div>

Fixed code:

<div class="card">
  <h2>Our services</h2>
  <p>We build websites, shops and landing pages.</p>
</div>

The <p> was never closed, so the browser has to guess where the paragraph ends — and its guess becomes the parent of everything that follows. This is the single most common validator error and the most common cause of cascading reports: close the element and half the errors below it vanish. A good editor that highlights matching tags, or a formatter that runs on save, catches this before the validator ever sees it.

4.2 Error 2: Stray end tag

The message: Stray end tag div — or Stray end tag span.

Broken code:

<p>Welcome to our site.</p>
</div>

Fixed code:

<p>Welcome to our site.</p>

A closing tag with no matching opening tag. It usually appears after a copy-paste, after deleting an opening tag and forgetting its closer, or after a template partial that closes a tag opened in a different partial. The fix is to delete the stray tag — but check first that the opening tag was not accidentally deleted somewhere above, in which case the real fix is to restore it.

4.3 Error 3: Duplicate ID

The message: Duplicate ID menu-toggle — or The first occurrence of ID menu-toggle was here.

Broken code:

<button id="menu-toggle">Open menu</button>
<!-- later in the same document -->
<button id="menu-toggle">Close menu</button>

Fixed code:

<button id="menu-toggle">Open menu</button>
<!-- later in the same document -->
<button id="menu-close">Close menu</button>

An id must be unique in a document. Duplicates break getElementById (which returns only the first match), break fragment links (#menu-toggle scrolls to the first one), and break the for attribute on labels. This error appears constantly in repeated components — a card, a modal, or a form field copied three times with the same IDs inside. The fix is to make the IDs unique, or to use a class instead when you need to target several elements at once.

4.4 Error 4: An img element must have an alt attribute

The message: An img element must have an alt attribute, except under certain conditions.

Broken code:

<img src="team-photo.jpg">

Fixed code:

<img src="team-photo.jpg" alt="The four founders standing outside the studio">

Every image needs an alt attribute: screen readers announce it, search engines read it, and browsers display it when the image fails to load. For a purely decorative image, an empty alt="" is correct — it tells assistive technology to skip the image — but the attribute itself must still be present. Write the alt text as a short description of what the image shows, not a keyword-stuffed sentence and not the file name.

4.5 Error 5: Unescaped & in an attribute or text

The message: & did not start a character reference — often with (& probably should have been escaped as &amp;.).

Broken code:

<a href="search.html?q=shoes&size=10">Running shoes</a>
<p>Terms & conditions apply.</p>

Fixed code:

<a href="search.html?q=shoes&amp;size=10">Running shoes</a>
<p>Terms &amp; conditions apply.</p>

A bare & in HTML starts a character reference, so the parser tries to read &size as an entity name and fails. In URLs, escape every & that separates query parameters as &amp; — the browser decodes it back to & when it follows the link, so the URL still works. In text, write &amp; for a literal ampersand. The same rule applies to < and > in text, which must be written as &lt; and &gt; or the parser will read them as the start of a tag.

4.6 Error 6: Bad nesting — a div inside a p, a link inside a link

The message: Element div not allowed as child of element p in this context — or Element a not allowed as child of element a.

Broken code:

<p>Read our guide
  <div class="callout">New: the 2026 edition is out.</div>
</p>
<p><a href="/guide/">Read the guide <a href="/pdf/">(PDF)</a></a></p>

Fixed code:

<p>Read our guide below.</p>
<div class="callout">New: the 2026 edition is out.</div>
<p><a href="/guide/">Read the guide</a> (<a href="/pdf/">PDF</a>)</p>

A <p> element can only contain phrasing content — text, links, emphasis, images — not block-level elements such as <div>, <ul> or another <p>. When the parser meets a <div> inside a <p>, it silently closes the paragraph first, which rearranges your document in a way your CSS does not expect. Links cannot contain other links for the same reason: a click inside a nested link is ambiguous. The fix is to restructure — put the block element after the paragraph, and put sibling links side by side instead of nested.

4.7 Error 7: Obsolete attributes

The message: The align attribute on the p element is obsolete — or The frameborder attribute on the iframe element is obsolete. Use CSS instead.

Broken code:

<p align="center">Welcome back.</p>
<img src="logo.png" border="0">
<iframe src="map.html" frameborder="0"></iframe>

Fixed code:

<p style="text-align: center;">Welcome back.</p>
<img src="logo.png" alt="Company logo">
<iframe src="map.html" title="Office map" style="border: 0;"></iframe>

HTML used to carry presentational attributes — align, bgcolor, border, frameborder, cellpadding — and all of them are obsolete in HTML5. The validator flags every one of them, and the fix is always the same: move the presentation to CSS. This error appears most often in old content, in code copied from decade-old tutorials, and in HTML emails pasted into pages. Note the title added to the iframe in the fixed code: a frame without a title is an accessibility failure, and the validator flags that separately.

4.8 Error 8: Bad value for an attribute

The message: Bad value 100% for attribute width on element img: Expected a digit but saw % instead — or Bad value for attribute href on element a: Illegal character in query.

Broken code:

<img src="photo.jpg" width="100%" alt="A garden">
<a href="/page with spaces.html">Our page</a>

Fixed code:

<img src="photo.jpg" style="width: 100%;" alt="A garden">
<a href="/page%20with%20spaces.html">Our page</a>

The width attribute on an image takes a number of pixels, not a percentage — percentages belong in CSS. And a URL with literal spaces is not a valid URL: encode the spaces as %20, or better, rename the file without spaces. The same class of error covers unquoted attribute values that contain spaces (class=btn primary is read as class="btn" plus a stray attribute), and attribute values with characters the attribute does not accept. When the validator says “bad value”, it is telling you the value does not match the type the attribute expects.

4.9 Error 9: Element not allowed as a child here

The message: Element li not allowed as child of element div in this context — or Element h1 not allowed as child of element button.

Broken code:

<div class="menu">
  <li>Home</li>
  <li>About</li>
</div>

Fixed code:

<ul class="menu">
  <li>Home</li>
  <li>About</li>
</ul>

List items belong inside <ul>, <ol> or <menu>; table cells belong inside rows; options belong inside a <select> or <datalist>. The content model of each element is part of the standard, and the validator enforces it. This error usually means a wrapper element was changed during a redesign — the <ul> became a <div> for styling — while the children were left as they were. Restore the correct parent, or change the children to match the new parent.

4.10 Error 10: Missing doctype or character encoding

The message: Start tag seen without seeing a doctype first — or Changing character encoding to UTF-8 / The character encoding was not declared.

Broken code:

<html>
<head>
  <title>My page</title>
</head>

Fixed code:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My page</title>
</head>

A document without <!doctype html> renders in quirks mode, where browsers emulate the layout bugs of the 1990s — box sizing, font sizing and table rendering all change. The doctype must be the very first thing in the file, before any whitespace or comment. The meta charset tag should be the first element inside <head>: if the browser has to guess the encoding, non-ASCII characters (accented letters, emoji, currency symbols) can arrive garbled, and the validator will say so. The lang attribute on <html> is technically a warning rather than an error, but add it anyway — screen readers use it to pick the right pronunciation.

4.11 Error 11: Attribute not allowed on this element

The message: Attribute href not allowed on element div at this point — or Attribute placeholder not allowed on element select.

Broken code:

<div href="/about/">About us</div>
<select placeholder="Choose a country">
  <option>France</option>
</select>

Fixed code:

<a href="/about/">About us</a>
<select aria-label="Choose a country">
  <option value="">Choose a country</option>
  <option>France</option>
</select>

Every attribute belongs to specific elements, and using one on the wrong element is an error even when the browser ignores it silently. A div with an href does nothing — the attribute is dead code that only confuses the next developer. A select has no placeholder attribute at all; the correct pattern is a first option with an empty value that acts as the prompt. If you are reaching for an attribute and the validator rejects it, the attribute probably does not exist where you are using it — check the element’s documentation rather than fighting the checker.

4.12 Error 12: End tag seen without a matching start, inside a table

The message: End tag for table seen, but there were unclosed elements — or A table cell was implicitly closed, but there were open elements inside it.

Broken code:

<table>
  <tr>
    <td>Apples
    <td>Oranges</td>
  </tr>
</table>

Fixed code:

<table>
  <tr>
    <td>Apples</td>
    <td>Oranges</td>
  </tr>
</table>

Tables are the strictest structure in HTML: every cell must be closed before the next cell opens, every row must be closed before the next row opens. A missing </td> does not just look untidy — the parser recovers by closing the cell where it thinks you meant to, which can merge two cells, shift a column, or swallow the rest of the row. Validate table markup by direct input whenever you edit a table by hand, and treat any table error as a sign to check every row, not just the one the message cites.

5. A Complete Before-and-After: One Broken Document, Fixed

Reading about single errors is one thing; seeing a whole document go from red to green is another. Here is a small page with five errors in it — the kind of page a beginner writes in an afternoon — followed by the corrected version. Paste the broken version into the Nu checker by direct input and you will see the report this section describes.

Before — 5 errors:

<!doctype html>
<html>
<head>
<title>Our bakery</title>
</head>
<body>
<div class="hero">
<h1>Fresh bread, every morning</h1>
<p>We bake sourdough, rye & wholemeal loaves daily.
<img src="bread.jpg">
<p>Visit us at <a href="visit.html?day=today&time=morning">the shop</a> any morning.</p>
</div>
</body>
</html>

The checker reports: no character encoding declared; no lang attribute (warning); an unclosed <p>; an img without alt; and a bare & in the link URL. One unclosed paragraph also makes the second paragraph a child of the first, which the checker flags as bad nesting — so five mistakes produce six or seven messages.

After — 0 errors:

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Our bakery</title>
</head>
<body>
<div class="hero">
<h1>Fresh bread, every morning</h1>
<p>We bake sourdough, rye &amp; wholemeal loaves daily.</p>
<img src="bread.jpg" alt="A loaf of sourdough on a wooden board">
<p>Visit us at <a href="visit.html?day=today&amp;time=morning">the shop</a> any morning.</p>
</div>
</body>
</html>

Five small changes — a doctype already present, a lang attribute, a charset declaration, two closed tags, one alt attribute, two escaped ampersands — and the document validates cleanly. Notice how little changed: validation is rarely a rewrite. It is a proofread with a tool that never gets tired.

6. Errors vs Warnings: What to Fix, What to Ignore

Not every message deserves the same urgency. Use this table to triage a report.

MessageSeverityAction
Unclosed element / stray end tagErrorFix — it changes how the document is parsed
Duplicate IDErrorFix — it breaks scripts, links and labels
An img element must have an alt attributeErrorFix — required by the standard
& did not start a character referenceErrorFix — escape it as &amp;
Element not allowed as childErrorFix — restructure the nesting
Obsolete attributeErrorFix — move the styling to CSS
Bad value for attributeErrorFix — the value does not match the attribute’s type
Consider adding a lang attributeWarningFix — one attribute, real accessibility benefit
Section lacks headingWarningFix if the section is a real section; ignore if it is a styling wrapper (use a <div> instead)
The type attribute is unnecessary for JavaScript resourcesWarningIgnore or remove — type="text/javascript" is the default and the attribute is redundant
Document checking completed, no errorsInfoCelebrate — the document is valid
The document is valid HTML5 plus ARIA, SVG 2, MathML 2, RDFa, MicrodataInfoContext only — it describes which checks ran

The pattern is simple: errors are always worth fixing, because they mean the document does not conform. Warnings are judgement calls, and the right call is usually to fix the ones that cost one line and ignore the ones that describe a deliberate choice. A report with zero errors and two understood warnings is a healthy document.

7. Validating Locally and in Your Build

The hosted Nu checker is excellent for one-off checks, but a workflow that depends on remembering to visit a website will eventually be skipped. Run validation where the code already lives.

7.1 The Nu checker on the command line

The same vnu engine runs locally as a Java program. Download the checker from the validator project’s GitHub releases, then check a file with a single command:

java -jar vnu.jar --errors-only site/index.html

The --errors-only flag hides warnings and info messages so the output is just the errors. Point it at a whole directory to check every page in a site at once, and add it to your build script so a page with errors fails the build before it can be deployed. A Docker image is available for machines without Java.

7.2 The validator API

The hosted Nu checker has a simple HTTP interface: send a document or a URL to https://validator.w3.org/nu/?out=json and the report comes back as JSON. That is the hook for continuous integration — a GitHub Action or a deploy script that validates every changed page and blocks the deploy on errors. The API is free and requires no key, but it is a shared public service, so keep the request rate reasonable and run heavy batch checks against a local vnu instance instead.

7.3 Editor and browser helpers

Most editors can validate as you type. The Webhint extension for VS Code runs the Nu checker (among other checks) inside the editor and underlines problems the moment you save. Browser extensions add a validate-this-page button to the toolbar, which is the fastest way to check a page you are already looking at. None of these replace the hosted checker for a final verdict, but they move the feedback from “after deployment” to “while typing”, which is where it is cheapest to act on.

7.4 Validate the template, not just the page

On a CMS or a static site generator, one template produces hundreds of pages. A single unclosed tag in a header partial is an error on every page of the site — and a single validation of one generated page finds it. Validate one page from each template (home, article, listing, form, search results) rather than every page, and re-validate a template whenever it changes. When a site-wide error appears on many pages at once, the cause is almost always a shared partial, not the individual pages.

8. W3C Validator vs Other HTML Checkers

CheckerWhat it checksBest for
Nu Html Checker (validator.w3.org/nu)Conformance to the HTML standardThe final verdict on any page; free, authoritative
Legacy W3C Markup Validator (validator.w3.org)Pre-HTML5 documents against a DTDOld XHTML/HTML 4 documents only
HTMLHint / eslint-plugin-htmlConfigurable style rules (attribute order, tag pairing, best practice)Team style rules the standard does not cover
Editor validation (VS Code + Webhint)Nu checker results plus accessibility and performance hints, liveCatching errors while typing
Browser DevTools (Elements panel)The parsed DOM after the browser repaired the markupSeeing how the browser interpreted broken markup — compare with your source to find the repair
axe / Lighthouse accessibility auditsAccessibility rules, some of which overlap with validationAccessibility specifically, not markup conformance

The Nu checker is the authority on conformance; the others are complements. HTMLHint can enforce rules the standard does not care about, such as whether attribute values are quoted or whether tags are lowercase. DevTools is useful in exactly one debugging situation: when the validator reports an error you cannot see in your source, open the Elements panel and compare the parsed DOM with your source — the difference shows you where the browser repaired your markup, and the repair points at the mistake.

9. A Zero-Error Workflow That Actually Sticks

  1. Validate while writing. Use direct input for the page you are working on, and fix the first error before writing more code. An error found in a 40-line page is a one-minute fix; the same error found in a 400-line page is a search.
  2. Validate every template. One check per template covers every page that template generates. Add it to your definition of done for template work.
  3. Validate after every deploy. Check the live URL of each changed page. A page that was valid in development can break in production when a plugin, a minifier or a CMS filter rewrites its markup.
  4. Keep a zero-error baseline. Fix the errors on your existing pages once, then treat any new error as a regression. A site that starts with 300 errors never gets to zero; a site that starts at zero stays there with almost no effort.
  5. Re-validate after CMS and plugin updates. WordPress plugins and themes inject markup into your pages. After an update, spot-check the pages the plugin touches — a new error that appears on every page the day after an update is the plugin’s, and you want to know that before your visitors do.

Frequently Asked Questions

1. Is the W3C validator free to use?

Yes. The Nu Html Checker at validator.w3.org/nu is free, with no account, no key and no usage limit for normal manual checks. The command-line version is open source and free to run locally, and the API is free for reasonable use. There is no paid tier and no feature locked behind a login.

2. Does passing the W3C validator improve my Google ranking?

Not directly — Google has never listed valid HTML as a ranking factor, and plenty of top-ranking pages have validation errors. What validation does is remove parsing ambiguity: search engines, screen readers and browsers all read your markup more reliably when it is valid, and a page that parses cleanly is less likely to have its headings, content or structured data misread. Think of it as removing a handicap rather than gaining a bonus.

3. Should I fix warnings, or only errors?

Fix all errors — they mean the document breaks the standard. For warnings, fix the cheap ones (a missing lang attribute is one line) and the ones that describe real problems (a section with no heading is usually a <div> in disguise). Ignore a warning only when you understand it and the code is deliberate, and say so in a comment so the next person does not “fix” it back.

4. Why does the validator report errors on my WordPress site when my theme is valid?

Because the validator checks the final HTML the server sends, not your theme files. Plugins, widgets, shortcodes and embeds inject markup into the page, and any of them can produce invalid HTML — an unclosed tag in a widget, a duplicate ID from two instances of the same plugin, an obsolete attribute in an old shortcode. Validate the live URL, find which part of the page the error sits in, and you will know whether the fix belongs to the theme, a plugin, or your content.

5. The validator says my page is valid but it looks broken. What now?

Validation checks the markup against the standard, not the rendering. A valid page can still look broken because of CSS, JavaScript, a missing file, or a layout mistake that is perfectly legal HTML. Check the browser console for failed resources and JavaScript errors, inspect the element in DevTools, and confirm the CSS file actually loaded. Validation tells you the markup is not the problem — which is useful information, because it narrows the search to everything else.

6. Can I validate HTML inside a JavaScript framework or a single-page app?

Yes, with one adjustment: the hosted validator checks the HTML the server sends, which for a client-rendered app is often a nearly empty shell. Validate the rendered page instead — use the browser’s “view source” on the rendered DOM (or save the rendered page from DevTools) and check that with direct input, or use a headless-browser step in your build that dumps the rendered HTML and pipes it to the local vnu checker. The server-rendered shell and the client-rendered page are two different documents, and both deserve a check.

Conclusion

Debugging HTML with the w3c validator is a short loop with a large payoff: paste the page, read the first error, fix it, re-validate, and repeat until the report is green. The twelve errors in this guide cover almost everything you will ever see — unclosed elements, stray end tags, duplicate IDs, missing alt text, unescaped ampersands, bad nesting, obsolete attributes, bad values, wrong parents, missing doctypes and encodings, misplaced attributes, and unclosed table cells — and every one of them has a one-line or two-line fix. None of them requires a rewrite, and none of them is a matter of opinion: the standard says what is correct, the checker reports where you diverge, and the fix is to conform.

Make the loop a habit and it stops being a chore. Validate while you write, validate every template, validate after every deploy, and keep a zero-error baseline so that a new error is always a regression you catch the same day. Your pages will render the same in every browser, parse cleanly for search engines, and behave predictably for assistive technology — and the next time something looks wrong, you will know within seconds whether the markup is the problem or not.

Related Articles You’ll Love

Exit mobile version