Well formed, and what this page does not check
There are two separate questions you can ask about an XML document. The first is whether the markup itself holds together: every tag closed, closed in the right order, one root element, attribute values quoted, no raw < in text. That is well-formedness, and it is what this page checks. The second is whether the document says the right things — the elements a schema requires, in the order it requires, with values of the right type. That is validity, and it needs the DTD or XSD that describes your format. Nothing here loads one.
The distinction matters when someone reports "the XML is invalid". Almost always they mean well-formedness, because that is the failure that comes back as a parse error rather than a business rule complaint. Run it through here first. If it comes back clean and the receiving system still rejects it, the problem is at the schema layer and no amount of reindenting will help.
The error you get, and the error you have
The scanner stops at the first thing it cannot account for and reports the line and column of that spot. As with any parser, the reported position is where continuing became impossible, not always where the mistake was made. A tag left open near the top of the file is only detectable at the end of the file, so the report names the opening line explicitly rather than pointing at the last character. A missing quote on an attribute value swallows everything up to the next quote in the document, which can be several elements later.
Five failures cover most of what you will hit:
| What is in the file | Why it fails |
|---|---|
<p>Tom & Jerry</p> | A bare ampersand starts an entity reference. Write & |
<input type=text> | Unquoted attribute value. HTML tolerates it, XML does not |
<br> | Void HTML elements have no XML equivalent. Write <br/> |
<b><i>x</b></i> | Overlapping tags. Close in reverse order of opening |
<a/><b/> at top level | Two root elements. A document gets exactly one |
What indenting does to your data
Reindenting is not a free operation. Adding a newline and some spaces between a tag and its text content changes that text content, because in XML whitespace inside an element is part of the character data unless a schema or an xml:space declaration says otherwise. For a configuration file or a feed nobody notices. For a document format where a run of text is broken up by inline markup — the XML equivalent of a paragraph with bold words in it — reformatting can insert spaces that were never there or drop ones that were.
The behaviour here is deliberate and worth knowing: text nodes that are entirely whitespace are dropped, text nodes with content are trimmed at both ends and placed on their own line, and with the inline option on, an element holding one short line of text is printed on a single line. Comments, CDATA sections and processing instructions pass through byte for byte. If your document carries significant whitespace, use the check-only mode and leave the bytes alone.
CDATA, comments and the things that look like markup
A CDATA section exists so you can drop a block of text containing angle brackets and ampersands into a document without escaping every one. Everything between <![CDATA[ and ]]> is character data. The one sequence you cannot put inside is ]]> itself, which is why embedded scripts and SQL occasionally break in surprising ways. Comments have a similar quirk: a double hyphen is not allowed inside one, so a comment containing a long ASCII rule made of dashes will fail in strict parsers.
Both are handled here as opaque blocks, which is the only sane approach — the contents are not markup and are not scanned for tags. That also means a stray </order> sitting inside a CDATA block will not close your order element, which is exactly right, and occasionally exactly the thing someone forgot when hand-editing.
Namespaces are names, not magic
A prefix like soap:Envelope is, to a well-formedness scanner, just an element name that happens to contain a colon. The binding between the prefix and a URI comes from an xmlns attribute, and a document that uses a prefix it never declares is still well formed in the sense checked here — it will be rejected later, by anything that resolves namespaces. If a message is being refused by a service and the markup checks out clean, the missing or misspelled xmlns attribute is a good next place to look.
Nothing leaves the tab
The scan, the reindent and the minify all happen in JavaScript in the page you have open, with no request made and nothing written anywhere. That is not incidental: the XML people most often need to reformat is a request or response captured off a live integration, complete with account numbers, tokens and customer names. It is safe to paste, but it is still on your screen, so mind who can see it. When you are done, related pages: the JSON formatter for the other half of most integrations, the HTTP header explainer for the envelope around it, and the SQL formatter for what happens once the data lands.
Questions people ask
It says my document is well formed but the service still rejects it.
Well-formedness and validity are different checks. This page confirms the markup nests and quotes correctly; it does not load your DTD or XSD, so it cannot tell you that an element is in the wrong order, that a required attribute is missing, or that a date is in a format the schema forbids. Those failures only appear when a validating parser has the schema in hand. If the markup is clean, the next things to check are namespace declarations and the schema itself.
Can I paste HTML into it?
You can, but most real HTML will fail, and that is correct rather than a limitation. HTML allows unquoted attribute values, unclosed elements such as li and p, void elements written without a slash, and named entities that XML does not define. XHTML, or HTML that was written to be XML-compatible, will pass. If you need to reformat ordinary HTML, use a tool built for HTML parsing rules.
Why did my indented output lose the blank lines between elements?
Blank lines between tags are whitespace-only text nodes, and reindenting replaces all of them with the layout it generates. It is a re-render, not a patch. If the original spacing matters to you — because a schema declares xml:space preserve, or because you are diffing against a file you cannot reformat — use the check-only mode, which reports the structure and leaves your text untouched.
Does it handle very large files?
The scanner is a single pass with no backtracking, so it stays linear in the size of the input, but the whole document is held in memory and the result is painted into a text area. A few megabytes is comfortable; past that the tab will hesitate, mostly on the rendering rather than the parse. For files in the tens of megabytes, a streaming parser run from a terminal is the right tool.
Is the encoding declaration checked?
No. The declaration at the top is treated as a processing instruction and carried through unchanged. By the time text reaches this page it is already a JavaScript string, so the bytes and whatever encoding they were in are long gone. If you have a mojibake problem — accented characters showing as pairs of odd symbols — that is a byte-level issue in how the file was read or written, and it needs solving before the document gets pasted anywhere.