Xerobit

XML Formatter

Format, validate, and beautify XML. Preserves attributes, processing instructions, and comments. Minify mode available.

How to use the XML formatter

  1. Paste your XML into the input box on the left. You can paste a fragment, a full document with declaration, or anything in between.
  2. Choose your indent style: 2 spaces (default), 4 spaces, tab character, or minified (collapses to a single line). The tool rerenders instantly on change.
  3. Wait for auto-format: formatting triggers automatically 300 ms after you stop typing. Press Ctrl+Enter (or ⌘+Enter on Mac) to run it immediately without waiting.
  4. Read the status bar: a green badge means the document is well-formed and the output is ready to copy. A red badge shows the parser's exact error message, including the line and column number where parsing failed.

The Copy button puts the formatted output on your clipboard. The Minify toggle collapses whitespace-only text nodes and strips indentation, useful before embedding XML in a JSON string or HTTP request body.

Why XML still matters in 2026

JSON dominated the last decade of API design, but XML never left. It underpins an enormous surface area of software infrastructure that gets maintained, extended, and debugged every day:

  • SOAP web services: enterprise banks, insurance systems, and government APIs still expose SOAP endpoints. Integrating a new microservice means wrapping or parsing SOAP envelopes.
  • SAML 2.0: the dominant SSO protocol in corporate environments. Every SAML assertion and response is XML, often base64-encoded inside a form POST.
  • RSS and Atom: podcast feeds, news aggregators, changelog notifications, and GitHub release feeds are XML. Millions of active subscribers depend on RFC-compliant XML.
  • SVG: every vector icon, illustration, and UI diagram embedded in a web page is XML. Knowing how to read and edit SVG source is a practical frontend skill.
  • OOXML and ODF: a .docx or .xlsx file is a zip archive full of XML files. Programmatic document generation (invoices, reports) means writing or patching that XML.
  • Android manifest: AndroidManifest.xml declares every activity, permission, intent filter, and service in an Android app. It is XML, and it must be valid.
  • Maven and Ant build files: pom.xml is the heart of every Maven Java project. Misconfigured XML means a failed build.
  • Spring, Hibernate, and .NET config: application context files, ORM mappings, and WCF configuration are still written in XML in many production codebases.

Understanding how to read, write, and debug XML is not optional for a full-stack developer working with any of these systems.

XML vs JSON: when to choose which

Both formats are mature and well-supported. The choice depends on context, not preference.

CapabilityXMLJSON
Schema validationXSD, RELAX NG, DTD: well-tooledJSON Schema, good, but less mature
NamespacesBuilt-in (xmlns)None (convention only)
CommentsYes (<!-- ... -->)No
Mixed contentYes (text + child elements)No
Browser parsingDOMParser, slowerJSON.parse, very fast
REST/HTTP APIsRare new usageDefault choice
Document formatsDominant (OOXML, EPUB, SVG)Rarely used
Human readabilityVerbose but self-describingConcise, requires key knowledge

Use XML when you need a formal schema, namespaces for merging vocabularies, or are working in a domain where XML is the standard. Use JSON for REST APIs, browser storage, and any format where parsing speed and terseness matter more than schema rigor.

What this tool validates: well-formedness vs schema validation

This formatter uses the browser's native DOMParser API to parse XML. DOMParser checks well-formedness: every opening tag has a matching closing tag, attribute values are quoted, entities are recognized, there is exactly one root element, and the document encoding is handled correctly. If the document is not well-formed, DOMParser returns a parseerror document instead of the real DOM, and this tool surfaces that error message directly.

What it does not check is validity against a schema. Schema validation requires loading an XSD, DTD, or RELAX NG file and running a validating parser such as xmllint --schema schema.xsd file.xml, Saxon EE, or a library like lxml in Python. Schema validation catches errors like a required element being absent or an attribute containing a value outside its allowed enumeration, things a well-formedness check cannot catch because it has no knowledge of what the document is supposed to contain.

For most debugging purposes, fixing a config file, reading an API response, editing a manifest, well-formedness checking is exactly what you need, and it runs instantly with no external dependencies.

Common XML errors and how to fix them

  • Unbalanced tags: every <tag> needs a matching </tag> or must self-close as <tag />. HTML-style void elements like <br> are not valid XML, they must be <br />.
  • Unescaped ampersand: a bare & character in text content or attribute values is illegal in XML. It must be written as &amp;. The same applies to < (use &lt;) and > in some contexts (&gt;).
  • Attributes without quotes: XML requires every attribute value to be enclosed in single or double quotes. <item id=123> is not valid; <item id="123"> is.
  • Multiple root elements: a well-formed XML document must have exactly one top-level element. Pasting two separate XML snippets without wrapping them produces this error. Wrap them in a container element.
  • XML declaration not first: if you include <?xml version="1.0" encoding="UTF-8"?>, it must appear as the absolute first bytes of the document. A BOM character, a blank line, or a space before it causes a parse failure.
  • Invalid characters: control characters other than tab, newline, and carriage return are not permitted in XML 1.0 documents. They sometimes appear in data exported from databases. Use XML 1.1 or strip them before parsing.
  • Tabs in indentation vs attribute values: tabs are legal whitespace between elements but can cause visual confusion in mixed indentation. Some style guides require space-only indentation in XML for consistency.

XML namespaces explained

Namespaces solve the collision problem: when you combine two XML vocabularies in a single document, for example, embedding XHTML inside an Atom feed, both might define an element called <title>. Namespaces let you say which vocabulary owns each element.

A namespace is declared with the xmlns attribute, typically on the root element: xmlns="https://www.w3.org/2005/Atom" sets the default namespace. xmlns:xhtml="http://www.w3.org/1999/xhtml" declares a prefix. Any element or attribute prefixed with xhtml: then belongs to the XHTML namespace, while unprefixed elements belong to the Atom namespace.

The namespace URI is just an identifier, it does not need to resolve to a real URL, though by convention it often does point to schema documentation. What matters is that two documents using the same URI are talking about the same vocabulary.

This formatter preserves all namespace declarations and prefixes exactly as written. Prefixes are not rewritten or normalized. If your source document uses ns0: as a SOAP prefix, the output will too.

XPath basics: querying XML

Once you have well-formed XML, XPath is the standard language for selecting nodes. Knowing a handful of patterns covers most practical debugging and scripting needs:

  • //element: selects all elements with that name anywhere in the tree (descendant-or-self axis).
  • /root/child: absolute path from the document root.
  • //item[@id="42"]: selects <item> elements with an id attribute equal to 42.
  • //item/text(): selects the text node children of all <item> elements.
  • count(//item): returns the number of matching elements as a number.
  • //item[last()]: selects the last <item> in its parent's child list.

XPath works in the browser via document.evaluate(), in the command line via xmllint --xpath "//title" file.xml, in Python via lxml's tree.xpath(), and in every major XML library. Formatting your XML first makes writing and debugging XPath expressions significantly easier.

FAQ

Does the formatter preserve namespaces?

Yes. Namespace declarations (xmlns and xmlns:prefix attributes) and prefixed element and attribute names are passed through exactly as written. The formatter does not rewrite, canonicalize, or inline namespace declarations.

What about CDATA sections?

CDATA sections (<![CDATA[ ... ]]>) are preserved verbatim in the output. The formatter does not escape CDATA content or reflow it. This matters for embedded scripts, SQL strings, and any content that deliberately contains characters like < and & without escaping them.

Will it handle very large XML files?

The formatter runs entirely in the browser using DOMParser, which holds the entire DOM in memory. Files up to a few megabytes work smoothly. For files above ~10MB, consider xmllint --format file.xml on the command line, which streams the document and handles arbitrarily large files without memory pressure.

Pillar