XML still carries sitemaps, RSS and Atom feeds, SVG files, SOAP payloads and a long tail of configuration formats. A single unclosed tag or unquoted attribute stops the whole document from parsing, and the failure often surfaces far from the mistake. A formatter gives you two things at once: a well-formedness check and an indented view of the hierarchy. This guide explains what the local XML formatter actually does, where its tokenizer can distort unusual markup, and how to prepare a sitemap or feed for publication.
Part of the developer toolkit guide. The tool runs entirely in the page, so internal config files never leave the machine. That privacy is useful, but it also means the tool has no schema service behind it: well-formed is not the same as valid against your XSD or business rules.
What the formatter checks
The input is parsed with the browser's DOMParser using the application/xml type. If the parser reports an error, the tool shows a generic invalid-XML message and refuses to produce partial output. Failing closed matters because a half-formatted document can look plausible while hiding the exact tag that broke. The input limit is 500,000 characters, close to 500 KB; anything larger is rejected before parsing.
This is a well-formedness check, not schema validation. The parser confirms that tags close, attributes are quoted, entities resolve and there is a single document element. It does not know whether a sitemap contains the required namespace, whether an RSS item has the fields your reader expects, or whether an order element follows your XSD. Those checks need a schema-aware validator or the receiving service.
The error message does not include a line and column number. If you need the exact location, open the file in an editor with XML support or check the browser console for the parser's own diagnostic. The value of the tool is the fast pass or fail and a readable tree once the document is accepted.
What changes when you press Format
Formatting is line-oriented. The serializer first normalizes the document, then a small tokenizer walks opening tags, closing tags, declarations, comments and text. Each opening tag increases the indent by two spaces, each closing tag decreases it, and self-closing tags stay on one line. The result is easy to scan:
<rss>
<channel>
<title>Example</title>
<link>https://example.com/</link>
</channel>
</rss>
Attributes are not reformatted or wrapped. A long attribute list stays on the element's line, which is fine for IDs and namespaces but unhelpful for dozens of attributes. Indentation is cosmetic; it does not add namespace declarations or repair missing closing tags.
Two edge cases deserve attention. Text nodes are trimmed, so mixed content such as <p>Hello <b>world</b></p> loses the space before the inline element when it is placed on its own line. Do not use the pretty output for XML where whitespace inside text is significant. Second, the tokenizer looks for the next > character, so an attribute value containing a literal greater-than sign can be split incorrectly. XML permits > in a quoted attribute, although escaping it is safer. Minify mode is the better choice for such documents.
CDATA sections can also confuse the line tokenizer when they contain > or look like tags. If a document uses CDATA for embedded HTML or SQL, format a copy and compare the text content before and after. For configuration files and sitemaps without CDATA, the output is predictable.
Minify mode and signed documents
Minify serializes the parsed document and collapses whitespace between adjacent tags with a simple replacement. It does not remove comments, change attribute order or rewrite namespaces. Elements that already sit next to each other stay unchanged, so the saving depends on how much indentation the source contains. A sitemap that is already machine-generated may shrink very little.
Never minify a document covered by an XML signature. XML digital signatures can include whitespace in the signed byte stream, and changing indentation or inter-tag spaces invalidates the signature even though the logical tree is identical. The same caution applies to files compared by checksum in a deployment pipeline. Keep the canonical byte-for-byte copy and use the formatter only on a scratch copy.
Minified output is still well-formed XML and is acceptable for sitemaps and feeds. Search engines do not require pretty indentation. What they require is a successful parse, the correct namespace and content that follows the sitemap protocol.
Sitemaps, feeds and namespaces
A sitemap is a small XML document with a specific namespace, a set of <url> entries and optional metadata. The formatter preserves namespace prefixes because the serializer keeps qualified names. After formatting, check that the root still declares the sitemap namespace and that every URL is absolute. The tool cannot check either condition for you. A sitemap may parse cleanly while pointing at relative paths that crawlers ignore.
Feed files have the same shape of risk. RSS and Atom are XML, so an unescaped ampersand in a title or a raw HTML fragment in a description will break the feed. Encode the text, or wrap markup in CDATA, then validate. If the feed is generated by a CMS, compare the generated file with a known-good sample rather than editing only the pretty output.
Sitemap protocol limits are separate from the parser. A single sitemap file is capped at 50,000 URLs and 50 MB uncompressed. Large sites should split into a sitemap index. None of that is enforced here; formatting a 60,000-URL file will succeed even though the file violates the protocol. Check the limits before submitting.
Where the tool stops
| Task | Supported here | Use instead |
|---|---|---|
| Well-formedness | Yes, via the browser XML parser | Nothing else needed for a quick check |
| XSD or Relax NG validation | No | A schema validator in your build or CI |
| Line and column errors | No | An XML-aware editor or the browser console |
| Large documents | Up to 500,000 characters | Split the file or use a command-line tool |
| Mixed content whitespace | Trimmed during pretty print | Keep the source or use minify carefully |
| CDATA with angle brackets | Can be tokenized incorrectly | Compare content, or avoid pretty printing |
| Signed XML | No signature awareness | Keep the canonical bytes untouched |
The 500,000-character limit is a UI guard, not a statement about what XML can contain. Command-line parsers handle much larger files. If a sitemap is too large for the page, it is also a signal to split it, which is better for crawling and for error isolation.
A practical workflow
- Keep the original file in version control or a backup folder before pasting it anywhere.
- Format a copy first. If the tool rejects it, fix the first structural error and retry rather than rewriting the whole document.
- Inspect namespaces, the root element and the first few records after formatting.
- Check text values for accidental trimming, especially in mixed-content documents.
- Minify only if the receiving system benefits and the file is not signed or checksummed.
- Validate the final file against the protocol or schema that actually governs it before publishing.
A clean parse is necessary but not sufficient. For a sitemap, the next checks are URL count, absolute links, encoding and robots rules. For a feed, test in a reader and confirm that dates, GUIDs and enclosures survive. For a config file, deploy to staging and compare the parsed settings with the source of truth.