## User's guide for the W3C Markup Validator

### Table of contents

### Quick Start

Just type (or Cut&Paste) the URL for the page you want to validate into the text field on the form and press the "Validate this page" button.

If you have a local file you want to validate, choose the "File Upload" link from the navigation menu. Select the button labeled "Browse..." (or something like that, depending on your browser) and choose the file you want to upload in the usual manner for your OS.

Alternatively, you can also copy and paste the complete markup (including a DOCTYPE declaration) for a document in the "direct input" box.

### Introduction

The W3C Markup Validation Service is a web gateway to SGML and XML parsers, and various other specialized validation services. The underlying implementations will take your document and compare it to a set of objective syntax rules for the submitted document. For example for HTML documents this set of rules is called a "DTD", a Document Type Definition. This way you can be sure your HTML is really valid and not just that it conforms to some random programmer's idea of "nice" HTML. Note that valid HTML does not guarantee that your pages will work OK in all browsers. Most of them are severely broken and you may need to find alternate ways of achieving your goal.

When you send an URL to the W3C Markup Validation Service, it will fetch that URL and feed it to the underlying parsers. If you upload a file it'll get fed directly into the parsers. We then take the output produced by the parsers and format it nicely as HTML and send it back to your web browser.

The W3C Markup Validation Service is not generating the error messages - they are all generated by the underlying parsers - but it is appending short explanations and suggested fixes for each error. We provide a feedback channel for users to suggest better explanations and more accurate solutions.

### Calling/Linking to the Validator

You can link directly to the Validator home page, or you can call the Validator CGI program. The home page is <http://validator.w3.org/> at the moment (and for the foreseeable future) and the CGI program can be reached at <http://validator.w3.org/check>.

If you call the CGI program with the "uri=referer" query string parameter (i.e. <http://validator.w3.org/check?uri=referer>) it will fetch the referring document and validate that. This means that if you embed a link to that URL in your pages, following on that link will send you the validation results for that page.

You can also link to the validation results for a specific page. You do this by giving "check" an "uri" parameter pointing at the page you want to validate. For example <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.example.com%2F> will validate the www.example.com home page.

The various options are listed below in the section "Options and Parameters" in parenthesis after the long name. To add options to your links directly, append the options separated by a semicolon. For example <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.example.com%2F;ss=1;outline=1> will validate the example.com home page with "Show Source", and "Outline" on, but "Verbose" off.

All parameter values should be encoded in the UTF-8 character encoding (before URI escaping them).

You may also see these separated by ampersands, but this usage is deprecated and support may be removed at some time in the future.

#### Calling the validator's API

The Validator can also be called by programs through its API. See full documentation for details.

### Options and output formats

#### Options and Parameters

In addition to the text field where you enter an URL -- or the file selection field if you are uploading files -- there are a few checkboxes that alter the behaviour of the validator.

These options are:

Encoding

  This allows you to override the character encoding information about your document. You may use this option for test purposes, but you will eventually have to serve your document with the correct character encoding, or the validator will complain about it and you document will not be valid.

Use Fallback instead of Override (Encoding) (`fbc`)

  Uses the character encoding override mechanism described above, but only does it as a fall back mechanism if the actual document is not served with character encoding information. Think of this as a gentler override mechanism.

Document Type (Doctype) (`doctype`)

  This allows you to override the DOCTYPE declaration for your document. You may use this option for test purposes, but you will eventually have to serve your document with the correct DOCTYPE declaration, or the validator will complain about it and you document will not be valid.

Use Fallback instead of Override (Type) (`fbd`)

  Uses the Doctype override mechanism described above, but only does it as a fall back mechanism if the actual document does not have a Doctype declaration. Think of this as a gentler override mechanism.

Show source input (`ss`)

  Displays the HTML source of the document you validated and links error messages directly to lines in this output. Makes it easy to see what's wrong.

Show an outline of this document (`outline`)

  Will generate an outline of your document from the H1 - H6 elements. For a properly formed document, this will be a nicely nested tree structure. The visualization of your document's structure makes it easier to see where you've skipped a heading.

  If you want to examine the semantic structure of your documents, beyond the outline, try the Semantic data extractor.

Validate error pages (`No200`)

  The Markup Validator will usually tell you if the page you tried to validate could not be retrieved (for example, if the server gave a "404 not found" message. In some circumstances you may want to be able to validate the error page sent by the server. This is the option to use then.

Verbose Output (`verbose`)

  This option triggers verbose output. Verbose output adds more explanations and suggestions to the validation results, and gives more information on the resource validated. This makes it a useful option if you prefer to be given as much help as possible; if you prefer more concise reports, leave this option unset.

For Content-Negotiated resources, set a specific `Accept` Header (`accept`)

  This option (experimental, as of 0.8.2) is useful if your Web server is set up to use format negotiation, serving different content based on the preferred/accepted media types of the user agent. The validator can then emulate different HTTP `Accept` behaviors.

  For example, append "`accept=application%2Fxhtml%2Bxml%2C*`" and the validator will send the HTTP Header "`Accept: application/xhtml+xml,*`".

For Content-Negotiated resources, set a specific `Accept-Language` Header (`accept-language`)

  This option (experimental, as of 0.8.2) is useful if your Web server is set up to use language negotiation, serving content in different languages based on the preferred/accepted language setup of the user agent. The validator can then emulate different HTTP `Accept-Language` behaviors.

  For example, append "`accept-language=ja%2Cfr`" and the validator will send the HTTP Header "`Accept-Language: ja,fr`".

Set a specific `Accept-Charset` Header (`accept-charset`)

  This option (experimental, as of 0.8.3) makes the validator send an `Accept-Charset` HTTP header, specifying the character encodings which it will accept from server. This option is mainly used to interface the Markup Validator for Mobile Web Best Practices checking.

Set a specific `User-Agent` Header (`user-agent`)

  This option (experimental, as of 0.8.3) makes the validator send a custom `User-Agent` HTTP header instead of the usual `W3C_Validator/xx.xxxx`. If the value of this parameter is `mobileok`, the validator will output a `User-Agent` string as defined by the Mobile Web Best Practices spec.

#### Output Options

In addition to the HTML output intended for human consumption in a browser, the Validator has some experimental features to generate machine parseable output in a few different forms. To enable these output options, append "`;output=<option>`" to the URL of the validation results (an interface for these options will be provided when they exit the beta stage).

Web Service API (`output=soap12`)
  Using the SOAP1.2 language over HTTP, this defines a web service with an output similar to the API for the W3C CSS validator and Feed Validator. The Full documentation for this API is available. This API is still under development, and subject to change.
JSON (`output=json`)
  Produces output using a JSON (JavaScript Object Notation) formatting equivalent to the JSON output for validator.nu.
EARL/RDF (`output=earl`)
  Produces output in the EARL 1.0 RDF syntax. This output may change or be removed in the future.
Notation3 (`output=n3`)
  Produces output in the Notation3 RDF syntax. This output is currently outdated and may change or be removed in the future.

#### Deprecated options

A number of options once available have been deprecated and are not available any more. These include the Show parse tree and exclude attributes from the parse tree, as well as Show ESIS and Show raw errors options, and the `xml` output option.

### Interpreting the results

In spite of our efforts, interpreting the Markup Validator's error messages isn't quite what you'd call easy. The error messages are generated in the context of a full SGML environment which demands a somewhat higher level of technical detail than your average HTML document. We have set up a page listing errors and their explanations, which should help you find out what meaning lies behind the cryptic messages, and fix your markup.

We're working on ways to make the error messages more friendly, but for now, if the errors explanation page doesn't work for you, or if you wish to suggest a better explanation, our feedback page will help you send your ideas to our public mailing list. This will have the added benefit of letting us know which error messages are causing the most trouble so we can fix those first. Please be as specific as possible and include the exact error message and, preferably, a URL we can validate to see for ourselves.

### Installing a local Validator

You can download the Validator to run on your own system. For Web design departments or agencies it can be a very good idea, saving time and allowing you to not send documents under work or confidential pages over the wire, but it is a complex operation, and is not recommended for average users, for which the free online service at W3C should suffice.

We have created a simple Installation manual, which, along with the Developer's information, should help you install a local instance of the Markup Validator in your own network easily.