XML Validator

Three layers of validation

First comes the markup layer: closed tags, quoted attributes, known entities, declared prefixes. Then structure: against an XSD schema if you pasted one, or against built-in rules if the document is recognized by its root element. And separately, the things that do not break the markup but make life hard for whoever receives the file.

An error is reported with the path to the element, something like /yml_catalog/shop/offers/offer[37]/price, the line number, and a hint on what to fix. With the path, you can find it in a file with thousands of identical elements.

The first error is exact, the rest are estimates

A standard-conforming XML parser stops at the first markup error: after that it can no longer tell text from tags. The line and column of that error are guaranteed, and you see a snippet of the source with a pointer to the exact spot.

Fixing one error per run is slow, so the tool continues with a lenient pass: bare ampersands, foreign entities, unclosed and mismatched tags, unquoted attributes. These findings are marked as estimates.

XSD schema

Paste a schema into the second field and the document is checked against it: required elements and their order, sequence, choice, and all, occurrence counts, attributes with use="required", built-in types from xs:int to xs:dateTime, restrictions such as enumeration, pattern, length and value ranges, type extensions, element and attribute groups.

Encoding and cleanup

The file encoding is read from its first line, so 1C exports in Windows-1251 open without garbled characters. Price lists and exports often carry prices, addresses, and phone numbers, so check what you share before sending it. To turn the document into a readable form, use XML formatting.