XML formatter & converter

1. Paste your XML. Drop it into the left pane, click Load file to open an .xml, .svg, or feed file from disk, or hit Sample to see the tool working on example data immediately.
2. Pick an action. Choose Format to pretty-print, Minify to strip whitespace, XML → JSON to convert to JSON, or JSON → XML for the reverse direction. For Format and the converters you can also choose the indent: 2 spaces, 4 spaces, or tabs.
3. Read the result. The output pane updates automatically about a third of a second after you stop typing. If the input isn't valid, a plain-English error appears instead, including the line number reported by the parser.
4. Copy or download. Use the Copy button next to the output, or download the result as an .xml or .json file, depending on the action.

There's no convert button and no page reload — every keystroke, action switch, and indent change re-runs the conversion live.

Format parses your document into a DOM tree and re-serializes it with one element per line, children indented one level deeper — the classic XML beautifier output that makes structure obvious. Attributes stay on their element, empty elements collapse to the self-closing form, comments and CDATA sections are preserved, and elements that contain text (or a mix of text and inline elements) stay on a single line so the formatter never invents whitespace inside your actual content. If the document starts with an XML declaration, it's kept at the top.

Minify is the same walk in reverse: it drops the whitespace that only exists for human eyes — indentation and line breaks between elements — while leaving text content intact. Minified XML is smaller to store and transmit, which matters for payloads sent on every request. The savings are shown in the status bar as bytes in versus bytes out, so you can see exactly what the whitespace was costing. One honest caveat: in XML, whitespace inside mixed content can be meaningful, so the minifier collapses runs of whitespace in text to a single space rather than deleting them outright.

XML and JSON model data differently — XML has attributes, text, and repeated elements; JSON has objects, arrays, and values — so any XML to JSON converter has to pick a convention. This tool uses the widely adopted one, and applies it predictably:

Values are kept as strings rather than guessed into numbers or booleans — "13.99" stays a string — because silently converting "007" to 7 or a postal code to a number is exactly the kind of surprise a converter shouldn't spring on you. Once converted, the JSON formatter can validate, re-indent, or minify the result further.

JSON to XML applies the same convention backwards: keys starting with @ become attributes, a #text key becomes the element's text content, arrays become repeated sibling elements, and ordinary keys become child elements. The JSON is validated first — if it doesn't parse, you get the JavaScript engine's error message translated into a line and column instead of a silent failure. If the JSON has a single top-level key, that key becomes the XML root element; otherwise the output is wrapped in a <root> element, since XML requires exactly one root.

Two details worth knowing. JSON keys that aren't legal XML names (spaces, leading digits, symbols) are sanitized — invalid characters become underscores — because <first name> simply isn't parseable XML. And round-tripping is faithful for data that fits the convention: convert the sample XML to JSON and back, and you get equivalent markup. Data that only exists in one model — comments, processing instructions, attribute order — is where any converter, this one included, has to make choices.

When parsing fails, the tool surfaces the browser parser's own diagnosis, including the line and column it points at. The usual suspects, in rough order of frequency:

• Unescaped ampersands. A bare & in text or a URL must be written as & — this is the single most common reason a feed or config “suddenly” stops parsing.
• Mismatched or unclosed tags. Every element needs a closing tag (or a self-closing slash), and closing tags must match opening tags exactly — XML is case-sensitive, so an opening <Item> closed by </item> is an error.
• Multiple root elements. A document must have exactly one top-level element; two siblings at the top level make it invalid (a common result of concatenating files).
• Unquoted attribute values — id=5 must be id="5" — and stray characters before the XML declaration, like a BOM or leading whitespace from a copy-paste.

Because validation re-runs on every keystroke, the moment you fix the reported line the error box flips to the green “Valid XML” status with an element count — a fast loop for cleaning up a broken file.

JSON has won the API-payload war, but XML remains everywhere real systems live: RSS and Atom feeds, XML sitemaps, SVG images, Maven and NuGet configs, Android layouts, SOAP services, invoice standards like UBL, and decades of enterprise integrations. XML's strengths — attributes, namespaces, comments, schema validation, mixed text-and-markup content — matter in documents; JSON's strengths — direct mapping to objects and arrays, less syntax, native browser support — matter in APIs. Which is exactly why converting between them is such a routine chore: a JavaScript service needs to consume a legacy SOAP response, or a sitemap needs to become JSON for a build script. This json to xml and XML-to-JSON pair exists for that boundary. If your pipeline speaks YAML instead, the YAML to JSON converter covers that hop.

Format mode doubles as an XML viewer online: paste a minified RSS feed, a sitemap downloaded from a CMS, an SVG file, or an API response, and the indented output makes the structure readable enough to actually navigate. The status bar confirms the document is well-formed and reports how many elements it contains — a quick sanity check before you feed a sitemap to a search console or debug why a feed reader rejects your RSS. Because the output pane scrolls horizontally rather than wrapping, deeply nested documents keep their indentation intact instead of turning into visual soup.

Yes. Parsing uses DOMParser, the XML engine built into your browser, and the formatter, minifier, and converters are small JavaScript routines running in this tab. Your XML and JSON are never attached to a network request, never logged, and never stored — which matters, because config files and API payloads routinely contain endpoints, credentials, and customer data that have no business passing through a random formatting server. It also means the tool works offline and has no size cap beyond your device's memory.

• Backend developers debugging SOAP responses, Spring configs, and legacy integrations.
• SEO specialists inspecting XML sitemaps and RSS feeds before submitting them.
• Android developers tidying layout and manifest files outside the IDE.
• Data engineers converting XML exports to JSON for pipelines that only speak JSON.
• Ops & support teams reading vendor XML payloads to answer “what did their system actually send us?”

Working with other developer formats too? The SQL formatter and JSON to TypeScript generator live in the same toolbox.