Skip to content
SDETRole
SDETRole

JSON & Data

XML Formatter

Pretty-print or minify XML while keeping CDATA, comments and PIs.

Runs entirely in your browser No sign-up

Input XML

0 chars

Formatted

About this tool

SOAP responses, sitemaps, Maven POMs and JUnit XML reports are hard to read on a single line. This formatter first checks that the input is well-formed using the browser’s own XML parser, then re-indents it with a tokenizer that leaves CDATA sections, comments, processing instructions and the DOCTYPE exactly as written. Elements that contain only text stay on one line, so the output reads like hand-written XML rather than one tag per line.

How to use it

  1. Paste XML or load the sample order document.
  2. Choose Format and an indentation (2 spaces, 4 spaces or tab), or Minify to collapse it to one line.
  3. If the XML is not well-formed, fix the line and column shown in the red banner.
  4. Copy or download the result.

Well-formed is not the same as valid

Well-formed XML follows the syntax rules: exactly one root element, every tag closed and correctly nested, attribute values in quotes, and special characters escaped. Valid XML is also well-formed and conforms to a schema (XSD) or DTD that defines which elements and values are allowed. This formatter checks well-formedness, because the document has to parse before it can be re-indented. Checking against an XSD is a separate step.

Common reasons XML will not parse

  • An unescaped ampersand or less-than sign in text: write & and <, or wrap the text in a CDATA section.
  • Tags that differ only in case, such as <Order>…</order>: XML is case-sensitive.
  • More than one top-level element: wrap them in a single root.
  • An attribute value without quotes, as in <item id=7>.
  • A namespace prefix without a declaration, such as <soap:Envelope> with no xmlns:soap="…" attribute.
  • Anything before the XML declaration: <?xml version="1.0"?> must be the very first characters, with no whitespace before it.

Where testers meet XML

SOAP and legacy enterprise APIs, JUnit XML test reports (the format most CI servers read), Maven pom.xml files, sitemaps, RSS feeds and Android layouts are all XML. Playwright writes JUnit XML with reporter: [['junit', { outputFile: 'results.xml' }]], and formatting that file is the quickest way to see why CI counted a test as failed.

To assert on XML in code, REST Assured supports XPath matchers such as body(hasXPath("/order/status[text()='SHIPPED']")). On the command line, xmllint --format file.xml pretty-prints a file, and Python’s xml.dom.minidom.parseString(text).toprettyxml() does the same in a script. To try XPath expressions interactively, use the XPath & CSS Selector Tester.

XML Formatter FAQ

Does formatting change my data?

Whitespace-only text between tags is dropped and re-created as indentation, and text inside elements is trimmed. That is harmless for data-oriented XML, but in mixed content or elements where xml:space="preserve" matters, compare the result before using it.

Are CDATA sections and comments kept?

Yes. They are copied byte for byte, including any markup inside CDATA. In Minify mode you can optionally remove comments.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →