XML Formatter_
Paste XML and read it: pretty-printed with your indent, minified for payloads, or explored as a collapsible tree. Malformed input is refused with the line, the column, and what was expected — never silently "repaired" into something you didn't write. Comments, CDATA, processing instructions, and the declaration pass through verbatim.
Everything runs in this tab: configs, invoices, and API responses never leave your browser. Mixed content — text and tags interleaved — is never reflowed, because in XML that whitespace can be meaning, not decoration.
- Input
- XML in any state — one endless machine-written line, a SOAP envelope, a JUnit report, a config file, or something that is not quite well-formed yet.
- Output
- The same document re-indented at your chosen width, minified to one line, or shown as a collapsible tree.
- Processing
- Scanned in this tab. Element names, attribute quoting, entity syntax, namespace prefixes and tag nesting are all checked before anything is reformatted. Documents under 256 KB re-format on every keystroke; larger ones wait until you stop typing, because the parse is synchronous and a megabyte of it would block the tab. Auto-format can be switched off entirely.
- Limits
- Malformed input is refused rather than tidied. Reformatting around damage produces a document that looks fixed and is not, which is the more expensive of the two outcomes.
- Well-formed is not valid
- This page checks the first: that the syntax holds together. Whether the document obeys a schema or DTD is a separate question needing that schema, and no formatter can answer it from the file alone.
An XML formatter that refuses instead of guessing
What an XML formatter is — and what this one runs
An XML formatter takes machine-generated XML — usually one endless line — and re-indents it so the structure is readable. Beautifier, pretty-printer and formatter all name that same operation; the word varies by tool and nothing else does. The same parse that enables formatting doubles as a well-formedness checker. This page runs a strict scanner on every keystroke: element names, attribute quoting, entity syntax, namespace prefixes, and tag nesting are verified, and the first violation is reported with its exact position. As a cross-check, the browser's own DOMParser parses the input too, and the tool refuses if either parser objects — browser parsers quietly tolerate some malformed input, and a formatter that "fixes" your document behind your back has changed your data.
How the pretty-printer decides
Elements whose children are all elements get block layout: open tag, children indented one level, closing tag aligned. An element holding only text stays on one line — <price>14.50</price> shouldn't take three. Long opening tags can wrap one attribute per line with Wrap attrs, turning a 200-character tag into a readable column with line-based diffs. Everything that isn't structure passes through byte-for-byte: declaration, DOCTYPE, comments, CDATA, processing instructions, entity references, and your original quote style. The formatter rearranges whitespace between elements — nothing else.
Whitespace, mixed content, and the preserve toggle
In XML, whitespace inside an element is real character data. For data-oriented documents (configs, feeds, SOAP payloads) the whitespace between elements is indentation noise, and collapsing it is exactly what "format" means — so that is the default. But once text and elements sit side by side inside the same parent — mixed content — <p>renew by <b>Friday</b> at noon</p> — the spaces around <b> are part of the sentence, and reflowing them changes the document. Any element containing visible text is therefore serialized inline and untouched, always — no option to get it wrong. The Preserve whitespace toggle goes further: with it on, every text node passes through verbatim and only pure element scaffolding is re-indented.
Well-formed is not valid — this page checks the first
XML has two levels of "correct". Well-formed means the syntax holds: every tag closes, attributes are quoted, entities are declared, one root element. Valid means a schema (XSD or DTD) confirms the right elements in the right places with the right types — a contract check against a second document. This page is a well-formedness checker and formatter; it does not fetch or evaluate schemas, and says so rather than pretending. Every major formatter site draws the same line — their schema validators are separate tools, usually server-side. For XSD validation use your toolchain (xmllint, your IDE) — and format here first, because a validator's errors are far easier to read on indented input.
Formatting XML inside the editor you already have
Plenty of people looking for an XML formatter never wanted a website at all — the editor already open on the other monitor will do it. In VS Code the built-in formatter handles XML once a language extension is installed — Shift+Alt+F on Windows, Shift+Option+F on a Mac. Notepad++ needs the XML Tools plugin from its Plugins Admin, which adds Pretty Print to the menu. IntelliJ and Eclipse both format XML out of the box with their reformat-code shortcut. A page still wins on the thing an editor will not do: it refuses malformed input outright and tells you which character broke it, rather than reformatting around the damage and leaving you to find it later.
Paste it, set the indent, read the first error
- 01Paste XML, or Upload a file — this free XML formatter tool reads it in your browser; nothing is sent anywhere. Checking runs live: broken input shows the line, column, and what was expected, with a caret under the exact character.
- 02Choose an indent width — two spaces, four, or tab — and switch on Wrap attrs when long tags should list one attribute per line. Preserve whitespace is there for documents where the gaps themselves matter.
- 03Format pretty-prints; Minify strips inter-element whitespace down to one line for payloads and embedding. Mixed content survives both untouched.
- 04Read structure in the Tree view — every element with its attribute count and first text — then copy the output or save it as an .xml download.
Four documents, and what the formatter does to each
One-line API response, readable
A SOAP or REST-XML response arrives as one line; formatted, the structure is obvious — the Sample button loads this shape.
<catalog><product id="P-101"><name>Trail Mug</name><price currency="EUR">14.50</price></product></catalog>
<catalog>
<product id="P-101">
<name>Trail Mug</name>
<price currency="EUR">14.50</price>
</product>
</catalog>Stable indent before a commit
Two colleagues' editors indent a config differently; normalizing both sides makes the real change visible in the diff.
format both versions here → same indent rules → diff shows only the value change
pom.xml / .csproj / app.config diffs stop showing 400 whitespace lines
Minify for a payload
An XML body embedded in a request or env var should not carry kilobytes of indentation.
<order> <sku>A-7</sku> <qty>2</qty> </order>
<order><sku>A-7</sku><qty>2</qty></order>
Find the element that matters
A 900-line invoice document hides one total; the tree view shows the skeleton with attribute counts and first text.
invoice [3 attrs] ├ header ├ lines │ ├ line [2 attrs] … └ totals — "1,204.00"
the path to <totals> without reading a single closing tag
XML syntax cheat sheet
| Construct | Syntax | Notes |
|---|---|---|
| Declaration | <?xml version="1.0" encoding="UTF-8"?> | Optional; if present, must be the very first bytes |
| Element | <name>…</name> · <name/> | Case-sensitive; exactly one root element per document |
| Attribute | name="value" or name='value' | Always quoted; no duplicates on one element |
| Namespace | xmlns:p="urn:…" then <p:item> | The prefix is a local alias — the URI is the identity |
| CDATA | <![CDATA[ raw < & text ]]> | Text taken literally until ]]> — no entities needed inside |
| Comment | <!-- note --> | No -- inside; not allowed within tags |
| Processing instruction | <?target data?> | Instructions for consuming software (e.g. xml-stylesheet) |
| Predefined entities | < > & ' " | The only five named entities XML defines without a DTD |
| Numeric entities | A · 😀 | Any Unicode code point, decimal or hex |
Everything else people call XML — unquoted attributes, unclosed tags, case-insensitive names — is HTML habit; the checker above names it when it appears.
Not well-formed → the fix
| Broken | Why it fails | Fix |
|---|---|---|
Q&A in text | Bare & must start an entity | Write Q&A |
a < b in text | Raw < opens a tag | Write a < b (or CDATA) |
<a><b></a> | Tags must nest — <b> is still open | Close inner first: </b></a> |
<img src=logo.png> | Unquoted value + unclosed element | <img src="logo.png"/> |
<a id="1" id="2"> | Duplicate attribute | One id per element |
<a/><b/> at top level | Two roots | Wrap in a single root element |
<p:x> without xmlns:p | Prefix never declared | Add xmlns:p="urn:…" in scope |
<2024-report> | Names can’t start with a digit | Start with a letter or underscore |
| Not one of the five predefined entities | Use   or declare it in a DTD |
Nine failures cover most broken XML — and the first two dominate: unescaped ampersands and angle brackets in text.
Habits that keep a document diffable
- Format before you debug: schema validators, XPath, and parsers all report positions that are far easier to find in indented XML.
- Normalize both sides before diffing: run old and new through the same indent settings, then diff — only real changes remain.
- Use Wrap attrs on documents with long tags (SVG, SOAP headers, Spring configs) — attribute-per-line turns tag soup into a scannable column.
- Keep CDATA for text full of & and < — escaping every character of embedded HTML or code is where hand-edited XML usually breaks.
- Turn on Preserve whitespace before formatting anything with pre-formatted text — if the gaps carry meaning, the default collapse is not what you want.
- Minify for transport, never for storage: a minified config parses identically, but the next human will just format it again.
Where reformatting changes what the document says
Well-formed is not valid
This page proves syntax, not vocabulary. A well-formed purchase order with the quantity in the wrong element sails through every formatter — only schema validation (XSD/DTD, in your toolchain) checks the contract. "Formats cleanly" is necessary, never sufficient.
Reformatting can change meaning
Whitespace inside elements is character data. In data XML it is ignorable indentation; in mixed content it is part of the text. This tool protects mixed content unconditionally and offers Preserve whitespace for the rest — but any formatter that reflows text nodes has edited your document, not beautified it.
The ampersand is the #1 breaker
URLs with query strings, company names like AT&T, SQL fragments — any bare & in text makes the whole document malformed, and the error may point far from the cause. When a feed breaks on "entity" errors, search for & first, then raw <.
The prefix is not the namespace
xmlns:m="urn:media" makes m: an alias for the URI — the URI is the identity. Two documents can use different prefixes for the same namespace, or the same prefix for different URIs. Compare URIs, never prefixes, and remember a prefix must be declared in scope before use.
The encoding declaration can lie
encoding="ISO-8859-1" describes the bytes the document claims to be — but pasted text is already decoded, and this page keeps the declaration verbatim without re-encoding anything. If accented characters look wrong, the file was read with the wrong charset before it reached any formatter; fix the read, not the declaration.
Server-side formatters see your documents
Invoices, medical exports, configs with connection strings — several popular formatter sites POST your paste to their servers. This page cannot: opening a connection is not something its code is allowed to do, and the build fails if that ever stops being true. For proprietary XML, that difference is the whole decision.
Scanner, indent rules, and the limits
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Checking
- Strict well-formedness scanner (tags, nesting, quoting, entities, namespace prefixes, single root) + DOMParser parsererror cross-check — refuses rather than repairs
- Errors
- Every rejection names the line, the column and what was expected, with a caret under the offending character. That includes the browser cross-check, whose own wording differs by engine and is reformatted into this shape rather than passed through
- Verbatim
- XML declaration, DOCTYPE, comments, CDATA, processing instructions, entity references, and attribute quote style pass through untouched
- Mixed content
- Elements containing visible text are serialized inline, always — the preserve-whitespace toggle extends this to whitespace-only nodes
- Options
- Indent 2 / 4 / tab; attribute-per-line wrapping (3+ attributes or tags over 80 chars); preserve whitespace; minify
- Entities
- The five predefined and numeric character references; DTD-declared entities are not resolved (reported as undeclared)
- Limits
- Input is refused above 4 MB. Between 256 KB and there, formatting waits for a pause in typing rather than running on every keystroke — a synchronous parse of a megabyte blocks the tab for seconds, and pretending otherwise made the tool unusable on exactly the documents it was built for. Nesting is capped at 500 levels, which is far past anything real and far below where the serialiser runs out of stack. The output pane stops drawing past 300,000 characters. Copy and Download are unaffected and always carry the complete result.
- Processing
- Parsing, formatting, upload reading, and download generation all happen in your browser — documents are never transmitted
Questions about formatting and checking XML
What is an XML formatter?
A tool that re-indents XML so humans can read what machines emitted on one line — and, because it must parse to do that, checks the syntax on the way. This one formats, minifies, shows a tree, and reports the first violation with its line and column.
Does this validate against an XSD or DTD schema?
No, and it says so rather than blurring the line: this is a well-formedness checker. Schema validation compares your document to a second contract document and belongs to xmllint, your IDE, or your build. Every major formatter site draws the same boundary — their XSD validators are separate tools.
Why refuse malformed XML instead of fixing it?
Because a guessed fix is silent data corruption. Browsers’ lenient parsers will happily "repair" some broken input into something the author never meant. This tool tells you exactly where the document breaks and what was expected — you make the fix, because only you know the intent.
Can I format HTML here?
Only if it is XHTML — genuinely well-formed. Regular HTML allows unclosed tags (li, br), unquoted attributes, and case-insensitive names, all of which this checker correctly rejects. A dedicated HTML formatter is the right tool for web markup.
Is the document I format here sent anywhere?
No — a fair question for XML in particular, since so much of it is SOAP traffic and configuration files carrying real endpoints and credentials. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.
What is the size limit?
Multi-megabyte documents parse and format in a few seconds. Above roughly 300k characters the output pane truncates what it displays, with a note saying so — Copy and Download always carry the complete result.