XML Formatter & Validator

About this tool

This tool does three things with the XML you give it: reformats it with consistent indentation, minifies it by stripping insignificant whitespace, and checks whether it's well-formed — all in the same pass, since a formatter has to fully parse a document before it can safely rewrite it. All processing happens locally in your browser using the built-in XML parser; nothing you paste or upload is sent to a server.

"Well-formed" is a specific, checkable property: every tag is closed, elements are properly nested, attribute values are quoted, and there's exactly one root element. It's a weaker claim than "valid against a schema" — a document can be perfectly well-formed XML while still violating the rules of a particular XSD. If you need to check a document against a schema, use the XML ↔ XSD tool instead; this formatter only checks well-formedness, plus a couple of extra, non-fatal checks described below.

What the formatter preserves

Reformatting XML safely means knowing which whitespace is structural (safe to rewrite) and which is part of the actual content (not safe to touch). This tool handles the cases that trip up naive formatters:

• Mixed content — an element containing both text and child elements (like <p>Hello <b>world</b></p>) is left inline rather than having indentation inserted into it, since that would change what the text actually says.
• xml:space="preserve" — content inside an element carrying this attribute is reproduced exactly as written, including all original whitespace and line breaks.
• CDATA sections, comments, and processing instructions — kept intact and in place, not reflowed or escaped.
• The XML declaration — if your input has one (<?xml version="1.0" encoding="UTF-8"?>), it's kept as-is at the top of the output. If your input doesn't have one, this tool won't invent one.

Whitespace-only text sitting between element tags — the kind that exists purely for human readability in the source — is what actually gets rewritten when you change indent style or switch to Minify.

What "Validate" actually checks

Every parse attempt is a validity check: if the browser's parser can't build a document from your input, you'll see exactly where it gave up, down to the line and column. Beyond that hard check, this tool flags one additional non-fatal issue: an id attribute value reused on more than one element in the document, which is usually a mistake even though it doesn't make the XML malformed. This is a lightweight, best-effort check, not a substitute for schema or DTD validation.

How to use it

1. 01

   Paste, upload, or drop your XML

   Paste into the input pane, click Upload file, or drag a .xml file directly onto the input pane.

2. 02

   Choose Format or Minify

   Format pretty-prints with your chosen indent; Minify strips insignificant whitespace for a compact single-line-per-structure output.

3. 03

   Check the status bar

   A green bar means well-formed XML (with any warnings listed underneath); a red bar gives the exact line and column of the first problem.

4. 04

   Copy or download the result

   Copy to your clipboard, or download it as a standalone .xml file.

Example

<product id="1042"><name>Nesake</name><categories><category>JSON</category><category>Security</category></categories></product>

<product id="1042">
  <name>Nesake</name>
  <categories>
    <category>JSON</category>
    <category>Security</category>
  </categories>
</product>

Common use cases

Limitations

• This tool checks well-formedness, not validity against a DTD or XSD schema. Well-formed XML can still fail schema validation.
• Whitespace normalization inside attribute values (e.g. a literal newline becoming a space) follows the XML specification's attribute-value normalization rules — that's standard parser behavior, not something this tool adds or can disable.
• The duplicate-id check is a simple heuristic looking at any attribute literally named id; it isn't aware of DTD-declared ID types and won't catch every uniqueness constraint a schema might define.
• Very large files (multiple megabytes) will take longer, since the browser has to fully parse and rebuild the document tree, and extremely large inputs may be slow on lower-powered devices.

Best practices

• Keep an XML declaration (<?xml version="1.0" encoding="UTF-8"?>) at the top of files you'll hand to other systems — many parsers assume UTF-8 without it, which isn't always correct.
• Use xml:space="preserve" deliberately and only where whitespace is actually meaningful (like inside a <pre>-style element); it disables reformatting for everything inside that element.
• Minify only for transport or storage, not for files people will read or edit directly — pretty-printed XML is dramatically easier to review and diff.
• Validate before you minify. Once whitespace is stripped, a location-based error message ("line 1, column 4021") is much harder to act on than the same error caught on the original, formatted file.

Troubleshooting

• "Unexpected close tag" — an end tag doesn't match the most recently opened start tag, or a tag was never closed at all. Check the line and column given; the error points to where the parser noticed the mismatch, which is often just after the actual unclosed tag.
• "Not well-formed (invalid token)" — usually an unescaped &, <, or > inside text content. Replace with &, <, or >, or wrap the content in a <![CDATA[ ]]> section.
• "Extra content at the end of the document" — there's more than one root-level element, or stray text/markup after the closing tag of the root element. XML allows exactly one root element.
• "Duplicate attribute" — the same attribute name appears twice on one tag; XML doesn't allow this, unlike some HTML-tolerant parsers.
• Output looks identical to input — if the XML already matches your chosen indent style, or contains only a single leaf element, formatting can legitimately produce output that's the same or very close to what you started with.

Frequently asked questions

Related tools