Skip to content

XML Formatter

Paste XML and format it with consistent indentation, minify it to a single line, or check it is well-formed — with specific error messages naming exactly which tag is mismatched or unclosed and at what line, instead of a generic parse failure.

  • Format, minify and validate modes
  • Specific mismatched/unclosed-tag errors, with line numbers
  • Preserves comments, CDATA and the XML declaration exactly
  • Rejects more than one root element
  • Runs fully client-side

Formatter

Parsed locally, nothing uploaded

Output

How to format XML

  1. 01

    Paste the XML

    A full document or a fragment — either works.

  2. 02

    Pick a mode

    Format for readable indentation, Minify for one line, Validate to just check well-formedness.

  3. 03

    Fix anything flagged

    Errors name the specific mismatched or unclosed tag and its line, not a generic parse failure.

What "well-formed" means here, and what this tool does not check#

This tool checks well-formedness — every tag opened is closed in the right order, attribute quotes are terminated, and there is exactly one root element — the structural rules that apply to all XML regardless of its purpose. It does not validate against a DTD or XML Schema, which would check whether the specific elements and attributes used are the ones a particular vocabulary (like an RSS feed or an SVG file) actually allows. Well-formedness is necessary but not sufficient for XML to be correct for its intended use; schema validation is a separate, vocabulary-specific step this tool does not attempt.

Why leaf elements collapse onto one line#

A generic pretty-printer that puts every opening tag, its text, and its closing tag on three separate lines produces output that is technically indented but genuinely harder to scan than the input was. This formatter collapses an element that contains nothing but text — no nested tags — onto a single line, like <title>DevSEOCraft Tools</title>, and reserves the multi-line, indented treatment for elements that actually have children to show.

What survives untouched: comments, CDATA and the XML declaration#

A comment's content, a CDATA block's raw content (which can legitimately contain characters like < that would otherwise need escaping), and the leading <?xml version="1.0"?> declaration are all passed through exactly as written, never re-indented or re-wrapped into their surrounding text. Reformatting the inside of a CDATA block, in particular, would corrupt whatever raw content it exists specifically to protect.

Frequently asked questions

Does this validate my XML against a schema or DTD?

No — it checks well-formedness (balanced tags, terminated quotes, a single root element), the structural rules every XML document must follow. It does not check whether your specific tags and attributes match a particular vocabulary's rules, which requires a separate schema-specific validator.

Why does an element with just text end up on one line instead of three?

An element with no nested children — just text content — is collapsed onto a single line, like <title>text</title>, since spreading it across three lines makes it harder to scan without adding any real information.

Does formatting touch the contents of a CDATA block or comment?

No — both are preserved exactly as written. Reformatting a CDATA block in particular would corrupt raw content it exists specifically to protect from XML parsing rules.

Is my XML sent anywhere?

No. Parsing and formatting run entirely in your browser — nothing is uploaded.

Developers

UUID Generator

Generate cryptographically random UUID v4 or time-ordered UUID v7, in bulk.

Developers

Base64 Encoder & Decoder

Encode and decode Base64 with correct UTF-8 handling, including the URL-safe alphabet.

Developers

ULID Generator

Generate ULIDs — sortable by creation time like UUID v7, but Crockford Base32 instead of hex.