Vocabulary and element order
<invoice><banana/></invoice> can be well formed even when the invoice vocabulary never permits a banana element. Only the contract for that vocabulary can answer the question.
Check one document locally
Check XML 1.0 well-formedness without DTD processing
The checker parses a document without a DOCTYPE in a disposable browser worker. Load the valid sample or the intentional mismatched-tag sample to see a local line-and-column diagnostic before pasting your own document. A passing result confirms its supported XML 1.0 syntax baseline only; it is not evidence that a schema, signature, or business rule accepted the document.
Loading the private XML 1.0 syntax checker…
Enable JavaScript to check a document without a DOCTYPE locally. The error guide and validation boundaries below remain readable.
Start with syntax evidence
How to run an XML well-formedness check
Fix the first reliable syntax error before investigating a schema or application failure. Later diagnostics can be consequences of an earlier broken boundary.
- 1
Paste the complete XML text
Include the document element and any XML declaration you need to inspect. A DOCTYPE stops this checker; use a controlled DTD-aware validator when document-type grammar is required. Prefer a small synthetic reproduction over confidential production data.
- 2
Run the local syntax check
For XML 1.0 without a DOCTYPE, the worker checks well-formedness under input, depth, node-count, time, and output limits. It does not make network requests or expand an external entity.
- 3
Use the right next validator
After syntax passes, apply the authoritative XSD, DTD, Relax NG, Schematron, signature profile, or application validator in a controlled environment if the workflow requires it.
The universal XML baseline
What this XML validator checks
A well-formed XML document follows XML's core syntax constraints. It has exactly one document element. Start-tags and end-tags match with proper nesting. Attribute values are quoted, reserved characters are escaped where required, and character data occurs in legal positions. Names and namespace declarations also have lexical and scoping requirements. This checker covers that XML 1.0 baseline only when no DOCTYPE is present; a DOCTYPE stops the check.
For example, <order><id>42</order></id> is not well formed because the elements cross rather than nest. <order status=open> is not well formed because the attribute value lacks quotes. A raw ampersand in text begins what looks like an entity reference; write & when the data is an ampersand character.
The checker reports a bounded message and a line and column when the underlying parser provides useful location data. Treat that location as the point where parsing could no longer continue, not always the exact character where the author first made a mistake. Inspect the token immediately before the location and its matching opener.
- Root
- Exactly one document element encloses the document content.
- Nesting
- Every non-empty start-tag closes in last-opened, first-closed order.
- Quotes
- Every attribute value uses matching single or double quotes.
- Escapes
- Reserved markup characters are represented legally in text and attributes.
Read the first failure in context
Common XML validation errors and what to inspect
Error wording differs among parsers. The structural cause is more useful than memorizing one engine's message.
SymptomLikely XML issueFocused repair
Mismatched closing tagAn element closed under the wrong parent or uses different case.Follow the open-element stack backward; XML names are case-sensitive.
Unbound prefixA qualified name uses a prefix with no in-scope namespace declaration.Declare the prefix on that element or an ancestor and confirm the intended URI.
Invalid attribute syntaxA quote is missing, an attribute repeats, or markup appears inside a value.Quote the complete value, escape reserved characters, and keep attribute names unique per element.
Content after rootA second top-level element or non-permitted text follows the document element.Wrap related elements in one root or split independent documents.
Unsupported entityThe source declares a custom entity or uses an undefined named reference.Do not delete meaningful declarations to get a green result; use the approved DTD-aware workflow instead.
A passing parse is the beginning
What XML well-formedness does not validate
Data types and cardinality
Well-formedness does not know whether an amount is decimal, a date uses the correct timezone, an identifier matches a pattern, or an element must occur exactly once. Schema or application logic defines those constraints.
Signatures and trust
Parsing does not verify an XML signature, certificate chain, digest, canonicalization transform, sender identity, or authorization. Use the security library and trust policy approved for the protocol.
Business meaning
A structurally allowed payment can still have the wrong account, currency, total, state transition, or permission. Domain validation and transactional checks remain necessary after syntax and schema validation.
A deliberately narrow parser surface
Local XML validation without external resource loading
Historical XML parser vulnerabilities often involve DTD processing, general or parameter entities, external system identifiers, or resource expansion. This checker never fetches external resources or validates a DTD. A DOCTYPE stops the XML 1.0 well-formedness check because DTD grammar is unsupported. Custom <!ENTITY> declarations and undefined named references are also rejected. This checker is not suitable for workflows whose semantics depend on declared entities.
The browser page caps input at 200,000 UTF-16 code units, warns at 100,000, limits structural depth and node counts in the core, and stops an operation after two seconds once the worker is ready. An astral Unicode symbol uses two units. These are availability boundaries for the page, not a certification that arbitrary XML is harmless. A downstream service can use different parser features and face different risks.
The source and result stay in the tab unless you copy them. The site does not place XML in a query string or local storage. Browser extensions, assistive software, clipboard history, screen capture, and device-level monitoring are outside that promise. Prefer synthetic examples and remove credentials, secrets, personal records, and production identifiers.
Need a readable view?
Open the XML Viewer →
Once syntax passes, format the document for a source diff or build a text-only tree to search element names, attribute values, and text.
Open the XML Formatter →Open the XML Viewer →
Scope made explicit
XML validator FAQ
What does this XML validator check?
For an XML 1.0 document without a DOCTYPE, it checks well-formed syntax: one document element, properly nested and matching tags, quoted attributes, legal markup boundaries, and namespace constraints. It also returns bounded structural statistics after a successful parse. A DOCTYPE stops the check because DTD grammar is unsupported.
Does a well-formed result mean the XML is valid for my application?
No. Well-formedness is the syntax baseline. The result does not evaluate DTD, XSD, Relax NG, Schematron, signatures, vocabulary rules, referenced identifiers, or business constraints.
Are external XML resources loaded during validation?
No. A DOCTYPE stops this XML 1.0 well-formedness check because DTD grammar is unsupported; no DTD or external resource is fetched or validated. Custom <!ENTITY> declarations and undefined named references are also rejected, so DTD-dependent document semantics cannot be evaluated here.
Why can an error location appear after the real mistake?
A parser can continue until it reaches a token that cannot be reconciled with the open structure. A missing quote or closing tag earlier in the document may therefore be reported at a later line. Inspect the preceding token and matching opener.
Does the checker repair invalid XML?
No. Automatic recovery can hide which structure the author intended. The tool reports a failure and leaves the source untouched so you can make a deliberate change and run the check again.
Can I validate a fragment containing several root elements?
Not as one XML document. A document has one document element. Wrap the fragment in a synthetic root for diagnostic work only when that wrapper accurately represents the intended processing context.