Format and validate XML before it breaks your integration
XML is the backbone of SOAP APIs, RSS feeds, sitemaps, and countless enterprise configuration files, and it is brutally unforgiving: one unescaped ampersand or one mismatched closing tag makes a parser reject the entire document. When a partner system sends back a minified, single-line blob of markup, fixing it by eye is slow and error-prone. This tool pretty-prints any XML document and validates it for well-formedness right in the browser, reporting the exact problem instead of leaving you to guess.
Reach for it whenever you debug a failing web service, clean up an exported configuration file, or need to confirm that a document your code generates is actually parseable. Because validation and formatting happen locally, you never paste sensitive markup into a third-party server.
How to Format and Validate an XML Document
- Open the XML Formatter/Validator tool and paste your XML into the input area.
- Click the Format button; the tool indents nested elements and puts each tag on its own line so the structure becomes readable.
- Click Validate to check well-formedness; if the parser fails, read the reported line and character position to locate the problem.
- Fix the offending spot — usually an unescaped
&, an unclosed element, or a mismatched tag name — and re-run the check. - Copy the cleaned output back into your file or API request, then verify the document still parses after the edit.
- For documents with an XML declaration, confirm it stays on the first line; nothing may precede it, not even whitespace.
Real Example: Cleaning Up a Messy Config File
Suppose an export script produced a config file where every element was jammed onto one line and one attribute value contained a raw ampersand. Formatting reveals the hierarchy at a glance, and validation flags the exact character where the raw ampersand breaks the document. Escaping it as & makes the file valid again.
| Input | Output |
|---|---|
<note><to>ops</to><body>Tom & Jerry</body></note> | well-formed, but the raw & is flagged; use & |
<catalog><book id="1">XML Guide</book></catalog> | valid, formatted with one element per line |
Tips for Trouble-Free XML
- Escape the big five — always write
&for ampersands,<for<, and>for>inside text and attribute values. - Keep the declaration first — the
<?xml version="1.0" encoding="UTF-8"?>declaration, if present, must be the very first thing in the file. - Match every tag — an opening tag such as
<item>needs its exact counterpart</item>; XML is case-sensitive, so<Item>will not close it. - Quote every attribute — attribute values must be wrapped in single or double quotes, and attribute names cannot contain spaces.
- Use CDATA for scripts — wrap large blocks of code or markup that would otherwise need heavy escaping in
<![CDATA[...]]>.
When to Use the XML Tool
- API debugging — pretty-print SOAP responses and REST payloads that arrive as dense single lines.
- Build automation — validate generated sitemaps, feed files, or Maven and Ant build scripts before committing them.
- Legacy interop — check documents exchanged with banking, logistics, or healthcare systems that still mandate XML.
- Learning — study how nested elements, attributes, and namespaces are structured by formatting real-world samples.
XML Questions Developers Ask
What is the difference between well-formed and valid XML?
Well-formed means the document follows XML syntax rules: one root element, matched tags, quoted attributes. Valid goes further and requires the document to conform to a DTD or XML Schema, which the tool's well-formedness check does not enforce.
Why does my XML fail when it contains an ampersand?
In XML, a bare ampersand starts an entity reference. A literal ampersand must be written as &, and an unescaped one is a syntax error even inside attribute values.
Does the validator handle XML namespaces?
Yes. Namespace prefixes such as soap:Envelope are ordinary tag names to the parser, so documents using them format and validate normally as long as every prefix is declared.
What is CDATA and when should I use it?
CDATA sections let you include text that would otherwise need escaping, such as code samples with many < and & characters. Everything inside <![CDATA[...]]> is treated as plain text.
Does formatting change the meaning of my document?
No. Indentation and line breaks between elements are insignificant whitespace in XML, so pretty-printing preserves the information content. It only changes the visual layout.
Can the tool handle large XML files?
Very large documents may slow the browser because parsing happens locally. For multi-megabyte files, validate the source where it is generated, or split the document into logical chunks.
Why does my XML declaration keep failing?
The declaration must appear at the very start of the file with no leading whitespace or byte-order mark, and the version attribute is mandatory. Encoding is optional but must be a registered character set name.
Is XML the same as HTML?
No. HTML has a fixed set of tags and tolerates sloppy markup, while XML is a generic, strict format with any tag names you define. XHTML is the subset that follows XML rules.