Formatar XML
XML Formatter re-indents an XML document in your browser using a single-pass tokenizer, so comments, CDATA sections, DOCTYPE subsets and attribute values containing angle brackets all survive intact. It reports mismatched or unclosed tags with a line and column rather than silently reshaping the tree.
A interface desta ferramenta está em inglês.
O guia abaixo está disponível apenas em inglês.
How does XML Formatter work?
Most XML formatters are a series of regular expressions: strip the comments, then split on tags, then re-indent. That ordering cannot be made correct, because the passes depend on each other in a circle. Deciding whether <!-- opens a comment requires knowing whether you are inside a CDATA section. Deciding where a CDATA section starts requires knowing you are not inside a comment. Deciding whether > ends a tag requires knowing whether you are inside an attribute value. Whichever order you choose, one of the three is wrong, and the failure is silent corruption rather than an error.
So this formatter scans the document exactly once into a token stream — declaration, processing instruction, DOCTYPE, comment, CDATA, open tag, close tag, self-closing tag, text — and everything after that is a fold over those tokens. The tokenizer is lossless by construction: every byte of the input lands in exactly one token, and there is a test asserting that concatenating them reproduces the original document byte for byte.
That design is what makes the awkward cases work rather than being special-cased. A DOCTYPE with an internal subset may contain > inside it, so the scan tracks bracket depth instead of taking the first closing angle. An attribute value may contain >, so tag scanning tracks quotes. A bare < that is not the start of a tag — invalid XML, ubiquitous in hand-written files — is carried through as text rather than aborting a format the author can see should succeed.
Indentation keeps one deliberate exception: an element whose only child is text stays on one line, so you get <name>Ada</name> rather than three lines for two words. Exploding every leaf is the main reason machine-formatted XML is harder to read than the hand-written kind.
When the tree does not close properly, the formatter stops and says where. A mismatched </c> where </b> was expected is reported with its line and column; a document that ends mid-tree names the elements still open. The alternative — quietly closing the tags for you — produces a document that looks right and is not the one you had, which is the worst outcome available.
Minified in
<r><a id="1"><b>x</b></a><!-- c --><d/></r>
Formatted out
<r>
<a id="1">
<b>x</b>
</a>
<!-- c -->
<d />
</r>What options and edge cases does XML Formatter support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Indent | 2 | 4 | tab | 2 spaces | Applied per nesting level. Tabs are the right choice when the file will be read in editors with different preferences, since each reader controls the visual width. |
| Collapse whitespace | boolean | true | Normalises runs of spaces and newlines inside text nodes. Turn it off for documents where text content is whitespace-significant, such as embedded source code outside a CDATA section. |
| Strip comments | boolean | false | Removes <!-- … --> entirely. Comments are preserved by default because in configuration files they are frequently the only documentation there is. |
| Wrap attributes | integer | 0 (never) | Above this count, each attribute goes on its own line. Useful for SVG and XSLT, where a single element can carry a dozen attributes and an unwrapped line runs off the screen. |
| CDATA | preserved | — | Reproduced verbatim, including internal whitespace and any characters that look like markup. The whole point of a CDATA section is that its contents are not parsed. |
| DOCTYPE | preserved | — | Kept intact, including an internal subset containing > characters. Scanning to the first > truncates the declaration and turns the remainder into text. |
| Namespaces | preserved | — | Prefixes and xmlns declarations pass through unchanged. This is a formatter, not a validator: it does not check that a prefix is bound. |
| Malformed input | error | — | A mismatched closing tag, an unterminated comment or CDATA, or a document ending mid-tree is reported with a position. Nothing is auto-corrected, because a silently repaired document is not the one you had. |
Frequently asked questions
Will formatting change what my XML means?
It can, in one specific way: whitespace inside text content is data in XML, and collapsing it changes that data. That is why Collapse whitespace is a switch rather than always-on — turn it off for documents where text is whitespace-significant. Everything else is preserved exactly, including CDATA contents, comments, attribute values and the DOCTYPE.
Why does it refuse my document instead of fixing it?
Because guessing which tag you meant to close is not something a formatter can do safely. Given <a><b></a>, closing <b> for you produces a document that looks correct and has a different tree from the one you wrote. The error names the tag and the position so you can decide, which takes seconds and cannot be wrong.
Does it handle SVG, XSLT, RSS, SOAP and Android layouts?
Yes — they are all XML, and nothing here is schema-aware. SVG and XSLT in particular benefit from the attribute wrapping option, since a single element with a dozen attributes is common and unwrapped it runs well off the screen.
What about HTML?
Only XHTML-shaped HTML. Real HTML has void elements that never close (<br>, <img>), optional closing tags (<li>, <td>), and raw-text elements like <script> whose contents are not markup. This tokenizer holds a document to XML rules, so it will report an unclosed <br> as an error. That is correct for XML and wrong for HTML.
Is there a size limit?
8 MB. Formatting runs on the main thread, so above that ceiling the tool declines rather than locking the tab. Both tokenizing and formatting are iterative rather than recursive, so a deeply nested document — there is a test at five thousand levels — reports a result instead of overflowing the call stack.
Is my document uploaded?
No. It is tokenized and re-indented by JavaScript in the tab you already have open. Open the Network panel and paste one: nothing carrying it leaves. XML configuration files routinely contain connection strings, internal hostnames and credentials, which is exactly the material that should not pass through an unknown server for reformatting.