Format XML _

What is XML formatting?

XML (Extensible Markup Language) is a W3C-standardised text format for structured documents and data interchange. Formatting — also called pretty-printing or beautifying — takes a well-formed XML source and re-indents it so each element, attribute, comment, processing instruction, and CDATA section is easy to scan. The parsed document tree is preserved exactly; only the inter-element whitespace changes.

How does XML formatting work?

Your input is processed entirely in your browser using the native DOMParser and XMLSerializer APIs plus a custom recursive indenter. The high-level steps are:

1. Your input is read verbatim from the textarea — every byte you pasted is kept in memory locally.
2. The browser parses it with new DOMParser().parseFromString(text, 'application/xml'). If the input is not well-formed, the parser embeds a <parsererror> node whose text payload carries the engine's line and column hints — they are surfaced verbatim in the error strip.
3. On a successful parse, a custom indenter walks the DOM tree depth-first, emitting each element, attribute set, CDATA section, comment, and processing instruction on its own line at the current depth. Self-closing void tags are honoured when the option is on.
4. Minify mode flips the pipeline: XMLSerializer().serializeToString(doc) emits a single-line form, then a guarded regex strips inter-element whitespace without touching text inside CDATA blocks or non-whitespace text nodes.
5. Output is written to the readonly textarea, the error strip is cleared, and the Download button packages the result as a .xml file you can ship or attach to a ticket.

Why pretty-print XML with this tool?

• Privacy: every parse, format, and minify pass happens in your browser. The XML never reaches our servers — no upload, no telemetry, no account.
• Precise errors: when the input is malformed, the parser surfaces the exact line and column the browser engine itself reports, not a synthetic guess — the same numbers you'd see in DevTools.
• Faithful round-trip: format then minify and you get back the byte-equivalent of your original document (modulo the XML declaration option) — formatting never re-canonicalises namespaces or rewrites attribute order.
• Fast: pure DOMParser plus a ~60-line indenter handle multi-megabyte SOAP envelopes and OOXML chunks instantly, with no external library to download.

What are common applications of XML formatting?

Pretty-printing XML shows up across web publishing, enterprise integration, and data archival:

• RSS / Atom feed inspection: paste a podcast or news feed body to confirm channel metadata, item ordering, and namespace prefixes before publishing.
• SOAP debugging: format an envelope copied from Wireshark or a SOAP client log so the Header, Body, and Fault sections are visible at a glance.
• Sitemap auditing: re-indent a sitemap.xml fetched from a competitor or your own staging site to count entries and confirm hreflang alternates per URL.

What does an XML formatting example look like?

Pasting a 3-element <feed><entry><title>Hello</title></entry></feed> and pressing Format with the 2-space indent option yields a four-line document with each element on its own line, indented by depth. Switching to Minify on the same input collapses it back to the original byte-string. Round-tripping is loss-free for any well-formed document.

Does this run offline?

Yes. The format and minify pipeline is pure DOMParser + XMLSerializer plus a tiny recursive indenter, all running inside the browser tab. Nothing is uploaded, no service worker proxies your input, and the page makes zero network requests for the format step itself. The only outbound traffic is the standard page-load assets (CSS, fonts, analytics) — your XML never reaches Ultim8Soft.

Does formatting change the document?

No semantic change. Formatting only rewrites whitespace between elements. Element names, attribute values, text content, CDATA payloads, comments, and processing instructions are preserved byte-for-byte. Namespace declarations and prefixes are kept exactly as the input wrote them — the formatter does not re-canonicalise or reorder attributes. The output parses to the same DOM tree as the input, modulo the optional XML declaration toggle.

How are CDATA / comments / processing instructions handled?

Each is emitted verbatim on its own line at the current indent depth. CDATA payloads are wrapped in <![CDATA[…]]> with no re-indentation inside — the spec says CDATA content is opaque, so the formatter never touches it. Comments use <!-- … -->; processing instructions use <?target data?>. All three survive a format → minify → format round-trip with their content intact.

What's the difference between formatting and minifying XML?

Formatting expands whitespace so humans can read the document tree; minifying strips it back out for transport and storage. Both operate on the parsed DOM, not the raw byte string, so a round-trip format → minify on a well-formed document yields the byte-equivalent of the original minified form. Use the format direction when you need to read or diff an XML payload, and the minify direction when you want to ship one over a metered API gateway or embed it inside another document.

This XML formatter uses the same parser your browser uses for AJAX XHR responses and SVG documents, so any well-formed XML — RSS, Atom, SOAP, sitemap, OOXML, SVG — round-trips cleanly. Paste any XML above, copy the output, or download it as .xml.