Format, validate, convert, and explore XML in seconds.
Thirty-two browser-based XML tools for the awkward parts of the job — pretty-printing, validating, diffing, and converting to and from the formats you actually use. Everything runs in your browser, nothing uploaded. XML is still the lingua franca of B2B / EDI, SOAP, RSS / Atom feeds, Spring / Maven configs, and the inside of every Office file (XLSX, DOCX, PPTX) — so these tools keep coming in handy long after the format went out of fashion.
Converting between formats
Most XML you'll meet in 2026 is something else in disguise — an enterprise system spits out
XML that the consumer wants as JSON, or a frontend
ships JSON that some legacy SOAP endpoint demands as XML.
The converters round-trip cleanly for the common shapes: attributes are preserved (or hidden,
your choice), repeating elements collapse into arrays, and CDATA sections are kept as text.
For tabular XML — anything that looks like <rows><row>...</row></rows> —
the XML to CSV tool flattens the repeating element
into a CSV (or TSV, with \t as delimiter) so it lands in a spreadsheet without a
detour.
When the document will not parse
The most common XML emergency is a file that a parser refuses outright. The
repair tool handles the usual culprits: a bare
& that should have been &, HTML-only entities like
that XML never defined, unclosed tags from a truncated export, unquoted
attribute values copied out of HTML, curly quotes from a word processor, and concatenated
fragments that leave the file with two root elements. Every change is listed, so you can see
what was rewritten before trusting the result — and the last line tells you whether the
document now parses.
Namespaces are the other reliable source of frustration. A SOAP envelope or an Office part is
full of prefixes, and a plain XPath expression silently matches nothing when a default
namespace is in play. The
namespace remover strips prefixes and
xmlns declarations so //soap:Body/ns2:result becomes
//Body/result and the XPath tester behaves the way you
expected in the first place.
Reading a document you did not write
For an unfamiliar file, XML Stats answers the shape question in one click: how many elements, which names repeat (that top entry is almost always the record element), how deep the nesting goes, and which namespaces are in play. Then the tree viewer lets you browse it as collapsible nodes with a filter that keeps only the branches matching a name, a value, or an attribute — which is how you find where a value lives without writing an XPath first. Going the other way, XSD to sample XML generates a skeleton instance from a schema, so you can see what a service actually expects to receive.
XML nobody calls XML
Three formats bring people here without the letters X-M-L in the request.
Sitemaps are XML, and the mistakes that cost
traffic — a wrong namespace, a lastmod that is not W3C format, URLs on the wrong
host — are all document-level and checkable before a crawler ever sees the file; the
generator builds a valid one from a plain list
of URLs. Feeds are XML too, in three mutually
annoying flavours, and get normalised into one JSON shape here. And an Apple
property list is XML with a peculiar flat
key/value structure that generic converters mangle — this one pairs the keys correctly.
Looking at an XML
Sometimes you just want to read the file. The formatter pretty-prints minified payloads — the sort of single-line SOAP envelope or signed XML blob you can't make sense of in a terminal. The validator tells you whether the document is well-formed and points at the first parse error with a line and column. The schema validator checks an XML against an XSD — element structure and simple-type values — useful for sanity-checking what an EDI partner sent you before the downstream parser blows up.
Diffing two XMLs
Plain diff hates XML — a one-character whitespace change reshuffles the line breaks
and you get a screenful of false positives. The
diff tool compares the two documents as trees and reports
each change where it happens (~ /catalog/book[2]/@price "19.95" → "21.50"),
matching children by name and identifier so one inserted element does not shift everything after
it. A unified line diff is still there as a second mode. When the question is whether two files
are byte-identical once the free choices are settled, the
canonicalizer answers it: C14N 1.0 inclusive or
exclusive, plus the SHA-256 DigestValue an XML signature is built on.
Searching and transforming
The XPath tester runs XPath 1.0 against your
document via the browser's native document.evaluate — match nodes, evaluate
string / number expressions, see exactly what your selector picks up before pasting it into
production code. The XSLT tester uses the native
XSLTProcessor to apply a stylesheet — handy for one-off transforms when reaching
for xsltproc on the CLI feels like overkill.
What they have in common
Everything runs in your browser. The files you drop or paste never leave your machine — there is no server component handling data. I can't see your envelopes because they were never sent to me. That means no size cap beyond your browser's memory, no account required, and nothing for me to leak. See the privacy policy for the longer version.
Sensible defaults, no hidden magic. Validation uses the same
DOMParser every browser ships, so the well-formedness errors match what your
runtime would say. Conversion preserves CDATA, comments, and processing instructions
unless you explicitly ask otherwise. The status bar tells you what was picked.
Free to use, with no warranty. Read the terms of use before relying on the output for anything load-bearing. Bug reports, corrections, and feature requests are always welcome — drop me a line.
— S., [email protected]