Upload an XML file to verify it’s well-formed and quickly identify syntax and structure issues.
XML remains a foundational format for data exchange, configuration, web services, and document markup. Its strict syntax rules — every tag must be closed, attributes must be quoted, elements must be properly nested — mean that even a small typo can render an entire document unparseable. XConvert's free XML Validator checks your XML for well-formedness errors instantly in your browser, pinpointing the exact location and nature of every problem without uploading your data to any server.
.xml file onto the page. The editor supports syntax highlighting to help you spot issues visually.<item> opened at line 12" or "Attribute value not quoted at line 7, column 23").XML validation refers to checking whether an XML document conforms to the rules of the XML specification. There are two levels of validation: well-formedness checking and schema validation. XConvert's XML Validator focuses on well-formedness — the fundamental requirement that every XML parser enforces before any further processing can occur.
A well-formed XML document must satisfy several rules. Every opening tag must have a corresponding closing tag (or use self-closing syntax). Tags must be properly nested — <a><b></b></a> is valid, but <a><b></a></b> is not. Attribute values must be enclosed in matching quotes (single or double). The document must have exactly one root element. Entity references must be properly formed. Character encoding must be consistent with the declaration. Special characters like <, >, & must be escaped when used in text content.
Schema validation goes further by checking whether the document's structure and data types match a predefined schema (DTD, XSD, or RelaxNG). While schema validation is important for application-specific correctness, well-formedness checking is the essential first step — a document that is not well-formed cannot be parsed at all, let alone validated against a schema. Every XML processing pipeline, from simple configuration file loading to complex XSLT transformations, begins with a well-formedness check. If this check fails, no further processing is possible.
| Feature | XConvert XML Validator | xmllint (libxml2) | W3C Markup Validator | Oxygen XML Editor |
|---|---|---|---|---|
| Price | Free | Free | Free | Paid |
| Runs in Browser | ✅ | ❌ (CLI) | ✅ | ❌ (Desktop) |
| No Installation | ✅ | ❌ | ✅ | ❌ |
| Well-Formedness Check | ✅ | ✅ | ✅ | ✅ |
| Line-Level Errors | ✅ | ✅ | ✅ | ✅ |
| Namespace Validation | ✅ | ✅ | ✅ | ✅ |
| DTD/XSD Validation | ❌ | ✅ | ✅ | ✅ |
| Privacy (No Upload) | ✅ | ✅ (local) | ❌ | ✅ (local) |
| Syntax Highlighting | ✅ | ❌ | ❌ | ✅ |
API response debugging — When a SOAP or XML-RPC API returns an error, validate the response XML to determine whether the problem is malformed XML or an application-level error. Well-formed XML that contains an error message is very different from broken XML that cannot be parsed.
Configuration file verification — Many enterprise applications (Java EE, .NET, Apache) use XML configuration files. Validate these files after manual edits to catch typos before they cause application startup failures.
Data feed processing — RSS feeds, Atom feeds, and XML sitemaps must be well-formed to be consumed by feed readers and search engines. Validate your feeds before publishing to ensure compatibility.
Document conversion preparation — Before converting XML to JSON, CSV, or YAML using XConvert's XML to JSON converter, validate the source XML. Malformed XML produces unpredictable conversion results or outright failures.
XSLT and XPath development — When writing XSLT transformations or XPath queries, the source XML must be well-formed. Validate your test documents to ensure transformation errors are in your XSLT, not your data. This saves significant debugging time when working with complex transformation pipelines.
Compliance and interchange — Industries like healthcare (HL7), finance (FIX, XBRL), and publishing (EPUB, DITA) rely on XML for data interchange. Well-formedness is the minimum requirement for any XML document entering these ecosystems. Regulatory compliance often mandates that XML documents pass validation before being accepted into processing pipelines.
XConvert's XML Validator uses a client-side XML parser implemented in JavaScript that follows the XML 1.0 (Fifth Edition) specification. The parser operates in a streaming fashion, reading the document character by character and maintaining a stack of open elements to verify proper nesting. When it encounters a violation — an unclosed tag, an unquoted attribute, an invalid character reference, or a namespace prefix without a corresponding declaration — it records the precise position and generates a human-readable error message.
The validator checks for the complete set of well-formedness constraints. Element names are verified against the XML Name production rules (valid starting characters, no spaces, proper use of colons for namespace prefixes). Attribute uniqueness is enforced within each element — duplicate attributes on the same element are flagged. Character references (both numeric like A and named like &) are validated. The document prolog, including the XML declaration and any DOCTYPE declaration, is parsed and checked for correctness. CDATA sections, processing instructions, and comments are all handled according to the specification.
Namespace handling deserves special mention. The validator checks that namespace prefixes are declared before use, that the default namespace is properly inherited by child elements, and that namespace URIs are syntactically valid. Namespace errors are among the most confusing XML problems because they often produce parser errors that seem unrelated to the actual cause. The validator's error messages specifically identify namespace issues and suggest fixes. All processing happens locally in your browser — your XML data, which may contain sensitive business information, API keys, or personal data, is never transmitted over the network.
Check encoding consistency — If your XML declaration specifies encoding="UTF-8", make sure the file is actually saved in UTF-8. Encoding mismatches cause parser errors on special characters. The validator detects common encoding issues.
Escape special characters — Use < for <, > for >, & for &, " for ", and ' for ' in text content and attribute values. Unescaped special characters are the most common well-formedness error.
Use self-closing tags for empty elements — <br/> is cleaner than <br></br> and avoids potential issues with some parsers. Both are valid, but self-closing syntax is conventional for elements with no content.
Validate before transforming — Always validate XML before applying XSLT transformations or converting to other formats with XConvert's XML to JSON or XML to CSV tools. Invalid input produces unreliable output.
Watch for namespace prefix errors — If you see errors about undeclared prefixes, check that all namespace declarations (xmlns:prefix="uri") are present on the correct ancestor elements.
Validate incrementally during editing — Rather than writing an entire XML document and validating at the end, validate frequently as you build the document. This makes errors easier to locate and fix.
Well-formedness means the XML follows the basic syntax rules of the XML specification (proper nesting, quoted attributes, single root element, escaped special characters, etc.). Validity means the XML also conforms to a specific schema (DTD, XSD, or RelaxNG) that defines allowed elements, attributes, and data types. XConvert checks well-formedness, which is the prerequisite for all XML processing. A document must be well-formed before it can be checked for validity.
No. This validator focuses on well-formedness checking — whether the document is syntactically correct XML. Schema validation (DTD, XSD, RelaxNG) requires the schema definition and is a separate concern. Well-formedness is the essential first step before schema validation.
No. All validation happens entirely in your browser using client-side JavaScript. Your XML content never leaves your machine. This is critical for documents containing sensitive data, API configurations, or proprietary business logic.
Yes. The validator fully supports XML namespaces. It checks that namespace prefixes are declared before use, verifies namespace URI syntax, and correctly handles default namespace inheritance. Namespace-related errors include specific diagnostic messages.
CDATA sections (<![CDATA[...]]>) are recognized and parsed correctly. The content within CDATA sections is treated as literal text and is not checked for XML markup rules. The validator ensures CDATA sections are properly opened and closed.
Both are fully supported. Comments (<!-- ... -->) are checked for the rule that they cannot contain -- (double hyphen) within the comment body. Processing instructions (<?target data?>) are validated for proper syntax.
This tool validates XML, not HTML. HTML5 is not XML-compliant (it allows unclosed tags, unquoted attributes, etc.). If your HTML is written as XHTML (strict XML syntax), it can be validated here. For general HTML, use a dedicated HTML validator.
The practical limit depends on your browser and device memory. Most modern devices handle XML files up to several megabytes without issues. For very large XML files (100MB+), consider using a command-line tool like xmllint.
Yes. The XML specification requires that all attributes on a single element have unique names. The validator flags duplicate attributes with the element name, attribute name, and line number.
Absolutely. The XML Validator is designed to work as a first step in XML processing workflows. Validate your XML, then convert it to JSON, CSV, or YAML. For validating other formats, see XConvert's YAML Validator and JSON Formatter.