What is the difference between "well-formed" and "valid" XML?

Well-formed means the document follows XML's own baseline syntax rules — proper nesting, closed tags, escaped special characters, one root element — independent of content. Valid means the document is well-formed AND additionally conforms to a specific schema (XSD or DTD) that defines which elements, attributes, and data types are permitted. A document can be well-formed but still invalid against a given schema.

What is an XSD schema?

An XSD (XML Schema Definition) is itself an XML document that formally defines the structure of another class of XML documents — which elements and attributes are allowed, their nesting order, cardinality (how many times an element can appear), and data types. It is the modern replacement for the older, less expressive DTD format.

Why can't this tool do complete XSD validation like xmllint does?

Full XSD validation requires implementing the entire XML Schema specification — complex type inheritance, facets like minOccurs/maxOccurs and pattern restrictions, namespace-aware schema imports — which is the job of dedicated libraries such as Xerces or Saxon, not something browsers ship natively. This tool performs a fast, practical structural check (are all the element names used actually declared in the schema) that catches the majority of everyday mistakes without requiring a server-side validation engine.

What causes a document to fail the well-formedness check?

The most common causes are an unclosed or mismatched tag, an attribute value missing its quotes, more than one root element, a literal & or < character in text content that was not escaped as & or <, or an encoding declaration that does not match the file's actual byte encoding.

Do I need a DOCTYPE or an xmlns namespace declaration for the XML to be well-formed?

No. Well-formedness only requires correct XML syntax — a DOCTYPE, schema reference, or namespace declaration is not required for a document to parse successfully. Those declarations become relevant only when you are checking validity against a specific DTD, XSD, or when element names need to be disambiguated across multiple XML vocabularies.

Can this tool validate against a DTD instead of an XSD?

This tool's schema check is built specifically around XSD's element[name] declaration syntax. DTDs use an entirely different, non-XML declaration syntax ( ), so a DTD pasted into the XSD field will not be parsed correctly — convert to XSD first, or use a DTD-aware validator for documents still using that older format.

Is it safe to validate an XML document that references external DTDs or entities?

The browser's DOMParser does not fetch or resolve external DTD or entity references during this kind of parsing, which incidentally protects against XXE (XML External Entity) attacks that exploit validators configured to resolve external references. If your document declares an external DTD, its well-formedness is still checked, but the external content itself is never retrieved.

Why does my SOAP request fail even though this tool says it is well-formed?

A SOAP web service typically enforces its own WSDL-defined schema on top of basic XML well-formedness — a well-formed envelope can still fail if a required element is missing, an element appears out of order, or a value has the wrong type. Paste the relevant XSD portion of the WSDL into the schema field here to catch structural mismatches before sending the request.

What does the element count on a successful validation tell me?

It is a quick sanity check that the document has the expected overall size and completeness — useful for spotting a truncated file or a data export that stopped partway through, without manually counting tags in a large document.

All ToolsValidate XML with XSD

Validate XML with XSD

Validate XML well-formedness and check structure against an XSD schema. Browser-based.

ilovedocstools.com

Processing…

Processed on your device

What is Validate XML with XSD?

Validate XML is a free online tool that checks whether an XML document is well-formed and, when you provide a schema, performs structural validation against it. Well-formedness is checked with the browser's native DOMParser — the same engine that powers XML parsing across the web platform — and schema checking compares every element name in your document against the elements declared in an XSD you paste alongside it.

XML validity comes in two distinct, commonly confused levels. "Well-formed" means the document obeys XML's own baseline syntax rules regardless of what it is supposed to contain: exactly one root element, every opening tag has a matching closing tag (or is self-closed), tags are properly nested without overlapping, attribute values are quoted, and reserved characters like &, <, and > are escaped as entities (&, <, >) wherever they appear as literal text rather than markup. Any XML parser — a browser, a build tool, an API client — can reject a document at this level without knowing anything about what the document is meant to represent. "Valid" is a stricter, additional claim: the document is well-formed AND it conforms to a specific schema (a DTD or an XSD) that defines exactly which elements and attributes are permitted, in what order, and with what data types. A document can be perfectly well-formed and still invalid — for example, a "well-formed" invoice XML with a <total> element containing the text "banana" is syntactically fine but violates a schema that requires <total> to be numeric.

Browsers, this one included, do not ship a full XSD validation engine — that requires the kind of complete implementation found in dedicated libraries like Xerces or Saxon, supporting complex types, type inheritance, facets, and namespace-aware schema resolution. What this tool provides instead is a practical, fast, structural check: it extracts every element name declared in your pasted XSD and confirms every element actually used in your XML document appears in that declared set, catching the most common real-world mistake — a typo'd tag name, a leftover element from an old schema version, or a namespace prefix mismatch — without requiring a server-side validation library. For anything requiring full facet-level, type-strict XSD conformance (say, before submitting to a government or banking XML interchange format with a strict published schema), a dedicated command-line validator like xmllint remains the authoritative tool.

This kind of check matters most in a handful of recurring situations: verifying a SOAP request envelope is syntactically sound before it hits a web service that will reject anything malformed with an opaque fault, catching a broken closing tag in a hand-edited configuration file (Android manifests, Maven POMs, and Spring bean definitions are all XML and all suffer from this), sanity-checking an exported data feed before importing it into another system, and confirming an API response actually matches the XML shape your integration code expects before you spend time debugging a parser exception further downstream.

Everything runs locally using the browser's native XML parser — no XML or XSD content is ever uploaded anywhere, which matters when the document you are validating is an internal configuration file, a contract, or another document you would rather not send to a third-party service.

How It Works

Well-formedness is checked by handing your XML string to the browser's DOMParser with a MIME type of application/xml. If the document violates baseline XML syntax — an unclosed tag, mismatched nesting, an unescaped ampersand, more than one root element — the parser does not throw a JavaScript exception; instead it silently returns a document whose root is a <parsererror> element containing the browser's own diagnostic message, which the tool detects and surfaces directly rather than presenting a generic failure. When an XSD is also provided, the tool parses that schema (itself checked for well-formedness first) and collects every element[name] declaration into a set of permitted element names. It then walks the entire XML document tree node by node, and for every element encountered whose local name is not in that declared set, it records a specific "not declared in the XSD schema" issue naming the offending tag — giving you a targeted list of exactly which elements do not match the schema rather than a single pass/fail verdict.

How to Use

1
Paste your XML
Paste the full XML content you want to check into the XML Document field.
2
Validate well-formedness first
Click "Validate XML" with the XSD field left empty to check basic syntax — matching tags, proper nesting, quoted attributes, and escaped special characters.
3
Fix any reported errors
If the document is not well-formed, review the specific parser error message, correct the issue in your source document, and paste the corrected version back in.
4
Add an XSD schema (optional)
Paste your XSD schema into the second field if you want to check that every element used in your XML is actually declared in that schema.
5
Re-validate against the schema
Click "Validate XML" again — any element names present in your document but missing from the XSD's declarations will be listed individually.
6
Confirm the element count
On a successful validation, check the reported element count as a quick sanity check that the document is complete and nothing was truncated.

Who Uses This Tool

🔐

SOAP Web Service Testing

Validate SOAP envelope XML before sending it to a web service to catch malformed requests early.

📋

Schema Compliance Checks

Verify that XML data files conform to a supplied XSD schema before processing them in an application.

🗂️

Config File Validation

Check Maven, Spring, or Android manifest XML files for well-formedness errors after manual edits.

🧪

CI/CD Pipeline Integration

Use as a quick manual check during development before automated schema validation runs in the pipeline.

📡

API Data Validation

Verify XML responses from third-party APIs to ensure they match the expected structure before parsing.

📦

Data Migration Quality

Validate exported XML datasets before importing them into a new system to prevent silent data corruption.

Why Choose This Tool

Well-Formedness Detection

Uses the browser's native DOMParser to check XML syntax according to the W3C specification with no dependencies.

Basic XSD Validation

Optionally paste an XSD schema to check that all element names in your XML are declared in the schema.

Clear Error Messages

Parser error text is extracted and displayed directly so you know exactly which tag or character is invalid.

Element Count Summary

Displays the total element count on success, giving a quick sanity check that the document is complete.

Optional Schema Input

Validate XML alone or with a schema — both modes are available so the tool fits any workflow.

Client-Side Privacy

No XML or XSD data is ever uploaded, making it safe to validate confidential enterprise documents.

Also Try

Format XML JSON Formatter HTML Beautifier JS Beautifier Regex Tester Sitemap Generator

Key Benefits

Validates well-formedness using the browser's native DOMParser engine
Optional structural XSD check — flags element names not declared in your schema
Descriptive, browser-native error messages instead of a generic "invalid" result
Works with or without a schema — paste XML alone or XML plus XSD
Reports total element count on success as a quick document sanity check
Correctly distinguishes "well-formed" from "schema-valid" for accurate diagnosis
100% client-side — sensitive configuration files and contracts are never uploaded
No installation of xmllint, Xerces, or any other external validator required

Frequently Asked Questions

Also Known As

xml validator online freevalidate xml against xsd onlinexml well-formedness checkercheck xml syntax onlineonline xml schema validatorxsd validation online toolxml validator browser basedvalidate xml no upload