We use cookies to ensure that we give you the best experience on our website. You can change your cookie settings at any time. Otherwise, we'll assume you're OK to continue.

Durham University

Computing and Information Services

Producing valid code

There are formal specifications for the markup used on the web. Most browsers will accept code that is incompatible with the specifications (invalid), but this can cause large rendering differences between browsers, and sometimes make a page fail to display.

Web Accessibility Initiative Guidelines

This page explains how to meet:

  • Guideline 3.2: "Create documents that validate to published formal grammars."

Reasons for following these recommendations

While most browsers will attempt to interpret invalid code and display it, their interpretations of how to do so are inconsistent. This can lead to anything from a minor layout change to a page not being displayed in some browsers.

A well-known issue is if a <table> tag is not closed, Netscape 4 will refuse to display anything on the page after the tag, as it requires the end tag for its display routines to work.

While browser interpretations of valid code also differ, the effect is usually only minor layout or display changes (and of course changes between different display media). By writing valid code, it is easier to be confident that a site will display well in browsers you are unable to test it in.

Currently very few pages on the web are valid, which requires browser manufacturers to make browsers that allow for invalid code, increasing development time and the possibility of bugs. A greater proportion of valid pages would allow for quicker development of browsers and useful features.

How to write valid code.

Valid code is produced with reasonable reliability by Dreamweaver. You can convert invalid code to valid code, again with reasonable reliability, by using the tidy program installed on the CIS Unix service.

Infosheet 163: Repairing HTML files with tidy.

You must specify a Document Type Definition for your document. A list of valid document types is available from the W3C. To make use of structural markup easier, the Strict versions of HTML 4.01 or XHTML 1.0 are best. The XHTML doctype has the further advantage that it enforces closing of all tags, which can give better performance in some browsers.

The validation messages from HTML validators can sometimes be a little cryptic. The usual causes of errors are:

  • Unclosed ending tags: Make sure that your tags balance and are all closed in reverse order to being opened (so <em><strong>word</strong></em> not <em><strong>word</em></strong>). Technically under HTML (but not XHTML), some tags do not have to be closed, but more reliable results will be achieved if you close them anyway.
  • Tags contained within the wrong things: <td> tags can only be contained within <tr> tags, for example.
  • Invalid attributes for tags: For example, the <img> tag has a lowsrc attribute supported by some browsers. However, it is not in the official specification, and so can be unreliable to use.
  • Invalid tags: For example, the <blink> tag is supported by some versions of Netscape, but fortunately is not in the official specification.


Checking your page code with a validator is simple and accurate, since the check is of an entirely objective nature. Either the World Wide Web Consortium Validator or the Web Design Group Validator will give the same results, so which is used is a matter of personal taste.

Stylesheets can be checked by the World Wide Web Consortium CSS Checker.