Online XML Formatter, Validator & Viewer

Using the XML Formatter

Toolbar actions

  • Format: put each element on its own line and indent the nesting.
  • Minify: collapse the whitespace between tags, leaving text content untouched.
  • Validate: check well-formedness and report the first break with its line and column.
  • Copy, Paste, Clear: move the document in and out of the clipboard, or empty the editor.
  • Upload, Export: open an .xml file, or download what is in the editor.

Tabs

Tree View nests elements so a branch can be collapsed; Grid Viewbuilds columns from the tag names and attributes it finds, with a separate table for the root element’s own attributes. Both are editable.

Format or minify XML

Paste a document and press Format to indent every element on its own line, or Minify to strip the whitespace between tags back out. Comments and processing instructions are given their own line; CDATA deliberately is not, because it is text — putting it on its own line would insert a newline and an indent into the element’s own content. Minifying a formatted document gives back exactly what minifying the original would, which is the property that keeps the two operations honest.

Validate well-formedness

Validate checks that the document is well-formed: tags match and nest, attributes are quoted and unique, names are legal, comments and CDATA are closed, and every entity reference resolves. It reports the first position that breaks, as a line and column with the reason. This is well-formedness only — it does not check a document against a schema or DTD, so a document that validates here can still be wrong for your application.

Minify never touches your text

XML preserves whitespace inside elements, so text content is left exactly as written. Minify collapses the space between tags and nothing else — an element reading a = b keeps its spaces, because collapsing them would be data loss rather than formatting. The cost of that rule is that a start tag split across several lines keeps its newlines; doing it properly needs a quote-aware scan, since a > is legal inside an attribute value.

<eq>a = b</eq> <n>1</n><eq>a = b</eq><n>1</n>

Read it as a tree or a grid

Tree view nests elements so you can collapse a branch and see the shape of the document. Grid view builds columns from the tag names and attributes it finds, which turns a repeating record structure into a table you can scan — with a separate table for the root element’s own attributes. Both are editable, and both write back to the same document.

What it gives back is what you gave it

Where the output differs from xmllint --format, it is because xmllint rewrites and this does not. The XML declaration is kept rather than dropped, a numeric character reference like &#65; stays as written rather than being expanded to A, and a > inside an attribute value is left alone rather than escaped. A formatter should hand back the document you gave it with different whitespace, not a different document.

Frequently asked questions

Is my XML uploaded to a server?

No. The page is a static export with no backend, so formatting, validation and both views run entirely in your browser. Nothing you paste leaves the tab.

Does it validate against a schema or DTD?

No. It checks well-formedness only — matching tags, quoted and unique attributes, legal names, closed comments and CDATA, resolvable references. Content models, a DOCTYPE’s internal subset and namespace constraints are not checked, so a well-formed document can still fail a schema elsewhere.

Why is the whitespace inside my elements untouched after minifying?

Because in XML that whitespace is data. Only the space between tags is collapsed. Removing spaces inside an element would silently change the content, which is a worse outcome than a slightly larger file.

Why does the output keep the XML declaration when xmllint drops it?

Because this is a formatter rather than a rewriter. It changes whitespace and leaves everything else as you wrote it — the declaration, numeric character references, and characters inside attribute values that xmllint would re-escape.

Can I edit the XML in the tree or grid view?

Yes. Both views are editable and commit to the same document, so an edit made in the grid is there in the tree and in the code editor. A leaf edited in the tree is written back as raw text rather than being retyped, which is what keeps XML content intact.