XML Formatter
Formats, validates and minifies XML entirely in your browser — points at the exact line and column of every error, and refuses to reindent whitespace that is actually part of your data.
Free · No signup · Nothing leaves your browser
Formats and validates XML entirely in your browser. It reports the exact line and column of every error — and it will not silently reindent an element whose whitespace is part of the data, which is something the other formatters do to you without a word.
Well-formed
Every tag is closed and correctly nested, every attribute is quoted, and no reserved character is left unescaped. Well-formedness only — validating against a schema or DTD needs the schema, which this page does not have.
Mixed content — whitespace here is data
<summary> holds both text and child elements. Indenting inside it would insert newlines and spaces into the text itself, changing what the document says — so it is reproduced exactly as you wrote it.
Most online formatters reindent these anyway. If you have ever pasted a document into one and found stray spaces in your text afterwards, this is why.
Namespaces
Used but never declared: soap: — a parser that enforces namespaces will reject this document, though many lenient ones accept it, which is why it survives so long unnoticed.
dc:→ http://purl.org/dc/elements/1.1/
Everything runs in your browser — the document is never uploaded, logged or stored. XML tends to carry customer records, invoices and API payloads, which is a good reason not to paste it into someone else's server just to add indentation.
Tekk is a spec-driven development platform for people building software with AI coding agents — for when the problem is the integration, not the indentation.
The thing other XML formatters get wrong
XML has two kinds of whitespace and they are not interchangeable.
Between elements, whitespace is insignificant — decoration for human eyes. A formatter can add, remove and rearrange it freely. That is the whole job.
Inside an element that holds both text and child elements, whitespace is data. Consider:
<summary>Height adjustable from <min>65cm</min> to <max>129cm</max>, motorised.</summary>
Pretty-print that naively and you get:
<summary>
Height adjustable from
<min>65cm</min>
to
<max>129cm</max>
, motorised.
</summary>
The sentence now contains newlines and leading spaces it did not have before. Render it and you get "Height adjustable from 65cm to 129cm , motorised." — note the space before the comma. The document no longer says what it said.
This page detects those elements and reproduces them exactly as written, then tells you which ones it left alone. Everything around them is still indented normally.
It matters most in document-shaped XML — DocBook, DITA, XHTML, RSS descriptions — and rarely in machine-generated feeds. Which is why a formatter has to detect it rather than assume.
Errors, with somewhere to look
Browsers report XML errors as a sentence inside an HTML page, worded differently in every engine. Most online formatters just say the document is invalid.
Every error here carries a line, a column, the offending source line, and what to do:
| Error | What it usually means |
|---|---|
Unescaped & in text |
A bare ampersand. Write &, or wrap the value in CDATA. Reported for every occurrence, not just the first. |
Expected </b> but found </a> |
Tags crossed rather than nested. Unlike HTML, XML has no error recovery. |
<x> was never closed |
With the line it opened on. |
| Attribute without a value | Legal in HTML (<input disabled>), never in XML. |
| Closing tag with nothing open | Usually a tag closed twice. |
Namespaces, which fail quietly
A prefix used but never declared is invalid. Lenient parsers accept it anyway, so the document works in one system and is rejected by the next — often months later, by someone who did not write it.
The panel reports three things: prefixes declared and used, prefixes declared and never used (usually a copied header), and prefixes used but never declared (the bug). The xml: prefix is bound by the specification and is never flagged.
Well-formed is not the same as valid
Well-formed is syntax: closed tags, correct nesting, quoted attributes, escaped reserved characters. It can be checked from the document alone, and that is what this page does.
Valid means it also conforms to a schema — XSD, DTD, RELAX NG. That requires the schema, and this page does not ask you for one.
Any tool that claims to validate XML without asking for a schema is checking well-formedness and using a bigger word for it.
How it works
- 1
Paste it and read the verdict
It formats as you type, with no submit button and no upload. If the document is not well-formed, this xml formatter gives you the line and column, the offending source line, and what to do about it — not the single word "invalid" that browsers and most online tools return.
- 2
Check the mixed-content warning
An element holding both text and child elements — a sentence with <em>emphasis</em> inside it — carries whitespace that is part of the data. Indenting inside it changes what the document says. Those elements are reproduced exactly as you wrote them, and you are told which ones they were.
- 3
Look at the namespace panel
Declared prefixes, which of them nothing actually used, and — the one that bites — prefixes used but never declared. Lenient parsers accept those, strict ones reject the document, which is why the bug survives so long before anyone notices.
Frequently asked questions
- Do you store or upload my XML?
- No. The parser is a few kilobytes of JavaScript that runs on your machine — there is no server call, nothing is logged and there is no account. XML tends to carry invoices, customer records and API payloads, which is a good reason not to paste it into someone else's server just to add indentation.
- What does well-formed mean, and is that the same as valid?
- No, and the difference matters. Well-formed means the syntax is right: every tag closed, correctly nested, attributes quoted, reserved characters escaped. Valid means it also matches a schema or DTD. This xml validator checks well-formedness, because validation needs the schema and you have not given it one. Any tool claiming to validate without one is checking well-formedness and calling it something grander.
- Why will it not indent some of my elements?
- Because doing so would change your data. In XML, whitespace inside an element that holds both text and child elements is significant — it is part of the text. Pretty-printing <summary>Adjustable from <min>65cm</min> upward.</summary> would insert newlines into that sentence. Most online formatters do it anyway; if you have ever pasted a document into one and found stray spaces in your text afterwards, that is what happened.
- What is mixed content?
- An element containing text and child elements together, rather than one or the other. It is normal in anything document-shaped — DocBook, XHTML, DITA, RSS descriptions — and rare in machine-generated data feeds. The distinction decides whether reformatting is safe, so this xml formatter detects it rather than guessing.
- Why does it flag a namespace prefix?
- Because using a prefix that was never declared is invalid, and lenient parsers let it through. A document with a stray soap: or dc: prefix works fine in one system and is rejected by the next, usually long after anyone remembers writing it. The panel lists what was declared, what went unused, and what was used without being declared.
- Can it handle CDATA, comments and processing instructions?
- Yes, and they are preserved rather than stripped. CDATA sections are treated as opaque by this xml formatter, so markup and ampersands inside them are data and not errors — which is exactly what CDATA is for. Comments, the XML declaration and processing instructions all survive formatting.
- Why does it say my ampersand is wrong?
- A bare & is not valid XML, even though it looks harmless. It must be written &, or the whole value wrapped in a CDATA section. It is the single most common XML error and the one parsers report worst — this xml validator names every occurrence with its line and column, not just the first one it hits.
- Does it work as an xml beautifier for minified feeds?
- That is the main use. Paste a single-line document from a log or an API response, pick 2, 4 or 8 spaces, and read it. As an xml beautifier it also goes the other way — the minify toggle strips formatting whitespace back out for a payload you are about to send.
- Is there a size limit?
- No hard cap, but the xml formatter re-parses on every keystroke, so a multi-megabyte document will feel sluggish in the textarea. For files that large, format a representative section rather than the whole thing.
- Will formatting change my document?
- Only the whitespace between elements, which XML treats as insignificant — plus the deliberate exception above, where it changes nothing at all. Attribute values are copied byte for byte, element order is preserved, and nothing is normalised, reordered or dropped. Formatting twice gives the same result as formatting once.
- Does it validate against a schema, XSD or DTD?
- No. That needs the schema itself, and this page never asks you to upload one. What it gives you is well-formedness, precise error positions, namespace consistency and the mixed-content warning — the checks that are possible from the document alone.
- Why is this free, and what is Tekk?
- Tekk is a spec-driven development platform for people building software with AI coding agents. This page costs nothing to run because nothing runs on our servers, so there is no signup wall, no run limit and no upsell inside the tool.
Want a real spec for what you’re building?
Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.
Free to try · Connect GitHub during signup