XML Formatter & Validator

Where You Still Find XML Today

You might think JSON has taken over, but XML still shows up in some important places. Public data is a big one. Many government open APIs, for example, default to XML. Sometimes you can request JSON with a special parameter, but other times XML is the only option. Anyone who's integrated with APIs for weather forecasts, business registration lookups, or official address data has probably run into this.

• Public Data Open API responses — They often come as a single, minified line. Pasting and formatting here lets you instantly see where the resultCode and resultMsg are.
• RSS & Atom feeds — Blog and news feeds are still XML. If your feed reader won't parse a feed, check its syntax here first.
• SVG — Vector images are just XML. Formatting them lets you visually trace which path belongs to which group.
• Sitemaps (sitemap.xml) — Used for syntax validation before submitting to search engines.
• E-invoices, EDI, and various industry-standard documents — Many domains still have schemas defined in XML.

When Errors Occur: The 5 Most Common Causes

Validation is performed by the browser's built-in XML parser (DOMParser). The tool displays the line and column number provided by the parser and explains the cause in plain English. In almost all cases, the error is one of these five:

• Using & literally — In XML, & starts an entity. If you put a URL querystring like `?a=1&b=2` in a value, it will break right there. You must use `&` or wrap the content in a CDATA section.
• Mismatched case in tag names — `<Title>Notice</title>` is an error. Unlike HTML, XML is case-sensitive.
• Unclosed empty tags — HTML habits like `<br>` or `<img src="…">` will cause errors. Empty tags must be closed, like `<br/>`.
• Using HTML-only entities — Entities like `&nbsp;` or `&copy;` are not defined in XML. Use numeric character references like `&#160;` and `&#169;` instead.
• More than one root element — This error happens if you paste two responses together. An XML document must have only one top-level element.

Namespaces: Prefixes Are Aliases, Not Names

XML namespaces are a mechanism to prevent name collisions when elements from different sources are mixed in a single document. Examples include RSS feeds that mix `<dc:creator>` and `<content:encoded>` tags, or government forms that combine multiple schemas.

Here's a common point of confusion: it's the URI that defines the element's identity, not the prefix (like `dc:`). The prefix is just an alias. If you change the `xmlns:dc="…"` declaration at the root, the same `dc:creator` tag takes on a different meaning. For this reason, this tool preserves prefixes and their declarations exactly as they are in the original. Normalizing them arbitrarily could change the document's semantics.

• `xmlns` declarations look like attributes, but you must not delete them. The moment you do, you'll get an "undeclared prefix" error.
• A default namespace (`xmlns` without a prefix) applies to that element and all its descendants. If you copy and paste a fragment, the declaration might not come with it, changing the meaning of the elements.
• Attribute order is also preserved. While the XML standard says attribute order is not significant, it is significant to a human running a `diff` against the original file.

CDATA: When to Use It and What to Watch For

A CDATA section is a block that says, "Don't interpret this as markup; read it as literal text." A classic use case is embedding an HTML body inside an RSS feed's `description` tag. Without it, you'd have to escape every `<` and `&` in the body, resulting in an unreadable string.

• You cannot include the string `]]>` inside a CDATA section, as it marks the end of the section. If your content must contain this sequence, the common workaround is to split the CDATA section in two.
• CDATA only prevents parsing; it is not a security feature. If you inject HTML wrapped in CDATA directly into your page, any XSS vulnerabilities will pass right through.
• This tool preserves CDATA, comments, processing instructions, and DOCTYPE from the original document. If you uncheck "Keep comments", comments will be removed from the output.

<!-- Escaped: hard to read -->
<description>&lt;p&gt;Today &amp; Tomorrow&lt;/p&gt;</description>

<!-- With CDATA: original text remains readable -->
<description><![CDATA[<p>Today & Tomorrow</p>]]></description>

Formatting Integrity and External Entities

The formatter only cleans up insignificant whitespace between elements. For elements with mixed content (text mixed with child elements), it keeps everything on a single line without adding line breaks. In an element like `<p>Hello <b>John Doe</b></p>`, the space after "Hello" is data. Pretty-printing it with indentation would change the rendered output.

The "Collapse empty tags" option converts empty elements from `<tag></tag>` to the self-closing form `<tag/>`. In the XML standard, these two are completely identical. However, if you're dealing with a legacy system that inspects the XML with simple string comparisons, it's safer to leave this option unchecked.

External entities (XXE) are not processed. The browser's built-in `DOMParser` does not fetch external DTDs or entities, so no network requests are made even if `SYSTEM` entity declarations are present in the document. However, this only means the tool itself is safe. It does *not* mean the same file is safe to feed into your server-side XML parser. Server-side parsers must be explicitly configured to disable external entities.