What this tool does
This is an XML formatter, viewer and well-formedness validator in a single page. Paste XML of any shape — a SOAP envelope, an RSS feed, a sitemap, a configuration file, an invoice in one of the UBL dialects — press Format, and the document is parsed, checked and laid out as an indented, collapsible tree. Element names, attribute names, attribute values, comments and CDATA sections are coloured differently, every element reports how many children it holds, and each branch folds away so a long document can be read one level at a time.
Formatting and validating are the same operation seen from two sides. To beautify a document you must first parse it, and parsing is precisely what a validator does; if the text cannot be parsed there is nothing to indent, and the parser message is the validation result. One button therefore does both: it will convert a minified blob into human readable output when the markup is sound, and tell you where it broke when it is not.
Each result appears above the one before it, so two payloads can be compared without losing the first. Results can be removed one at a time or cleared all at once, and nothing survives a refresh.
Formatter, beautifier, validator, viewer
Four words circulate for tools of this kind, and they name four different things people want from one.
A formatter re-prints the document with consistent whitespace: one element per line, a fixed indent per level of nesting, a predictable place for every angle bracket. Beautify is the older word for the same operation, carried over from the JavaScript tooling world — a beautifier and a formatter are the same tool under two labels. Neither alters your data, only where the line breaks fall.
A validator answers a yes-or-no question about the text. In XML that question splits in two, which is the single most useful thing to understand about the format, and the next chapter is about the difference. This page answers the first half: is the document well-formed.
A viewer goes further than a formatter. Instead of printing text it turns the parsed document into something you can operate: fold a repeating branch shut, see how many children an element holds, walk into a nested structure without counting closing tags by eye. Formatted text beats minified text, and a tree beats formatted text the moment the document is taller than the screen.
This page is all four at once. Input is validated for well-formedness, formatted, beautified and rendered as a human readable tree, and the Copy button returns the beautified text with two-space indentation if plain text was what you needed.
Well-formed is not the same as valid
XML draws a line that JSON has no need for. A document is well-formed when it obeys the syntax of the language: one root element, every open tag closed, tags nested rather than overlapped, attribute values quoted, reserved characters escaped, a single consistent encoding. A document is valid when, in addition, it matches a schema — a DTD, an XSD, a RELAX NG grammar — that says which elements may appear, in what order, how often, and what may go inside them.
This page checks the first. It uses your browser parser, which is the same strict XML parser your browser applies to feeds and stylesheets, so anything it accepts is well-formed by definition. It does not fetch or apply a schema, and deliberately so: doing that would mean requesting the schema over the network, which conflicts with the promise that nothing here leaves your machine.
The practical consequence is worth stating plainly. If this tool reports no error, your XML is syntactically sound — but an element in the wrong order, a missing mandatory field or a date where a number was expected will still be rejected by the system you are sending it to. That rejection is a schema failure, not a syntax failure, and it needs a schema-aware validator to diagnose. Roughly speaking: use this page to answer "is my XML broken", and a schema validator to answer "is my XML acceptable here".
Your XML never leaves your browser
Nothing you paste here becomes a network request. The text you paste is parsed by your own browser, rendered into the page and held in memory only — nothing is posted to a server, written to a cookie or saved in local storage. Refreshing clears every result, and closing the tab disposes of the data.
That matters more for XML than for most formats, because of who still uses it. XML is the language of invoices, payroll exports, insurance claims, banking messages, health records and government filings. A single pasted SOAP envelope can carry a national identity number, a bank account, a salary and a diagnosis code, often all four at once. A formatter that uploads its input has quietly turned a debugging step into a cross-border data transfer, and in a regulated environment that transfer is something you would have to document and justify.
The promise is only worth making if the code keeps it, so check it: open your network tab, paste a document and press Format. The page load carries the same analytics beacon as every other page here — a URL and a page title — and formatting adds nothing to it, whatever the document contains. Disconnect from the network entirely and the tool still works, because there was never anything on the other end to talk to.
Reading the parser error
When the document is not well-formed nothing is rendered and the parser message is shown as-is, normally naming a line and column. Treat that position as where parsing failed rather than where the mistake is. The two coincide for a stray character, but an unclosed element is only detected when a later closing tag fails to match, which can be hundreds of lines further down.
A handful of causes account for most failures. Mismatched or overlapping tags, where markup that a browser would forgive in HTML is fatal in XML. Unescaped reserved characters — a bare ampersand in a URL inside a text node is the classic one, and it needs to be written as an entity or wrapped in CDATA. Unquoted attribute values, legal in HTML, never legal here. An undeclared entity, since XML knows only five by name and anything else has to be declared or written as a numeric reference. More than one root element, which happens whenever two responses are concatenated into a single file.
Encoding causes a quieter class of failure. If the declaration says UTF-8 and the bytes are Latin-1, the first accented character will break the parse with a message about an invalid byte sequence, which reads as a syntax error but is really a file that was saved in the wrong encoding. A byte order mark in front of the declaration produces a similarly confusing complaint about content before the prolog.
Namespaces, attributes and whitespace
Namespaces are the part of XML that surprises people arriving from JSON. A prefix such as soap: or xsi: is not part of the element name; it is a pointer to a URI declared with xmlns somewhere above it. Two documents that look completely different can be the same document with different prefixes, and two that look identical can differ if their prefixes are bound to different URIs. This viewer shows names exactly as written, prefix included, so you see the document rather than an interpretation of it.
Attributes and child elements are the other perennial argument. XML lets you model the same fact either way, and there is no rule that settles it — attributes suit small, single-valued metadata such as an identifier or a unit, while anything that might repeat, grow or need its own children belongs in an element. Reading a formatted tree makes an inconsistent choice visible immediately, which is usually the moment people notice it.
Whitespace deserves one warning. In XML, whitespace inside an element is content: the parser keeps it, and it can matter. This viewer hides whitespace-only text nodes so the structure stays readable, and prints an element containing a single text node on one line. That is a presentation decision, and the Copy button reproduces it — so if you are working with a format where leading spaces inside a text node are significant, copy from your original rather than from the beautified output.
A worked example
Take a small order document: a root order with an identifier, a nested customer, a list of two items each carrying a price, a comment and an empty element. Minified it is one line of roughly three hundred characters, and answering "how many items are on this order" means counting tags.
Formatted, the header reports the root element and how many descendants it holds, the items branch announces two children, and the empty notes element is shown self-closing rather than as an opening and closing pair — a distinction that decides whether a field was sent empty or not sent at all. Fold the customer away and the whole order fits in six lines. Press "Load a sample" to see exactly that document rendered.
No. Nothing you paste is transmitted: parsing and rendering happen in your browser, and the result exists only in the page in front of you. There is no cookie, no local storage and no logging of what you paste, which is also why a refresh empties the results.
No. It checks well-formedness — the syntax of the document — and not conformance to a schema. Applying a schema means fetching and processing it, which would mean sending your document or your schema somewhere, and this page is built not to. Use a schema-aware validator in your own toolchain for that half of the job.
Yes. Both mean re-printing the document with indentation and line breaks so a person can read it; beautify is simply the older word. Neither reorders elements nor alters values. What this page adds is the viewer: a collapsible tree instead of a block of text, plus a Copy button that hands back the beautified markup with two-space indentation.
Because in XML an ampersand starts an entity reference. A bare "&" in a text node or an attribute value — most often inside a query string — has to be written as & or the surrounding text wrapped in a CDATA section. The same applies to a less-than sign, which must be <.
Comfortably a few megabytes on a normal machine. The ceiling is your browser memory and the time it takes to build the tree, not a server quota, because there is no server involved. Large documents read better collapsed: use "Collapse all", then open only the branch you are investigating.
Only its presentation. The document is parsed and re-rendered, which normalises whitespace between elements and prints empty elements in self-closing form, but no element is reordered and no value is altered. Whitespace inside a text node is the one thing to be careful with, since this view trims it for readability.
No — this page converts XML into a human readable tree and back into beautified XML text, and nothing else. A faithful conversion to JSON has to decide what happens to attributes, namespaces, mixed content and repeated elements, and those decisions belong to your data rather than to a generic tool.
Once the page has loaded, yes. Formatting and validating use the parser built into your browser, so you can disconnect and keep working. That is the practical proof of the privacy claim: a tool that still functions with the network off cannot be sending anything anywhere.