Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Pretty-print (indent) or minify XML markup.
<root>
<item id="1">First</item>
<item id="2">Second</item>
</root>This tool pretty-prints XML -- indenting nested elements onto their own lines for readability -- or minifies formatted XML by stripping whitespace between tags, useful before pasting XML into a size-constrained field or API payload.
Paste XML and choose Pretty-print or Minify. The result updates instantly, with proper indentation reflecting the actual element nesting depth.
The formatter tokenizes the XML on tag boundaries and tracks nesting depth as it walks through open and close tags, indenting each line to match. A leaf element containing only text (like <name>Ada</name>) stays on one line rather than needlessly breaking its text content onto a separate line.
To convert XML into JSON instead, see the XML to JSON Converter. For HTML specifically, use the HTML Beautifier.
Suppose you paste a hypothetical single-line document: a root element called library that holds two book elements, each with a title and an author. In Pretty-print mode the root tag sits on the first line with no indent, each book tag is indented one level, and the title and author lines sit one level deeper. Because each title element holds only text, its opening tag, text and closing tag remain together on one line. The default indent step is two spaces per level. In Minify mode the same document collapses back into one continuous string, because the tool removes any whitespace that sits between a closing bracket and the next opening bracket.
Minifying only removes whitespace that lies between two tags. Whitespace inside an element's text, for instance the spaces between words in a paragraph, is left alone, since it may be meaningful data. One consequence is that if your source has text placed next to a tag with line breaks around it, the outer whitespace between a tag and the text is not stripped by the between-tags rule and may remain. Minifying is a good way to reduce a payload for an API request or a configuration field with a character limit, but it does not compress data in any deeper sense, and it cannot rename tags or drop unused namespaces.
The formatter works from tag boundaries, not from a full parse. It will not report mismatched tags, missing quotes or illegal characters. If a document is broken, the output may still look neat while the nesting is wrong, so a sudden jump in indentation, or a final line that is not indented at column zero, is a hint that a tag is missing or extra. CDATA sections, which contain a greater-than sign inside their brackets, may be split oddly across lines because the tokenizer looks for the first closing bracket. For strict validation against a schema, use a dedicated XML validator or your application's parser.
Be careful with content where whitespace matters, such as preformatted text elements, some markup languages built on XML, or documents that compare text exactly. Formatting inserts new lines and spaces between elements, which is harmless for most data files but may matter if a downstream system treats those spaces as content. When in doubt, compare the parsed data from before and after, rather than relying on how the text looks.
Format an unfamiliar response before you read it, so you can see how deep the structure goes. When you are about to commit a configuration file, format it once so that diffs show only real changes rather than indentation noise. If your input arrives with Windows-style line endings, the tool normalizes whitespace between tags anyway, so you do not need to convert them beforehand.
It expects reasonably well-formed XML to format correctly, but it isn't a strict validator -- severely malformed XML may produce an unexpected result rather than a clear validation error.
No -- adding or removing whitespace between tags doesn't change an XML document's structure or content, only its visual readability.
Yes -- comments (<!-- ... -->) and processing instructions (<?...?>) are kept in place during formatting.
The formatter indents each nesting level by two spaces.
No. It does not validate. Broken nesting shows up as odd indentation, such as the last line not returning to the left edge.
No. It removes only whitespace between a closing bracket and the next opening bracket, so spaces within text are kept.
Yes. They are placed on their own line and do not add a level of indentation to the lines that follow.
Reference: MDN Web Docs