Is my XML uploaded anywhere?

No. The formatter runs entirely in your browser using JavaScript. Your XML is never sent to a server, which is why it works offline once the page has loaded.

How accurate is the formatting?

The tool re-indents based on tag nesting depth — opening tags indent, closing tags dedent, and self-closing tags, comments and the XML declaration are left on their own line. It tidies layout but does not validate against a schema or DTD, so it will not catch semantic errors.

What is the difference between formatting and minifying?

Formatting adds line breaks and indentation so the nesting is readable. Minifying strips the whitespace between tags and collapses everything onto a single line, which shrinks payload size for transport or storage.

Which indentation options are available?

You can choose 2 spaces, 4 spaces or a tab character. Two spaces is the most common default for XML config and SOAP payloads; tabs suit teams that already indent code with tabs.

Does it handle the XML declaration, comments and CDATA?

Yes. The ` ` declaration, ` `, ` ` blocks and processing instructions are treated as single-line tokens that print on their own line without affecting indent depth, so their contents stay byte-for-byte intact.

Will it fix broken or unclosed tags?

No. It is a pretty-printer, not a validator. If a tag is left unclosed the trailing text is kept verbatim rather than dropped, but mismatched nesting will still produce mismatched indentation — run a validator for structural errors.

What is the XML Formatter & Minifier?

Free online XML formatter. Pretty-print messy XML with 2-space, 4-space or tab indentation, or minify it to a single line. Privacy-first — your XML never leaves your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

XML Formatter & Minifier

Name: XML Formatter & Minifier
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

XML formatter and minifier

Paste raw or minified XML and get back a clean, indented document — or collapse a formatted file back down to a single line. This is the everyday “beautify my XML” tool for developers working with SOAP envelopes, RSS/Atom feeds, Android layout files, SVG markup, sitemaps and config files that arrive as one unreadable line.

Pretty-print and minify rules

The formatter is a dependency-free pretty-printer that runs in two passes. First it tokenizes the input on tag boundaries, classifying each chunk as an opening tag, a closing tag, a self-closing tag (<x/>), a leaf (the <?xml ?> declaration, , CDATA or processing instructions) or a text node. Then it re-emits each token with indentation driven by a depth counter:

a closing tag dedents before it prints;
an opening tag prints, then indents its children;
self-closing tags and leaf tokens print on their own line without changing depth;
text sitting between an opening tag and its matching close is printed inline.

Minify mode skips the indentation entirely and joins every tag onto one line. Only whitespace between tags is touched — attribute values, text content, comments and CDATA are never altered.

Example

Paste this one-line input:

<note><to>Gera</to><body private="true">Hi</body></note>

With 2-space indentation, Format produces:

<note>
  <to>Gera</to>
  <body private="true">Hi</body>
</note>

Run Minify on the indented version and you get the original single line back.

Indent option	Use when
2 spaces	Default for most XML, SOAP and config files
4 spaces	Deeply nested docs where extra width aids scanning
Tab	Teams that already indent with tabs

Everything runs locally in your browser as plain JavaScript — your XML is never uploaded, so it is safe for proprietary payloads and works offline once loaded.

When formatting vs minifying is the right move

Format for readability when you need to:

Debug a SOAP response from a legacy API by finding the right element
Review an Android layout XML file to understand view hierarchy
Read through a sitemap to check URL paths and modification dates
Inspect an RSS or Atom feed that an API returned as one unbroken string
Compare two XML config files visually (line-by-line diff works far better on formatted XML)

Minify for transport or storage when:

Sending XML over a network where payload size affects speed or cost
Storing XML in a database column where space is constrained
Embedding XML in a file format that expects a compact representation
Preparing a response from a service that was originally hand-formatted with inconsistent spacing

What this formatter does not do

This is a pretty-printer, not a validator or schema checker. It corrects indentation and collapses whitespace between tags, but it will not:

Tell you whether your XML is schema-valid (matches an XSD or DTD)
Fix unclosed tags or mismatched tag names
Normalise attribute quoting (single vs double quotes remain as written)
Handle XML namespaces specially — namespaced tags are treated as opaque token strings

If you need structural validation, use the XML-to-JSON converter on this site: a parse error there (signalled by a parsererror element in the output) means your XML is not well-formed.

CDATA and processing instructions

<![CDATA[ ... ]]> sections are treated as single opaque tokens and printed on their own line. Their contents — which can include characters that would otherwise be reserved in XML — are preserved byte-for-byte. Similarly, processing instructions like <?xml-stylesheet type="text/xsl" href="style.xsl"?> are kept as single-line tokens that do not affect indentation depth.

Whitespace in XML is data — format with care

Unlike JSON, XML has no single canonical notion of insignificant whitespace: text nodes are content, and the W3C XML specification provides the xml:space="preserve" attribute precisely because some documents carry meaningful spacing. A formatter must therefore distinguish element-only content (safe to re-indent) from mixed content — elements interleaved with text, as in XHTML paragraphs — where inserting line breaks would change the data. This tool re-indents structural markup and leaves text content intact, which is the conservative behaviour; if a downstream system compares documents byte-for-byte or signs them (XML digital signatures), format a copy for reading and keep the original untouched, because even semantically harmless whitespace changes break signatures and checksums.

MDN’s XML introduction is a good practical companion to the specification for teams newer to XML.

A related workflow habit: when inspecting XML from an API or log, format a copy immediately and keep the raw original beside it. The formatted copy is for reading; the original is what you attach to bug reports and reprocess, since it is the bytes the system actually produced.