Skip to content
Tools

XML Formatter

Format, beautify and validate XML documents instantly with customizable formatting options. Everything runs locally in your browser.

Visible pane

XML

0 chars

Loading editor…

Waiting for XML

What is XML formatting?

XML documents are usually generated, and a generator has no reason to put newlines in. What comes back from a SOAP endpoint, out of a build tool or off a CDN is one line of several thousand characters, holding a structure nested five or six deep that is completely invisible in it. Formatting puts that structure back on the screen: one element per line, indentation showing what sits inside what, attributes readable rather than run together.

The same document, before and after
<order id="A-1042"><customer>Ada Lovelace</customer><lines><line sku="KB-8842" qty="1"/><line sku="MS-1120" qty="2"/></lines></order> <order id="A-1042">  <customer>Ada Lovelace</customer>  <lines>    <line sku="KB-8842" qty="1" />    <line sku="MS-1120" qty="2" />  </lines></order>

Nothing changed except the whitespace between tags. Names, attributes, values and entities are all reproduced exactly — an attribute quoted with an apostrophe stays quoted with an apostrophe, and nothing is re-escaped.

There is one honest caveat, and it is worth stating rather than glossing over. XML has no ignorable whitespace without a schema. A consumer is entitled to notice the newlines and indentation between elements, and in principle a reformatted document is not byte-identical to a parser that cares. In practice almost nothing does, which is why formatters exist at all. What this tool will not do is put whitespace inside a value: an element holding text stays on one line, and a CDATA section is never touched.

Everything runs in your browser. The XML people paste into a formatter is routinely a real response with a real customer in it, so nothing is uploaded, stored or logged.

Why format XML?

Because a document you cannot see the shape of is a document you cannot reason about — and because the mistakes XML is prone to are structural ones that only become visible once the structure is on the screen.

  • Responses become readable. A SOAP body, an API payload or a feed arrives on one line. Formatting is the first step to understanding any of them, and usually the only one needed — when it is the data you want rather than the markup, converting the document to JSON is the step after.
  • Nesting stops being invisible. Five levels of wrapper look much like two until they are indented, and the depth on screen is the depth in the document.
  • Diffs shrink to the actual change. With one element per line, adding an entry to a POM is a one-line diff in a pull request or in a diff checker. Without it, a single reformat buries the change nobody can then find.
  • Errors surface immediately. A formatter has to parse before it can print, so the unclosed tag on line 400 is reported the moment you paste rather than when a consumer rejects the file.
  • Namespaces become legible. Prefixes are highlighted apart from the names they qualify, so a document that is nine tenths soap: stops reading as a wall.
  • Teams stop reformatting each other’s files. One agreed set of options, applied by a tool, ends the argument about where the attributes go.

Supported XML documents

Anything that is XML, which is more than most people expect. The list below is not a set of modes to choose between — there is one parser and one printer, and they handle all of it, because underneath the schemas and conventions these are the same language.

XML

The general case: a single root element, nested children, attributes on tags, and text inside. Everything below is this with a schema and a convention on top, which is why one formatter handles all of them.

SOAP

An envelope wrapping an optional header and a body, every name prefixed. Arrives as one enormous line from almost every client, which is exactly what a formatter and a collapsible tree are for.

RSS

A channel holding items, usually with a content:encoded element carrying HTML inside CDATA. That CDATA is left completely alone here — reformatting it would change the markup a reader renders.

Atom

The other feed format: a default namespace rather than prefixes, entries rather than items, and typed title and summary elements. Dates are ISO 8601 where RSS uses the RFC 822 form.

SVG

Vector graphics, and XML throughout. A path's d attribute is often thousands of characters, so the line-width setting and word wrap both matter here more than anywhere else.

Sitemap

A urlset of url elements, each with a loc and usually a lastmod. Small, repetitive and easy to get subtly wrong — a missing closing tag in one entry invalidates the whole file for a crawler.

Configuration

Maven POMs, Android manifests, .NET app.config, Spring beans, property lists. Usually hand-edited, usually under version control, and the place where consistent formatting pays for itself in smaller diffs.

XHTML

HTML written to XML's rules: every tag closed, every attribute quoted, everything nested properly. Formats here exactly like any other document — the self-closing style option exists largely for it.

Formatting features

Indentation

Two spaces, four spaces or tabs, applied to nesting and nothing else. An element whose content is text stays on one line — <name>Ada</name> is never split across three, because that would put a newline and an indent inside the value, and in XML that is content rather than layout.

Attributes

On the tag line, one per line, or exactly as written. On the tag line is the default and moves attributes onto their own lines only when the tag passes the line width, which is adjustable from 80 to 200 characters — useful for an Android manifest or an SVG, where a single element can carry a dozen.

A long tag, wrapped
<application  android:name=".ToolsApplication"  android:allowBackup="true"  android:icon="@mipmap/ic_launcher"  android:label="@string/app_name"  android:theme="@style/Theme.Tools">

Tree view

The document as a structure rather than as text. Expand and collapse any branch, open everything, or jump straight to a depth. A collapsed element shows the text it holds and how many children it has, so you can find your way around without opening anything. Every row copies either the node’s own markup — taken from the source, so it is exactly what was written — or its XPath, which is what you want when the next step is a query rather than a copy.

Syntax highlighting

Tags, namespace prefixes, attributes, attribute values, CDATA, comments, processing instructions and the DOCTYPE each get their own treatment, in both panels and in both light and dark themes. The prefix is deliberately separated from the name it qualifies: in a SOAP envelope that is the difference between reading the structure and reading the same six characters two hundred times.

Validation

Parsing is validation, so it comes free — and nothing is formatted until the document parses, because rearranging a broken document only hides the problem. When the parser stops you get the message, the line, the column, a caret under the character and a button that takes you there.

  • Missing, mismatched or badly nested tags, reported against the element that was still open rather than against the end of the file.
  • Unquoted, duplicated or malformed attributes, including the < inside a value that almost always means a closing quote went missing.
  • Unterminated comments and CDATA sections, which are the most destructive kind of error because everything after the opening is being read as something it is not.
  • Bare ampersands and unknown entities. Without a DTD, XML defines only five — &nbsp; is not one of them.

And, separately, things that are legal XML and still wrong:

  • A namespace prefix nothing declares, checked with scope — so a prefix bound inside one branch is correctly reported when used in another.
  • A declaration that is not the first character of the file. One blank line above <?xml makes a strict reader reject the document, and it is invisible on screen.
  • An encoding no reader will recognise, and a note when a document declares something other than UTF-8.

Namespace support

Prefixes are highlighted, listed in the statistics in the order they first appear, searchable in the tree, and checked for declaration with proper scoping. The reserved xml: prefix never needs declaring and is never flagged.

Common XML constructs

Six things make up every XML document. Knowing which one you are looking at is most of knowing why a parser is complaining about it.

Elements

The structure. Exactly one root, everything nested inside it, and names that are case-sensitive — <Item> and <item> are different elements, and mixing them is a common source of a parser that reads nothing.

Attributes

Name-value pairs on a tag. Every value needs quotes, single or double, and no element may carry the same attribute name twice. Unlike HTML there is no such thing as a bare attribute: write disabled="disabled", not disabled.

Namespaces

A way for two vocabularies to share a document without colliding. xmlns:soap binds a prefix, plain xmlns sets a default for an element and its descendants, and both are scoped — a prefix means nothing outside the element that bound it.

CDATA

A section whose contents are taken literally, so markup and ampersands inside it are text. Used for embedded HTML, scripts and anything else that would otherwise need escaping character by character.

Comments

Delimited by the same markers HTML uses, and not allowed to contain a double hyphen anywhere inside. Preserved in place here, and dropped by minification unless you say otherwise — sometimes a comment is layout and sometimes it is meaning.

Processing instructions

Addressed to whatever consumes the document rather than to the parser, and written with a target and some data between question marks. The xml declaration is one of these by syntax, carries the encoding, and is treated as its own thing here because of it.

XML best practices

Nest properly, and close everything

XML has no optional closing tags and no implied nesting, which is the whole point of it: a document either parses or it does not, and there is no recovery mode to disagree about. Tags close in the order they opened, names are case-sensitive, and an element with no content is written <thing/> rather than left hanging.

Nesting, right and wrong
<a><b>text</b></a>     <!-- correct --><a><b>text</a></b>     <!-- b is still open when a closes --><a><B>text</b></a>     <!-- B and b are different elements -->

Indent to show nesting, not to decorate

Indentation should mean exactly one thing: this is inside that. Used for anything else — lining up attribute values, centring things — it breaks the moment a name gets longer, and it turns every future edit into a reformatting diff.

Declare namespaces where they belong

Bind a prefix on the highest element that needs it, usually the root, rather than repeating the declaration down the document. Use a prefix consistently: nothing stops you binding the same URI to ns1 in one file and soap in another, and nothing makes it pleasant either. A namespace URI is an identifier, not an address — it does not have to resolve, and using a real URL you control is a convention rather than a requirement.

Choose between an attribute and an element deliberately

Attributes suit metadata that is single-valued and unlikely to grow — an id, a currency, a flag. Elements suit anything that might one day need structure, repetition or a value long enough to be awkward on one line. The test worth applying: could this ever have children? If it could, make it an element now.

Escape what has to be escaped

Five characters carry meaning: &, <, >, " and '. An ampersand in text is the single most common XML error there is, and it has to be written &amp;. For a value with a lot of them — embedded HTML, a script, a query — a CDATA section is easier to read and easier to keep right than escaping each character individually.

Validate before you send, not after they reject

Well-formedness is the floor and takes a second to check. A schema — XSD, DTD or RELAX NG — is the next step up, and answers a different question: not “is this XML” but “is this the XML we agreed on”. This tool answers the first question exactly, and does not pretend to answer the second.

XML formatter vs XML minifier

Opposite goals, and both are on this page. A formatter makes a document readable. A minifier makes it smaller to send. You format the copy you read and minify the copy that crosses a wire.

The same document, formatted and minified
<!-- formatted --><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">  <url>    <loc>https://example.com/</loc>    <lastmod>2026-08-04</lastmod>  </url></urlset> <!-- minified --><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url><loc>https://example.com/</loc><lastmod>2026-08-04</lastmod></url></urlset>

Notice what minifying did not do. It removed the whitespace between tags and nothing else — no names shortened, no attributes reordered, no text touched. Text and CDATA are content in XML, so a minifier that trims them changes the document. That makes the saving smaller than minifying HTML or JavaScript, where whitespace in most positions genuinely is meaningless. It also makes the result safe to send somewhere strict, which is the only reason to minify XML in the first place.

Comments are the one judgement call. They are removed by default, because in most documents they are a note to a maintainer rather than something a consumer reads — but in a few they carry meaning, so there is a setting for it.

When to reach for which: format when you are reading, debugging, reviewing a diff or editing by hand. Minify when the document is about to be transmitted or stored at volume, and you would rather not pay for the indentation a million times.

Common use cases

The same tool, reached for at different moments. Every one of them starts with a document that arrived in a state nobody chose.

SOAP APIs

The response comes back as one line and the fault you are looking for is somewhere in the middle of it. Format it, collapse the envelope, and read the body.

RSS feeds

Checking a feed you generate is well-formed before a reader rejects it, and reading one you consume to find out what a publisher actually puts in each item.

Sitemaps

A sitemap that does not parse is a sitemap a crawler silently ignores. Validating it here takes a second and tells you the line rather than leaving you to guess.

SVG graphics

Icons exported from design tools arrive minified, with generated ids and a single line thousands of characters long. Formatting is the first step to editing one by hand.

Enterprise systems

EDI, HL7 wrappers, banking messages and anything with a WSDL behind it. Large, deeply nested, heavily namespaced — the documents a tree view was invented for.

Configuration files

A Maven POM or an Android manifest with consistent formatting produces a diff that shows what changed. Without it, one editor's reformatting buries the change in noise.

Data exchange

Anything crossing a boundary between two systems. Formatting is how you check what you are sending, and validating is how you find out why the other end rejected it.

Debugging

An unclosed tag on line 400 of a generated document. The parser stops there and says so, with a caret under the character and a button that takes you to it.

Frequently asked questions

Is this XML Formatter free?

Yes. Formatting, minifying, validating, the tree view, uploading, downloading and every option are free, with no account, no sign-up and no cap on how many documents you format.

Is my XML uploaded anywhere?

No. The document is parsed and printed by JavaScript running in your browser. Nothing is sent to a server, nothing is stored and nothing is logged. You can disconnect from the network after the page loads and the tool keeps working — which matters, because the XML people paste into a formatter is routinely a SOAP response with a customer's details in it, or a config file with an endpoint and a key.

Will formatting change my XML?

It changes the whitespace between tags, and nothing else. Tag names, attributes, attribute values, entities, CDATA and comments are all reproduced exactly as written — an attribute quoted with an apostrophe stays quoted with an apostrophe, and nothing is re-escaped. The one thing to know is that whitespace between tags is not always meaningless: XML has no notion of ignorable whitespace without a schema, so a consumer is entitled to see it. In practice almost nothing does, which is why formatters exist at all. An element holding text is never split across lines, because that would put a newline and an indent inside the value.

Can I format SOAP responses?

Yes, and it is one of the things this is most useful for. A SOAP envelope arrives as one line of several thousand characters, with prefixed names throughout. Formatting gives it structure, the tree view lets you collapse the envelope and header to get at the body, and namespace prefixes are highlighted separately from the names they qualify so a wall of soap: stops fighting for attention.

Can I validate XML?

Yes. Every document is parsed before anything is formatted, so unclosed tags, mismatched or badly nested tags, unquoted or duplicated attributes, unterminated comments and CDATA sections, bare ampersands and malformed names are all caught, with the line, the column and a caret pointing at the character. On top of well-formedness it checks things that are legal XML and still wrong: a namespace prefix nothing declares, a declaration that is not at the very start of the file, and an encoding no reader will recognise.

Why won't it format my document?

Because it does not parse. A formatter that rearranges a broken document produces a differently broken document and hides the one thing you needed to be told, so nothing is printed until the document is well-formed. The Issues tab has the line, the column and what to do about it, and clicking the location takes you there.

Why does it only report one syntax error?

Because a parser stops at the first thing it cannot read, and everything after that point is unparsed rather than wrong. A single missing closing tag would otherwise produce a page of invented errors, all describing the same mistake. The warnings and notes below it are different — those come from a separate pass and you may well see several at once.

Does it support namespaces?

Fully. Prefixes are highlighted apart from the local names they qualify, the statistics list every prefix the document binds, and the validator checks each one is actually declared — with scope, so a prefix bound inside one branch is correctly reported as undeclared when it is used in another. The reserved xml: prefix never needs declaring and is not flagged.

Can I format SVG files?

Yes. SVG is XML, so everything applies: upload a .svg file, format it, explore it in the tree, and download it still named .svg. The self-closing style option is worth knowing about here — the spaced form, <path />, is the convention in SVG and XHTML because an older HTML parser needed the gap.

Can I upload XML files?

Yes. Use the upload button or drag a file anywhere onto the tool. .xml, .svg, .rss, .atom, .xhtml, .xsl, .xslt, .xsd, .wsdl and .plist are all accepted, and the extension is kept when you download the result. Files are read as UTF-8.

What if my document declares a different encoding?

It is noted rather than acted on, and the reason is worth being plain about: the declaration describes the bytes in a file, and by the time text reaches a web page the browser has already decoded it. A document declaring ISO-8859-1 gets an informational note saying so. If the characters look wrong, the file needs converting to UTF-8 before it gets here — no in-browser tool can undo a decoding that has already happened.

How large a document can it handle?

Up to about 20 MB. Anything past 100 KB is processed on a background thread so the page keeps responding, the tree renders only the rows on screen, and the parser makes a single pass with an explicit stack rather than recursion — so a document nested a thousand levels deep is fine where a recursive parser would overflow.

What does the tree view do?

It shows the document as a structure rather than as text: expand and collapse any branch, open everything or collapse everything, or jump straight to a depth. A collapsed element shows its text and how many children it has, so you can navigate without opening anything. Every row copies either the node's own markup — taken from the source, so it is exactly what was written — or its XPath. Attributes and text nodes can each be hidden when you want to see only the shape.

Can I search the document?

In both panels. Ctrl/Cmd+F opens a search over the text with every match highlighted, a counter, and previous and next. The tree has a search of its own that matches nodes rather than characters, scoped to tags, attributes, text or all three, and stepping through it opens whatever branches are needed to reveal each hit. Searching for a namespace prefix in the tag scope finds every element in that namespace.

Is CDATA preserved?

Always, and it is never re-indented. Taking its contents literally is the entire purpose of the construct, so a CDATA section is placed on a line and otherwise left completely alone — including its internal newlines and spacing. It is the one thing here with no option to change it, because there is no correct way to reformat it.

What is the difference between formatting and minifying?

Opposite goals. Formatting makes a document readable — one element per line, indentation showing the nesting. Minifying strips the whitespace between tags so it is smaller to send. You format the copy you read and minify the copy that goes over a wire. Minifying XML saves less than minifying HTML or JavaScript, because text and CDATA are content and cannot be touched; what it removes is the indentation, and optionally the comments.

Are comments and processing instructions kept?

Yes by default, and each can be turned off. The <?xml ?> declaration is the exception: it looks like a processing instruction and carries the encoding, so it is never dropped even when processing instructions are. Minifying removes comments by default, which is a separate setting because sometimes a comment is meaning rather than layout.

What about the DOCTYPE?

It is preserved as written, including an internal subset, and can be turned off. What is not done is acting on it: entities and default attributes it declares are not expanded. That is partly scope and mostly safety — expanding entities from a DOCTYPE is exactly how the billion-laughs attack works, and a document with an internal subset gets a note saying the subset was not applied.

What do the statistics count?

Elements, attributes, namespaces, comments, CDATA sections, processing instructions, maximum nesting depth, characters, lines, input and output size with the difference between them, and how long the pass took. The namespace list shows every prefix the document binds, in the order it first appears.

Are there keyboard shortcuts?

Ctrl/Cmd+Enter formats, Ctrl/Cmd+Shift+M minifies, Ctrl/Cmd+Shift+T opens the tree, Ctrl/Cmd+Shift+C copies the output, Ctrl/Cmd+Shift+D downloads it, Ctrl/Cmd+Shift+L loads another sample, Ctrl/Cmd+Shift+Delete clears the input, and Ctrl/Cmd+F opens whichever search belongs to the panel in front. Escape closes it.

Does it work offline?

Once the page has loaded, yes. Everything runs locally, so you can disconnect and keep formatting. A connection is only needed to load the page the first time.

Popular tools

↑ ↓NavigateOpenEscClose