XML Formatter & Validator

An XML formatter turns a long, unbroken string of XML into a neatly indented document you can actually read, and a good one tells you straight away if the XML is broken. Our free XML Formatter and Validator pretty-prints with two or four spaces or tabs, minifies when you need a compact version, and checks that the document is well-formed using your browser's own XML parser, pointing to the line and column of the first error where the browser reports them. It keeps the XML declaration, comments, CDATA sections and processing instructions, and leaves mixed content and xml:space="preserve" sections untouched. A built-in XPath tester lets you run queries against the document. Everything happens in your browser, so sitemaps, feeds, invoices and API payloads never leave your device.

How to use the XML formatter

1. 1 Paste your XMLDrop in a sitemap, RSS feed, SOAP response, configuration file or any other XML document. It can be one long line or already partly formatted.
2. 2 Choose format or minifyPick two spaces, four spaces or tabs and format for a readable, indented layout, or minify to strip the whitespace between elements for a compact copy.
3. 3 Read the well-formedness checkIf the parser finds a problem, you will see the error message and, where your browser provides them, the line and column so you can jump to the fault.
4. 4 Try an XPath queryType an XPath 1.0 expression to pick out elements, attributes or values. Namespace prefixes from your document work, and the default namespace is available as d:.
5. 5 Copy or download the resultCopy the formatted or minified XML to your clipboard, or download it as an .xml file ready to use elsewhere.

What an XML formatter does

XML, short for Extensible Markup Language, stores structured data as nested elements with opening and closing tags, much like HTML but with strict rules and tag names chosen by whoever designed the format. Systems that exchange XML rarely bother with line breaks, so the files you download or capture from an API often arrive as a single, enormous line. That is fine for software but almost impossible for a person to scan.

Formatting, also called pretty-printing, adds line breaks and indentation so each child element sits one level deeper than its parent. You can then see the shape of the data at a glance: which items repeat, where a value sits, and whether an element is in the place you expect. Minifying does the opposite, removing the whitespace between elements to make the file smaller for storage or transmission.

Our formatter is careful about what it touches. The XML declaration at the top, comments, CDATA sections and processing instructions such as stylesheet links are all kept. Elements that contain a mix of text and child elements, known as mixed content, are left as they are, because adding whitespace inside them could change the meaning of the text. Anything marked with xml:space="preserve" is also left exactly as written.

Well-formed versus valid XML

There are two different levels of correctness in XML, and it helps to know which one a tool is checking. A document is well-formed when it follows the basic grammar of XML: there is exactly one root element, every opening tag has a matching closing tag, tags are properly nested, attribute values are quoted, and special characters are escaped. Any XML parser will refuse a document that is not well-formed.

A document is valid when it is well-formed and also matches the rules of a particular schema, written as a DTD or an XSD file. The schema defines which elements are allowed, in what order, how many times, and what type of data each one holds. A UBL invoice, for example, can be perfectly well-formed but still invalid if a required element is missing or a date is in the wrong format.

Our tool checks well-formedness using the XML parser built into your browser, which is fast and reliable for that job. It does not perform DTD or XSD schema validation. For that you need a schema-aware validator, such as the xmllint command-line tool, an XML editor, or the validation service provided by the system you are sending the data to.

Common XML errors and how to fix them

Most broken XML falls into a handful of familiar patterns. When the checker reports an error, look at the line it mentions and the lines just before it, because the parser often only notices a problem some way after the actual mistake.

• Unclosed or mismatched tags: every opening tag needs a closing tag, and they must close in reverse order. An item opened inside a list must be closed before the list is.
• Unescaped ampersands: a bare & is not allowed in text or attribute values. Write & instead, so Fish & Chips becomes Fish & Chips. The same goes for a less-than sign, which should be <.
• Mismatched case: XML is case-sensitive, so an element opened as Price cannot be closed as price. HTML habits are a frequent cause.
• More than one root element: a document must have a single element that wraps everything else. Two sibling elements at the top level is an error.
• Unquoted or badly quoted attributes: attribute values must be inside single or double quotes, and the same quote mark must open and close the value.
• Text or a blank line before the XML declaration: if the declaration is used, it must be the very first thing in the file.

Where you will meet XML

JSON has taken over many web APIs, but XML is still everywhere, especially in publishing, finance, government and older enterprise systems. Some of the most common examples are close to home for anyone running a website.

XML sitemaps list the pages you want search engines to find, and a single stray ampersand in a URL can stop a sitemap being read. RSS and Atom feeds power podcasts, blog subscriptions and news aggregators. SOAP web services, still used by many payment, shipping and public sector systems, send requests and responses as XML envelopes. Configuration files for Java applications, .NET projects, build tools and Android apps are frequently XML. Electronic invoices often use the UBL standard, which public bodies across Europe accept for e-invoicing, and Microsoft Office files such as .docx and .xlsx are zipped collections of XML documents.

In all of these cases, a quick format and well-formedness check is a sensible first step when something will not load. It tells you immediately whether the problem is a syntax error in the file or something further along, such as a schema rule or a business rule in the receiving system.

Testing XPath queries

XPath is a small query language for picking parts out of an XML document. Our tester uses the document.evaluate function built into your browser, which supports XPath 1.0. A path such as /rss/channel/item/title selects every item title in a feed, while //title finds title elements anywhere in the document. Square brackets add conditions: //item[1] picks the first item, and //product[@sku] finds products that have a sku attribute. Functions such as count(//url) return a number rather than nodes.

The result panel shows whichever kind of answer your expression produces. A node-set is listed as the matching elements, attributes or text; a count or sum appears as a number; a comparison returns true or false; and string functions return text.

Namespaces are the usual reason an XPath query returns nothing. Sitemaps, Atom feeds, SOAP envelopes and UBL invoices all declare a namespace, and in XPath 1.0 an element in a namespace cannot be matched by its bare name. Our tester reads the prefixes declared in your document so you can use them directly, and makes the default namespace available under the prefix d:. In a sitemap, for example, //d:url/d:loc selects every page address.

Privacy: your XML stays on your device

Parsing, formatting, minifying and XPath evaluation all run in JavaScript inside your browser. Nothing you paste is sent to our server, stored or logged. That matters with XML, which often contains customer names, addresses, order details or invoice amounts. You can safely inspect API responses and exported data without passing them to a third party.

Nothing is saved between visits, so copy or download your formatted XML before closing the page.

Examples you can copy

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.co.uk/</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
  <url>
    <loc>https://www.example.co.uk/services/</loc>
  </url>
</urlset>

Broken:
<item><title>Fish & Chips Friday</title></item>

Fixed:
<item><title>Fish &amp; Chips Friday</title></item>

//d:url/d:loc            every page address
count(//d:url)           number of URLs (returns 2)
//d:url[d:lastmod]/d:loc  pages that have a lastmod date
string(//d:url[1]/d:loc) first address as text

Common mistakes to avoid

Frequently asked questions