Skip to content
FormatKit

Free online XML well-formedness checker

XML validator that names the broken rule

This XML validator is free and needs no signup: hand it a document of up to 5 MB and it says whether the syntax holds, and if it does not, which rule was broken, on what line and in which column, with a caret under the character that stopped the parser. It checks well-formedness — one root, matched tags, quoted attributes, escaped ampersands — and deliberately not conformance to a DTD or an XSD, because a browser parser never applies one. A document that passes here also reports its root element, namespace bindings, depth and element counts.

  • 100% free
  • No signup
  • Up to 5 MB
  • Line, column and caret
  • Syntax, not schema

Well-formedness check — syntax only, no DTD or schema is applied

Paste XML, drop a file, or press Ctrl+V anywhere on this page. The verdict appears here as you type.

Need the document laid out rather than judged? format-xml.com is our dedicated tool for that.

How to check whether XML is well-formed

Three steps from a suspect document to the character that broke it.

  1. Give the checker something to read

    Paste it into the box, drop an .xml file onto it, or use Open file — a Ctrl+V lands anywhere on this page, ⌘V on a Mac. Anything up to 5 MB is read, including .xsd, .svg, .wsdl, .plist and RSS feeds. Two sample buttons sit in the toolbar — one document that passes, one that fails on three separate rules.

  2. Read the verdict as you type

    The bar underneath answers immediately. A failure names the category first — Tags do not match, Bare ampersand, Content after the root element — then the line, the column, the offending source line with a caret under the exact character, and a sentence on what the rule actually is. XML parsers stop at the first violation, so fix that one and the next appears.

  3. Check the advisories on a document that passes

    A well-formed result lists the root element, element and attribute counts, nesting depth, and every namespace prefix with the URI it is bound to. Underneath sit the things that parse and still deserve a look: a DOCTYPE that was not applied, a declared encoding this page cannot verify, a leading byte-order mark, or a name that starts with the reserved letters xml.

Technical specifications

What is checkedWell-formedness per XML 1.0 fifth edition: single root, matched and nested tags, quoted attribute values, legal names and characters, correct entity and character references, comment and CDATA rules
What is not checkedAnything a DTD, XML Schema, RELAX NG or Schematron would say. No external DTD is fetched and no content model is applied, even when the document carries a DOCTYPE
ParserThe browser's own DOMParser in application/xml mode — the same engine that would load the document in your page, so a pass here is a pass there
Error reportCategory, line, column, the source line with a caret beneath the failing character, and the rule in one sentence. One error at a time, because XML parsing stops at the first fatal error
Categories named15, among them mismatched tags, bare ampersand, undefined entity, content after the root, undeclared namespace prefix, duplicate attribute, unquoted attribute value and misplaced XML declaration
Reported on a clean documentRoot element name, element and attribute counts, nesting depth, text characters, comments, CDATA sections, processing instructions and every namespace binding
Maximum document size5 MB (5,242,880 bytes). A 5 MB feed of about 60,000 elements is checked in roughly 0.4 seconds
Cost and processingFree, no account, no daily cap; the document is parsed inside this browser tab and never uploaded

Frequently asked questions

Is well-formed the same as valid XML?

No, and the XML 1.0 specification defines them as two separate things. Well-formed means the syntax holds together: one root element, every tag closed and correctly nested, attribute values quoted, no bare ampersands or angle brackets in text. Valid is a stronger claim — that the document also obeys a grammar declared for it in a DTD or an XML Schema, so that <invoice> really does contain a <total>, in that position, with the attributes the schema requires. This page answers the first question only. A document can be flawlessly well-formed and completely wrong for its schema.

What checks XML against an XSD or a DTD, if this does not?

A validating parser with the schema in hand: xmllint --schema contract.xsd document.xml on the command line, Xerces in Java, lxml.etree.XMLSchema in Python, or System.Xml.Schema in .NET. Browsers deliberately skip it — DOMParser never fetches an external DTD and ignores the content model entirely, which is why a document with a DOCTYPE line still only gets a syntax check here. Once the syntax is clean, schema validation is the next step rather than a competing one.

Why does my XML break on an ampersand or on &nbsp;?

Because & starts an entity reference and XML predefines only five entities: &amp; &lt; &gt; &quot; and &apos;. A bare & makes the parser hunt for the semicolon that should end the reference, which produces the EntityRef message; &nbsp;, &copy;, &mdash; and the rest of the HTML character set simply do not exist in XML unless a DTD declares them, so markup copied out of a web page fails on the first one. Write &amp; for a literal ampersand and use numeric references — &#160; for a non-breaking space — for everything else.

Why does the reported line number point at the wrong place?

Because an unclosed element is discovered at the end of the file but reported where it opened. When the parser reaches the last byte with <item> still on its stack it has no way to know which of the following lines was supposed to close it, so it points at the start tag — the line you are looking at is fine, and the missing </item> belongs somewhere below. The same asymmetry explains a mismatched-tag error landing on the closing tag rather than on the opening one it fails to match.

Why does the error message differ between Chrome and Firefox?

Because each engine writes its own report and there is no standard for the text. Blink and WebKit use libxml2 wording and wrap it in an XHTML error page — “error on line 4 at column 12: Opening and ending tag mismatch” — while Gecko replaces the document with a parsererror element in its own namespace and writes “XML Parsing Error: mismatched tag. Line Number 4, Column 12”. This page reads all three shapes, pulls the line and column out of whichever it got, and prints the same category name regardless of the browser you are using.

Can an XML document have two root elements?

No — exactly one element contains everything else, and that rule has no exceptions. Two records side by side at the top level produce “Extra content at the end of the document”, which is the second most common failure after unescaped ampersands, usually created by concatenating two files or by pasting a fragment out of a larger one. Wrap the pair in a container element and both become children of a legal root. Comments, whitespace and processing instructions may sit outside the root; nothing else may.

Does capitalisation matter, and what about whitespace inside tags?

Case matters everywhere: XML is case-sensitive, so </Total> does not close <total> and the attribute Id is not the attribute id. Whitespace inside a start tag is free — you may break a long tag across lines between attributes — but not between the < and the element name, and not inside the closing </ pair. Attribute values must be quoted with either single or double quotes, which is the rule HTML relaxed and XML never did.

About well-formedness, and why XML is so unforgiving

XML 1.0 draws a line most other formats blur. A document is well-formed when it satisfies the syntactic constraints in section 2 of the specification — one root element, tags that close in the order they opened, attribute values in quotes, the characters & and < escaped in text — and it is valid only when it also matches a grammar declared for it. The two are independent claims about the same file, and the loose sentence “the XML is invalid” almost always means the first one failed. This page answers the first question, deliberately and completely; the second needs your schema, which the browser will not fetch.

The severity is by design. The specification calls a well-formedness breach a fatal error and says a conforming processor must report it and must not continue normal processing — no recovery, no best guess. That is the opposite of the HTML parser sitting a few lines away in the same browser, which will happily invent the tags you forgot. It is also why the error you get is a single error: the parser stops, so a file with four problems shows them one at a time, and the count only appears as you fix them. The five predefined entities are the other rule that catches people out — XML defines &amp;, &lt;, &gt;, &quot; and &apos; and nothing else, so every HTML entity from &nbsp; onwards is undefined until a DTD says otherwise.

Reading the browser’s verdict is harder than asking for it. Each engine reports a failure differently: Gecko throws the whole document away and returns a parsererror element in its own namespace with a sourcetext child, while Blink and WebKit hand back an XHTML page with the libxml2 message inside it — and neither shape is standardised, so code that checks for one silently reports success on the other. This page checks for all of them and normalises the position out of whichever wording it receives. Once the syntax is clean, the document is ready to be explored as a tree or converted to JSON. If what you actually need is the document laid out neatly rather than judged, format-xml.com is the dedicated tool we keep for that job.

Where the document is parsed

The parser is the one already inside your browser, so the document is read in this tab and nothing about it is transmitted, stored or logged. That is why a SOAP envelope or a signed invoice can reasonably go in here: the bytes never leave the machine, and nothing about them survives a reload.