Skip to content

XML format

Pretty-print an XML document (or paste it in) into a readable, deterministic layout.

XMLformatprettysecure

Upload

Files (0–1)
One XML document, up to 4 MB, or paste it below. No DOCTYPE, no mixed content; anything risky gets a named refusal.
Paste an XML document instead of uploading a file. The same security refusals apply: no network, no external entities, no mixed content.

Options

Questions people ask
What if my document is not well-formed XML?
A document that is not well-formed, whether an unclosed tag, an undefined entity or a bare garbage stream, is user content. The tool does not crash and does not fabricate an "improvement"; it completes the attempt and hands back a diagnostic: a syntax finding with the parser's line and column. `Status` reads "Could not format", and the diagnostic explains exactly why the reformat was impossible. This is the same treatment as the lint tools you'd use next: the job's outcome is "I looked at your document and here is what I found".
Why won't the tool format my XML that has a DOCTYPE?
A ``<!DOCTYPE`` declaration is the shape of the document that enables two whole classes of XML attack: XXE ("file://" and "http://" external entities, the "you can read my /etc/passwd" class) and entity expansion ("billion laughs", where a small wire payload amplifies to gigabytes of memory). Rather than try to parse a DTD carefully and prove we did not fetch anything, the tool *refuses to parse documents with a DTD at all*. The refusal ships as a **diagnostic** on a succeeded job: the code is ``E_XML_DTD`` and the finding names the external / internal entity risk. Strip the DOCTYPE and re-upload, and the document will format normally.
Why does it refuse mixed content?
A document like ``<para>The <b>bold</b> part</para>`` has element children interleaved with meaningful text: "The " and " part" are load-bearing text, not whitespace. Pretty-printing would add indentation whitespace around the <b> element. That is harmless in most XML parsers, but CSS, XSLT and XHTML *do* treat those text nodes as content; a pretty-printer that silently re-shapes them has changed the document's meaning. The tool refuses such documents with `E_XML_MIXED` so the user does not have to check by hand.
My XML is thousands of levels deep and the tool refused it. Why?
The reformat phase re-walks the element tree once per nesting level, and the tool holds that walk inside a fixed 512-level budget so it can always finish instead of crashing mid-way. A document deeper than that is not print-prettied: you get the named ``E_XML_NESTING`` refusal (the name is the same in the report and in the technical details) rather than a stack-overflow job failure. Documents that humans actually print sit dozens of levels deep at most; 512 is far above that, and a refusal is always honest about the depth it saw.
What about entities like &amp; and &lt;?
The five XML predefined entities (``&amp;`` / ``&lt;`` / ``&gt;`` / ``&quot;`` / ``&apos;``) are handled natively: the parser unescapes them into the tree, and the re- writer re-escapes them on the way out. This is the only entity handling the tool does; a document that declares *user-defined* entities (which requires a DTD) is refused by the DOCTYPE rule.
Does it rename namespaces?
It may re-label the *prefix*. A document that writes ``ns:root`` with ``xmlns:ns="http://x"`` may come back as `ns0:root` with `xmlns:ns0="http://x"`. The qualified names are unchanged (the element still points to the same URI), so the document's meaning is exactly the same. If the user wants the original prefix labels preserved, the tool does not provide that option; it would require a full-fidelity XML library that the platform's stdlib does not ship.
Does it preserve CDATA sections, comments, and PIs?
No. CDATA sections are parsed to their text value and re-emitted as escaped text (the meaning is the same, the source style is not). Comments and processing instructions are dropped: they are not part of the element tree the tool's serializer writes. Both limitations are in the result summary's ``notes`` field so the output cannot be mistaken for a byte-identical round-trip.
Does anything leave my server?
No. The processor runs in an isolated container with no network access. No external fetch handler is ever registered on the parser. The upload is deleted the moment the job completes; the result is kept for about 10 minutes.