dummy4u

XML Formatter and Validator

Formats as you type, tells you where it broke, and does not quietly discard your declaration or doctype.

Well-formed is not the same as valid

This page checks well-formedness: tags balance, attributes are quoted, there is exactly one root element, and the special characters are escaped. That is the XML equivalent of syntax checking, and it is what fails in practice.

Validity is a stronger claim — that the document also matches a schema, whether a DTD, an XSD or a RELAX NG grammar. That requires the schema itself and a validating processor, neither of which a browser provides. If a system rejects your XML while this page accepts it, a schema is almost certainly the reason: a required element missing, an unexpected child, a value in the wrong format.

The five things that are usually wrong

  • An unescaped ampersand. & starts an entity reference, so a bare one in text or an attribute is an error. It must be & — the single most common cause, usually from a URL with query parameters.
  • Mismatched case. XML is case-sensitive, so <Item>…</item> does not close.
  • More than one root. Two sibling elements at the top level is not a document. Wrap them.
  • Unquoted attributes. <a href=x> is fine in HTML and illegal in XML. Single or double quotes, but always quotes.
  • A raw < in text. Same as the ampersand: escape it as &lt;, or wrap the block in CDATA.

What the formatter keeps

Most online XML formatters parse your document into a DOM and serialise it back out. That is quick to write and quietly destructive: the XML declaration disappears, the doctype and any internal subset go with it, entity references get expanded, and comments are sometimes dropped.

This one indents the original text rather than a reconstruction of it, so the declaration, the doctype, processing instructions, comments and CDATA sections all survive verbatim. The browser's own parser still decides whether the document is well formed — you get its verdict, not a second opinion from reimplemented parsing rules.

Elements whose entire content is a single run of text stay on one line, because <title>Dune</title> spread across three lines helps nobody.

A note on whitespace

Indenting XML changes it. In element content, whitespace is data as far as the specification is concerned, and a consumer using xml:space="preserve" or comparing documents byte for byte will notice. For configuration files and API payloads this never matters. For signed documents it matters enormously — an XML signature covers a canonical form, and reformatting invalidates it. Format for reading, not before signing.

Common questions

Is my XML uploaded?
No. Parsing and formatting happen in your browser and the page makes no network requests, which is the reason to use a page like this rather than pasting a production payload somewhere unknown. See the privacy policy.
Does it handle namespaces?
Yes. Prefixes and xmlns declarations are attributes like any other and pass through untouched. Note that well-formedness does not require a prefix to be declared in a way your consumer likes — only that it is syntactically valid.
Can it convert XML to JSON?
Not yet. The conversion needs a convention for attributes, repeated elements and mixed content, and a bad convention produces output that is technically JSON but useless.
Why is my SOAP or SVG file reported as an error?
Both are XML, so a genuine error is a genuine error — look at the reported line. The common surprise is HTML pasted in by mistake: unclosed <br> and <img> tags are legal HTML and invalid XML.