Formatters
XML Formatter
XML still runs payments, sitemaps, RSS, and Android resources. An XML formatter does not make that fashionable. It makes the tree visible so you can see why a feed closed the wrong tag.
Drop a file on the left. Drafts stay in this browser. Shortcut: Ctrl or Cmd + Enter to run.
How this xml formatter works
- Paste or drop a .xml file into the input on the left.
- Flip options if you see them (comments, indent, case). Defaults are the safe ones.
- Hit Run, or Ctrl / Cmd + Enter. Leave “Process on server” off unless you mean it.
- Read the status line, then copy, download, or jump to a related tool.
Well-formed first
Indent follows nesting. Attributes stay on their tags. If the document is not well-formed, validate first — pretty-print on broken XML is a guess. Sitemaps and SOAP envelopes are good candidates; binary-ish Office XML is not a fun paste and may be too large for a casual editor.
Frequently asked questions
What does formatting XML actually do to the file?
Formatting XML is about a stable shape: indent, wrapping, keyword casing where it helps. Example: <item><id>1</id></item> reads easier as <item>\n <id>1</id>\n</item>. It is not a linter and not a compiler.
Should I format XML before I go live, or while I edit?
Edit in a readable shape. formatting belongs to the moment the file has to be understood (beautify/format/validate) or the moment it leaves your hands (minify/encode). Mixing those moods is how minified HTML becomes your only source of truth — a sad place to live.
Can formatting XML break what I already put live?
Well-formed XML cares about nesting and one root. Beautify will not invent a schema; it only makes the tree readable. Glance at the output once. A 20-second read beats a 20-minute “why did production go weird” thread.
Got a simple before-and-after for xml formatter?
Sure. Before: <item><id>1</id></item> After: <item>\n <id>1</id>\n</item>. That is the whole mood of the tool — same job, different clothing. If your real file is huge, try a representative slice first so you can see the rule, not a wall of text.
What about comments, strings, and data that look like code?
Strings are data. 'a + b' is not math. Comments are notes — minify may drop them, beautify should keep them if the engine sees them. XML has its own trap: Well-formed XML cares about nesting and one root. Beautify will not invent a schema; it only makes the tree readable.
Any fun XML fact worth remembering?
Fun fact: XML is case-sensitive. <Item> and <item> are different tags. HTML is famously sloppy about that. Beautify will not merge them for you.
Do I still need a bundler, Prettier, or a schema tool?
For an app in git: yes — keep the project formatter and the bundler. This xml formatter is for the five-minute paste: a log line, a vendor dump, an email template, an API body. Different altitude, same mountain.
When should I not use a xml formatter?
Skip it when the file is a binary, when you need a full language compiler, or when a single sample cannot represent the format (Excel workbooks, YAML with anchors, HTML that is really a React tree). Also skip minify as your only copy of source. Keep a readable original.