The following notes and warnings highlight missing or conflicting information which caused the validator to perform some guesswork prior to validation, or other things affecting the output below. If the guess or fallback is incorrect, it could make validation results entirely incoherent. It is highly recommended to check these potential issues, and, if necessary, fix them and re-validate the document.
No Character encoding declared at document level
No character encoding information was found within the document, either in an HTML meta
element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.
See this tutorial on character encoding for techniques and explanations.
Using Direct Input mode: UTF-8 character encoding assumed
Unlike the “by URI” and “by File Upload” modes, the “Direct Input” mode of the validator provides validated content in the form of characters pasted or typed in the validator's form field. This will automatically make the data UTF-8, and therefore the validator does not need to determine the character encoding of your document, and will ignore any charset information specified.
If you notice a discrepancy in detected character encoding between the “Direct Input” mode and other validator modes, this is likely to be the reason. It is neither a bug in the validator, nor in your document.
The uploaded document was successfully checked as http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd. This means that the resource in question identified itself as "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd" and that we successfully performed a formal validation of it. The parser implementations we used for this check are based on OpenSP (SGML/XML) and libxml2 (XML).
If you use CSS in your document, you can check it using the W3C CSS Validation Service.