XML Beautifier / Minifier — Free Online Tool

What is XML Formatter, Minifier & Validator (XML to JSON, CSV, YAML)?

XML tooling means four distinct jobs on the same markup: re-indenting it so a human can read the nesting, stripping the whitespace back out for transport, checking it is well-formed against the XML 1.0 grammar, and reshaping the tree into a friendlier format. This tool does all four on the text in front of you, with the validation and conversion steps driven by the browser's own XML parser rather than a regular expression.

• Beautify with seven indent presets: The pretty-printer tokenises the markup into tags and text runs, tracks depth, and re-emits one node per line. Indent choices are 1, 2, 3, 4 or 8 spaces, one tab, or two tabs. A short text-only element such as <name>Alice</name> is deliberately kept on one line instead of being exploded into three.
• Minify that also drops comments: Minify removes <!-- … --> comments outright, collapses whitespace between tags, and squeezes runs of spaces. That makes it lossy for mixed content: if an element's text depends on internal spacing, minified output is not equivalent to the input.
• Validation through DOMParser: Validate runs the string through DOMParser with the application/xml MIME type and looks for a <parsererror> element in the resulting document. On success you get "Valid, well-formed XML"; on failure the browser's own message is normalised, whitespace-collapsed and truncated to 240 characters — so you see the real line and column, not a generic "invalid".
• Four conversion targets: The Convert to dropdown offers JSON, CSV, YAML and HTML Table (plus XML, which is the no-op default). JSON and YAML walk the whole tree; CSV and HTML Table expect the root's children to be a list of similar records, and raise "No child elements found for CSV conversion" when the root has none.
• Attributes get an @ prefix: In JSON and YAML output every attribute becomes a key prefixed with @, and an element's own text content becomes #text when it has siblings. Repeated sibling tags collapse into an array. This is the same convention used by most XML-to-JSON mappings, and it is what makes the transform round-trippable by hand.

Why use XML Tools?

XML that arrives over the wire is usually one long line with no whitespace, and the first error a strict parser reports is often the last thing you would have guessed. Formatting and validating separately turns "it doesn't work" into a line number.

• Nesting becomes visible: A SOAP envelope, an Atom feed, an Android layout or a Maven POM is unreadable minified. Indenting it exposes the depth, which is how you spot the element that closed one level too early or the namespace declared on the wrong node.
• Real parser messages, not guesses: Because validation uses the browser's XML parser, you get errors like "error on line 4 at column 22: Opening and ending tag mismatch" or "EntityRef: expecting ';'" — the same diagnostics your server-side parser will produce, so a fix here fixes it there.
• Reshape without writing a script: Converting a feed or an export to JSON, YAML or CSV is normally a throwaway script with an XML library. For a one-off inspection, a dropdown and a button is the whole job — and the HTML Table target gives you something you can paste into a document.
• Smaller payloads on purpose: Minify shows you exactly how much of an XML document is indentation and comments. On a verbose config or a SOAP body that is frequently a third of the bytes, which is worth knowing before you decide whether gzip alone is enough.
• Nothing leaves the tab: Parsing, formatting and conversion all run client-side. XML is the format of choice for SAML assertions, bank statements, invoices and health records — content that generally may not be pasted into a hosted formatter.

When to use XML Tools

Reach for it when XML is either unreadable, rejected, or in the wrong shape for what you are building.

• Debugging a SOAP request or response that a gateway rejected, where the fault text does not say which element is wrong.
• Reading a minified RSS or Atom feed, a sitemap.xml, or an SVG file that was exported without whitespace.
• Checking a hand-edited pom.xml, web.xml, AndroidManifest.xml or .csproj is well-formed before a build spends five minutes discovering it is not.
• Turning an XML export from a legacy system into JSON for a modern API, or into CSV so it opens in a spreadsheet.
• Inspecting a SAML assertion or a signed XML document for structure — remembering that reformatting a signed document invalidates its signature.
• Comparing two XML documents: beautify both with the same indent setting first, then paste them into the Diff Checker so the diff is about content, not layout.
• Shrinking XML for a size-constrained transport, or measuring how much of the payload is whitespace and comments.

How to use XML Tools

Paste or upload the markup, then choose one of the four actions. Each reports its own status message below the toolbar.

1. Load the XML: Paste into the XML box, or press Upload .xml. The picker only accepts an .xml extension, and the file contents are sniffed for a tag-like pattern first — you get "File doesn't appear to contain valid XML" rather than a silent load of the wrong file.
2. Validate before anything else: Press Validate. "Valid, well-formed XML" means DOMParser accepted it. Otherwise you get the browser's own error text, which names the line and column — fix that first, because Convert will fail on the same input.
3. Choose an indent and Beautify: Pick 1, 2, 3, 4 or 8 spaces, 1 tab or 2 tabs from the Indent dropdown, then press Beautify. The output pane has line numbers so the reported error line lines up with what you are reading.
4. Or Minify for transport: Minify strips comments and inter-tag whitespace. Use it on machine-to-machine payloads; avoid it on documents whose text content is whitespace-sensitive.
5. Convert to another format: Set Convert to: JSON, CSV, YAML or HTML Table, then press Convert. Leaving it on "XML (default)" reports "Already XML" instead of doing nothing silently. For CSV and HTML Table, the root element's children must be the repeating records.
6. Copy the result: Copy takes the output pane's contents to the clipboard; Clear empties both panes. Both actions are in the toolbar next to the four operations.

Key features

• Seven indent presets: 1, 2, 3, 4 and 8 spaces plus 1 tab and 2 tabs, so output can match whatever your repository's .editorconfig demands.
• Browser-native well-formedness check: Validation goes through DOMParser with application/xml and surfaces the <parsererror> text verbatim, giving real line and column numbers.
• Four conversion targets: JSON (2-space), YAML, CSV and HTML Table. Attributes become @name keys, element text becomes #text, and repeated siblings become arrays.
• Header union for tabular output: CSV and HTML Table collect the union of every record's child tags and attributes as columns, so records with missing fields still line up — the gap is emitted as an empty cell.
• RFC 4180-style CSV quoting: Values containing a comma, a double quote or a newline are wrapped in quotes with inner quotes doubled, so the output survives a spreadsheet import.
• Syntax-highlighted panes with gutters: Input is highlighted as XML and output as markup, both with line numbers — which is how you find "line 47" from an error message quickly.

Common use cases

• SOAP and web-service debugging: Format the envelope, validate it, and locate the mismatched tag or unescaped ampersand that produced the fault.
• Feed and sitemap inspection: Read a minified RSS, Atom or sitemap.xml file, then convert the item list to CSV to audit URLs and dates in bulk.
• Legacy data migration: Convert an XML export to JSON for a REST API, or to CSV for a spreadsheet review before the import runs.
• Build-file sanity checks: Validate a hand-edited pom.xml, .csproj or AndroidManifest.xml before committing, instead of learning about it from CI.
• Documentation and reporting: Turn a record list into an HTML Table you can paste into a wiki page, a ticket, or an email.
• Payload size work: Minify to measure how much of a config or SOAP body is indentation and comments before optimising transport.

Examples

Real input and output for each operation. The Indent dropdown was left at 2 spaces.

<?xml version="1.0" encoding="UTF-8"?><catalog><book id="bk101"><author>Gambardella, Matthew</author><price>44.95</price></book></catalog>

<?xml version="1.0" encoding="UTF-8"?>
<catalog> <book id="bk101"> <author>Gambardella, Matthew</author> <price>44.95</price> </book>
</catalog>

<root> <a>1</a> <!-- note --> <b>2</b>
</root>

<root><a>1</a><b>2</b></root>

<items> <item id="1"><name>Alice</name></item> <item id="2"><name>Bob</name></item>
</items>

{ "items": { "item": [ { "@id": "1", "name": "Alice" }, { "@id": "2", "name": "Bob" } ] }
}

<items> <item id="1"><name>Alice</name><city>Berlin, DE</city></item> <item id="2"><name>Bob</name></item>
</items>

name,city,@id
Alice,"Berlin, DE",1
Bob,,2

<order><note>Tom & Jerry</note></order>

error on line 1 at column 24: EntityRef: expecting ';'

Technical reference

The rules and limits behind each operation:

Specification

XML 1.0 Fifth Edition (W3C REC-xml-20081126); namespaces per Namespaces in XML 1.0 Third Edition

Predefined entities

Only five: &amp; &lt; &gt; &apos; &quot;. HTML names such as &nbsp; are undefined in XML and cause a parse error unless declared in a DTD

Element name rules

Must start with a letter or underscore, may contain letters, digits, hyphen, period and underscore; names beginning "xml" in any case are reserved

Case sensitivity

Fully case-sensitive — <Item> and <item> are different elements, unlike HTML

Validation engine

DOMParser().parseFromString(src, "application/xml"); failure is detected by a <parsererror> node, message truncated to 240 characters

Scope of validation

Well-formedness only. There is no DTD, XSD or RELAX NG schema validation, so a document can be well-formed yet schema-invalid

Indent options

1, 2, 3, 4, 8 spaces; 1 tab; 2 tabs

Upload constraint

The file picker accepts .xml only, and the contents must match a tag-like pattern before they are loaded

Common mistakes to avoid

Leaving bare ampersands or angle brackets in text content

Why it happens: XML defines exactly five predefined entities — &amp; &lt; &gt; &apos; &quot; — and an unescaped & starts an entity reference. Text like "Tom & Jerry" or a query string with "a=1&b=2" therefore fails with "EntityRef: expecting ';'", and a literal < in text produces a tag-mismatch error instead. This is the single most common reason hand-assembled XML is rejected.

How to avoid it: Escape & as &amp; and < as &lt; in all text and attribute values, and let a real serialiser do it rather than building XML by string concatenation. If the content is genuinely markup or contains many special characters, wrap it in a CDATA section — <![CDATA[…]]> — which suspends entity recognition, but remember CDATA cannot contain the sequence ]]>.

Expecting HTML entity names to work in XML

Why it happens: &nbsp;, &copy;, &mdash; and the rest of the HTML named entity set are declared by the HTML DTD, not by XML. In an XML document with no DTD they are undeclared entity references, and DOMParser reports "Entity 'nbsp' not defined". The document looks fine in a browser tab if the browser sniffs it as HTML, which is why the failure often only appears in a strict server-side parser.

How to avoid it: Use numeric character references instead: &#160; or &#xA0; for a non-breaking space, &#169; for ©. Better still, emit the actual UTF-8 character and declare encoding="UTF-8" in the XML declaration — XML is Unicode-native, so there is no reason to escape ordinary text at all. Reserve named entities for the five XML predefines.

Assuming "well-formed" means "valid"

Why it happens: Validate checks well-formedness only: tags balanced and correctly nested, one root element, attributes quoted, names legal. It does not check your document against a DTD, XSD or RELAX NG schema. A perfectly well-formed document can still have elements in the wrong order, a required attribute missing, or a date where a schema demands xs:dateTime — and this tool will happily call it valid.

How to avoid it: Treat a pass here as the first gate, not the last. Well-formedness is a prerequisite for every schema validator, so clearing it first removes the noisiest class of error. For contract checking, run the document against the actual schema with xmllint --schema, a language-native validator, or your framework's built-in check before you ship.

Reformatting XML whose whitespace or signature matters

Why it happens: Beautify and minify both rewrite inter-node whitespace. For elements with mixed content — text and child elements interleaved, as in DocBook or XHTML — that whitespace is part of the data, and reindenting changes the rendered text. Worse, an XML Signature covers a canonicalised byte sequence: reformatting a signed SAML assertion or signed invoice changes the digest and the signature stops verifying, with no error from this tool.

How to avoid it: Only reformat documents whose whitespace is insignificant — configs, feeds, data exports. For signed documents, format a copy for reading and keep the original bytes for transmission. If you need a canonical form for comparison or signing, use a real Canonical XML (C14N) implementation rather than a pretty-printer, and diff the canonical outputs.

Converting arbitrary XML to CSV or an HTML Table

Why it happens: Both tabular targets assume a shape: a root element whose direct children are similar records, each holding flat leaf elements and attributes. Given a deeply nested document they raise "No child elements found for CSV conversion" when the root has no element children, and silently lose data when records contain grandchildren, because each column is read from the first matching descendant element only. Repeated tags inside a single record collapse to one value.

How to avoid it: Flatten first. Convert to JSON to see the real shape, reshape it there, and use the JSON to CSV tool if the records are nested. Or extract just the repeating list into its own <items> wrapper before converting. Whenever a CSV comes back with fewer columns than you expected, compare it against the JSON output — that difference is the data the flattening dropped.

Frequently asked questions

How do I format XML online without uploading the file?

Paste the markup into the XML box, or use Upload .xml — the file is read locally through the File API and its contents stay in the tab. Pick an indent from the dropdown and press Beautify. Parsing, formatting, validation and every conversion run in your browser's JavaScript engine, so nothing is transmitted. That matters for the documents XML is typically used for: SAML assertions, invoices, bank statements and health records that you are not permitted to paste into a hosted service.

What is the difference between well-formed and valid XML?

Well-formed means the document obeys the XML 1.0 grammar: exactly one root element, every tag closed and properly nested, attribute values quoted, legal element names, and reserved characters escaped. Valid means it additionally conforms to a schema — a DTD, XML Schema (XSD) or RELAX NG grammar — which constrains which elements may appear where, in what order, and with what data types. This tool checks well-formedness only. Every schema validator requires well-formedness first, so a pass here is a necessary but not sufficient step.

Why does my XML fail with "EntityRef: expecting ';'"?

There is a bare ampersand somewhere in your text or attribute values. In XML an & always begins an entity reference, so the parser reads the following characters as an entity name and gives up when it does not find a semicolon. Query strings, company names like "Smith & Sons" and URLs with multiple parameters are the usual sources. Replace each literal & with &amp;, or wrap the whole value in a CDATA section. The reported column points just past the offending ampersand.

How does XML convert to JSON, and why do arrays appear inconsistently?

The converter walks the DOM and maps each element to an object: attributes become keys prefixed with @, an element's own text becomes #text when it has siblings, and an element with only text collapses to that string. Repeated sibling tags become an array. That last rule is the source of the inconsistency — a list with two <item> elements produces an array, but the same document with one <item> produces a plain object, because nothing in XML marks an element as repeatable. Consumers should normalise single values into arrays, or drive the mapping from a schema.

Does minifying XML change its meaning?

It can. Minify removes comments and collapses whitespace between and inside tags, which is safe for documents where whitespace is insignificant — most configs, feeds and data exports. It is not safe for mixed content, where text and elements interleave and spacing is part of the text, nor for anything covered by an XML Signature, since the digest is computed over canonicalised bytes and any reformatting breaks it. Removing comments is also permanent, so minify a copy if the comments document anything you need.

Can this tool validate XML against an XSD or DTD schema?

No. Validation here is a well-formedness check performed by the browser's DOMParser, which reports structural errors such as tag mismatches, illegal names, undeclared entities and multiple root elements. Browsers do not expose an XSD or RELAX NG validator to JavaScript, and a DTD referenced by a DOCTYPE is not fetched. For schema conformance use xmllint --schema schema.xsd file.xml, a language-native validator such as Java's javax.xml.validation or Python's lxml, or your XML editor's built-in support.

Why won't my XML convert to CSV?

The CSV and HTML Table targets expect the root element's direct children to be a list of similar records — the <items><item>…</item><item>…</item></items> shape. If the root has no element children you get "No child elements found for CSV conversion". If records contain nested grandchildren, each column is read from the first matching descendant, so deeper data is silently dropped and repeated tags inside one record collapse to a single value. Convert to JSON first to see the real structure, then flatten it or use the JSON to CSV tool.

References

• W3C — Extensible Markup Language (XML) 1.0 (Fifth Edition)
• W3C — Namespaces in XML 1.0 (Third Edition)
• MDN — DOMParser.parseFromString()
• W3C — Canonical XML Version 1.1
• RFC 4180 — Common Format and MIME Type for CSV Files