Information on W3C validation

What is W3C validation?

Validation is the process of checking a page's source code against the published rules of the HTML language, the standards maintained by the World Wide Web Consortium and the WHATWG. In plain terms, a validator reads your markup the way a browser does and reports everything that does not follow the rules: an element that was opened and never closed, a tag placed where it is not allowed, an attribute that does not exist, a value that makes no sense for the attribute it belongs to, or a construct that was removed from the language years ago.

It is worth being clear about what validation is not. It does not judge your design, your content, your loading speed or your security. A page can be perfectly valid and completely useless, and a page with a handful of errors can be excellent. Validation checks one thing: whether the document you wrote is the document a machine will read.

Is it important to have W3C-validated pages?

Important rather than mandatory, and for reasons that are more practical than ceremonial.

Browsers guess, and they do not all guess alike

Invalid markup is never rejected by a browser. It is repaired, using error handling rules that have accumulated over decades. The repair usually produces something sensible, and sometimes produces a document tree quite different from the one you had in mind, with your content nested inside an element you never intended. That is where the layout bug that only appears in one browser comes from, and why it takes an afternoon to track down.

Machines other than browsers are far stricter

Screen readers, automated testing tools, content extractors and search engine crawlers all build their understanding from the structure of your document. They have far less tolerance for ambiguity than a browser rendering pixels. A broken structure becomes a navigation problem for someone using assistive technology, which is covered in detail on our page about validation and accessibility.

It saves your own time

A page full of errors is harder to work on. Styles apply to the wrong branch, a small change produces an unexplained shift elsewhere, and the mistakes propagate the moment the file becomes a template. Validating early, while a site is being built, costs minutes. Validating a site that has been growing for five years costs an afternoon, which is still worth it, but the first option is cheaper.

How does the W3Cvalidator.com tool work?

You give it one address, usually your home page. The tool downloads that page, submits it to a markup checking engine, and at the same time collects every link it contains that stays inside your domain. Those links go into a queue, and the process repeats until the queue is empty or the limit of 1500 pages is reached.

Because a single web request cannot run for several minutes on shared hosting, the work is split into short steps and the page refreshes itself to trigger the next one. The progress bar tells you where the run has got to. When it ends, you get one entry per page, with the number of errors and warnings, and a link to the detailed report explaining each message line by line.

What the tool does not do is correct anything. Automatic repair of markup is unreliable, because the same broken structure can be fixed in several places and only the author knows which was intended. What you get is a map: where the problems are, how many of them, and which page to open first. The detailed reports and our page on common HTML errors handle the rest.

Where to start if the report looks bad

Sort the problem by cause rather than by page. Because most sites are generated from templates, the same error usually appears on every page at once, and the number in the summary is the number of pages affected rather than the number of mistakes made. Open the page with the highest count, fix what you find in the template, and run the analysis again. Counts that look catastrophic usually collapse after two or three corrections.

Work in this order: character encoding and language first, since they are one line each and they affect how everything else is read. Then unclosed elements, which can generate a cascade of unrelated messages. Then obsolete elements and attributes, which are mechanical replacements. Then the warnings, one at a time, deciding for each whether it applies to you.