Validate XML and locate every error

Find the broken tag in seconds

When an XML document won’t parse, the cause is usually a single misplaced character.Indentio reports the exact line and column, names the problem — a mismatched closing tag, an unescaped ampersand, a duplicate attribute — and, where it’s safe, offers a one-click fix.

The well-formedness rules, in full

XML has no “mostly correct” state. A document either satisfies every rule below and parses, or it fails one and is rejected entirely — there is no error recovery of the kind browsers apply to broken HTML. These are the constraints this validator enforces:

Namespaces, and why an undeclared prefix fails

A colon in a tag name — <xs:element>, <soap:Envelope>,<dc:creator> — marks a namespace prefix. The prefix is only a local shorthand; it must be bound to a URI by an xmlns: declaration on that element or an ancestor:

<!-- ✗ prefix "xs" was never declared -->
<xs:schema>
  <xs:element name="title"/>
</xs:schema>

<!-- ✓ -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="title"/>
</xs:schema>

This is the single most common failure when someone copies a fragment out of a WSDL, an XSD, or an Atom feed and validates it on its own: the declaration lived on the root element that was left behind. The URI itself is just an identifier and is never fetched — it does not need to resolve to anything, and typing it wrong produces no error here, only a mismatch later against a schema.

Well-formed, valid, and the three schema languages

This validator answers the first question. It is worth knowing precisely what the second one would add:

• DTD — the original, declared inline or via <!DOCTYPE>. Can express element order and nesting but has almost no concept of data types. Still ubiquitous in publishing formats.
• XSD (XML Schema) — the W3C successor, itself written in XML. Adds a full type system: integers, dates, ranges, patterns, cardinality. This is what .xsd files and most enterprise and SOAP tooling use.
• RELAX NG — a simpler alternative with a readable compact syntax, favoured in documentation formats such as DocBook.

All three assume a well-formed document to begin with. If a schema validator reports a cryptic parse failure, run the document through a well-formedness check first — a surprising share of “schema errors” turn out to be a missing tag.

A note on DOCTYPE and external entities

A DTD can define custom entities, and an entity can point at an external file or URL. Server-side XML parsers that resolve those references have been the source of a long-running class of security problems known as XXE — a document that quietly reads /etc/passwd and exfiltrates it. Indentio parses in your own browser with entity resolution off, so nothing is fetched and there is nothing to leak. If you accept XML from users in your own systems, disable external entity resolution in whichever parser you use; it is off by default in most modern libraries and dangerously on in some older ones.

Works with any XML dialect

SVG, RSS, Atom, XSD, WSDL, sitemaps, Maven pom.xml, Android layouts, .NET.config, Apple .plist, DocBook, XLIFF, and SOAP envelopes are all XML, so all of them validate here. Upload a file or paste the markup directly. Two dialect habits cause most real-world failures: unescaped ampersands in URLs inside feeds and sitemaps, and namespace prefixes separated from their declaration.

Validate, then fix

• Live well-formedness checking as you type, with the first error’s exact line and column.
• Hover any red underline for the reason and a targeted hint.
• Bare ampersands can be escaped in one click; structural errors are pinpointed rather than guessed at, because a wrong repair would silently corrupt the document.
• Use Tree view to see the nesting the parser sees — usually the fastest way to spot the element that never closed.

Go deeper