XML Formatter

Paste XML into the input, drop a file, or type directly. The tool parses the markup into a node tree and re-serializes it, which is what produces clean output rather than a naive find-and-replace on angle brackets. Core actions:

• Beautify / indent — re-emit the document with one level of indentation per nesting depth. You can usually pick 2 spaces, 4 spaces, or tabs.
• Minify — strip insignificant whitespace between elements to shrink the payload for transport or storage.
• Validate (well-formedness) — verify the document follows XML syntax rules: matched tags, correct nesting, a single root element, properly quoted attributes, and legal entity references.
• Error reporting — when parsing fails, surface the location and reason (for example, a mismatched closing tag or an unescaped &) so you can jump straight to it.

Because it works on the parsed tree, the formatter preserves attribute values, CDATA sections, comments, and the XML declaration rather than mangling them.

Say an API returns this on one line:

<order id="42"><item sku="A1">Pen</item><item sku="B2">Notebook</item></order>

Beautifying it with 2-space indentation gives you something you can actually read:

<order id="42">
  <item sku="A1">Pen</item>
  <item sku="B2">Notebook</item>
</order>

Now drop a closing tag:

<order id="42">
  <item sku="A1">Pen
  <item sku="B2">Notebook</item>
</order>

Validation flags it: the parser expected </item> but found <item>, so the first item is never closed. The fix is to add the missing </item>. This is the most common class of XML bug, and seeing the document indented makes the unbalanced nesting obvious at a glance.

• Reading API responses — REST and especially SOAP services often return compact, single-line XML. Formatting it makes the structure legible while you debug.
• Editing config files — pom.xml, Android AndroidManifest.xml, .csproj, web config, and similar files are easier to review and diff when consistently indented.
• Cleaning up generated output — exporters and serializers frequently emit XML with no whitespace at all. Beautify before committing so the file is reviewable.
• Preparing payloads — minify a hand-formatted request body before sending it, or shrink stored XML to save space.
• Quick sanity checks — paste a fragment to confirm it is well-formed before pasting it into a larger document or test fixture.
• Learning and teaching — the indented view makes the parent/child relationship between elements explicit, which helps when you are getting familiar with a new schema.

A few things that trip people up:

• Well-formed is not the same as valid against a schema. This tool checks XML syntax (well-formedness). It does not check your document against a DTD or XSD, so it will not tell you that an element is in the wrong place per a schema, only that the markup itself is structurally legal.
• Reserved characters must be escaped in text. A raw & is an error; write &. The same goes for < and > inside element content, which become < and >.
• Use CDATA for embedded markup or code. If an element needs to contain literal < or & (for example, an HTML snippet), wrap it in <![CDATA[ ... ]]> so the parser treats it as raw text.
• There must be exactly one root element. Two top-level siblings will fail validation. Wrap them in a single parent if you need both.
• Comments and the XML declaration are preserved, so formatting a real file won't strip your <?xml ... ?> line or your <!-- notes -->.

XML has two distinct correctness levels, and it helps to know which one you are getting.

Well-formedness is the baseline every XML document must meet. The rules are purely structural: one root element, every start tag has a matching end tag (or is self-closing like <br/>), elements nest without overlapping, attribute values are quoted, attribute names are unique within an element, and special characters are escaped. A document that breaks any of these cannot be parsed at all. That is what this tool verifies.

Validity is a stronger, optional guarantee: the document is well-formed and it conforms to a grammar declared in a DTD or XML Schema (XSD) — correct element order, required attributes, allowed data types, and so on. Checking validity requires the schema, which lives outside the document.

In practice, well-formedness catches the overwhelming majority of everyday XML mistakes (typos, unclosed tags, stray ampersands). Reach for a schema validator only when you need to enforce a specific contract.