XML formatter, validator and minifier
Paste XML to indent it, shrink it or check it. A mistake is reported with its line, its column and the likely fix. Comments, CDATA, processing instructions and text mixed in with tags are left exactly as written. Nothing is uploaded: it all runs in this page.
Recommended. Text that sits next to tags (as in a paragraph with a bold word) is left exactly as it is, so no spaces are added or lost. Turn it off and every piece of text is trimmed and moved onto its own line, which changes the text.
Well-formed XML, formatted below.
- Size
- 400 B
- Elements
- 10
- Attributes
- 7
- Depth
- 4
- Comments
- 1
How it works
- •The page reads your XML with its own tokenizer that follows the XML 1.0 rules. It does not use the browser's XML parser, so the same code gives the same answer everywhere and the error positions are exact. Lines are split at line feeds, CRLF and lone CR, and columns count characters from the start of the line.
- •It stops at the first problem. For <a><b></a> it reports line 1, column 7: the closing </a> where </b> was expected. Mismatched and unclosed tags, a missing quote around an attribute, a repeated attribute, a second root element, a bare & or < in text, an undefined entity such as , ]]> in text and characters XML forbids are all caught.
- •Formatting only changes white space that is not content. Between child elements it adds line breaks and indentation. Text that contains anything other than white space, CDATA, comments, processing instructions, the XML declaration, the DOCTYPE and everything under xml:space="preserve" is written exactly as it was. Minify removes the same insignificant white space and nothing else.
- •Options: 2 or 4 spaces or a tab, empty elements always as <a/> or always as <a></a>, one attribute per line, removing comments, and a switch that checks namespace prefixes. Turning off “Keep mixed content as written” trims text next to tags and puts it on its own line, which does change that text.
- •Namespace mistakes such as an undeclared prefix (<p:a/>) are reported as errors, like most XML libraries do. The command-line tool xmllint lets them through. The limits are 5 MB of text and 1000 levels of nesting. Entities declared in a DOCTYPE are accepted but not expanded, external DTDs are not loaded, and nothing is validated against a DTD or a schema.
- •We compared the verdicts with xmllint and with Python's ElementTree on 208 test documents (77 meant to be well-formed, 131 not). They agreed with ElementTree on 207 and with xmllint on 198. The 10 that xmllint differs on are namespace mistakes, and the one that ElementTree differs on is version="2.0" in the XML declaration, which the XML specification does not allow.
Questions
- Is my XML uploaded?
- No. The text is processed by code running in this page and is never sent anywhere. Copy and download also happen on your device.
- Will formatting change what my XML means?
- Not with the default settings. Only white space between elements is added or removed, and text, CDATA, comments, processing instructions and anything under xml:space="preserve" stay as written. If your own program reads the white space between elements as data, formatting will change what it sees. Switching off “Keep mixed content as written” does change text that sits next to tags.
- Why does this page report an error that another tool accepts?
- Usually a namespace rule: an element or attribute uses a prefix that no xmlns:prefix declaration defines, and tools such as xmllint do not complain. Most XML libraries do. Untick “Check namespace prefixes” to see the plain XML 1.0 result. The other common cause is an HTML habit that XML forbids: a bare &, an attribute without a value, or a name like .
- Does well-formed mean valid?
- No. Well-formed means the text follows the XML syntax rules. Valid means it also matches a DTD or schema that says which elements and attributes are allowed. This page checks the first, not the second.