XML formatter & automatic indentation formatting tool | ZeroTools

This tool parses input text data using the browser's standard feature DOMParser (specifying application/xml). During this process, it strictly evaluates whether the XML meets well-formedness requirements.

Before parsing begins, protective guardrails check that input text does not exceed 100,000 UTF-16 code units and does not contain DOCTYPE declarations (accurately ignoring DOCTYPE strings inside comments, CDATA, or processing instructions).

When syntax errors occur—such as mismatched start and end tags, missing closing tags, or missing quotes in attribute values—tests have observed that WebKit inserts an XHTML parsererror panel into a partially parsed document rather than using Mozilla's reserved error namespace.

Consequently, the shared core rejects both Mozilla's error namespace and known WebKit/Blink XHTML generated error panels (identifying the specific namespace, style marker, and two error headings), rather than rejecting a bare tag named parsererror.

Ordinary elements named parsererror without a namespace, as well as ordinary XHTML parsererror elements lacking generated panel markers, remain entirely valid.

The implementation does not claim that the error namespace alone always detects parse failures across all browsers; matches against known generated panels are conservative, and detection of lookalikes or universal browser support is not guaranteed.

When an error is caught, no partial output, raw browser HTML, or line numbers are exposed, presenting only a generic localized error message in the output area.

This processing is performed by building a DOM tree inside the client browser. Document tree depth is limited to 64 levels and total node count (including elements and attributes) is limited to 20,000, while the serialized output is capped at 2,000,000 UTF-16 code units.

These limits reduce browser workload, though they are not a hard guarantee against all temporary freezes or memory consumption. No XML data is transmitted to an external server for formatting.

In addition, the check is strictly limited to structural well-formedness; there is no feature to automatically repair broken markup or validate against external schemas.

When an error is detected or input is modified, previous formatted results are suppressed immediately so that invalid or stale data cannot be copied.

An XML document that has been successfully parsed is given indentation according to the hierarchical structure of the elements (node depth), and formatted into a format that is visually easy for humans to read.

In this tool, you can specify three types of indentation widths from the select box: "2 spaces", "4 spaces", and "8 spaces".

The indentation process recursively traverses the DOM tree starting from the root element. When formatting branches that contain no direct text or CDATA nodes, the tool tracks element depth and calculates the appropriate indentation prefix (depth multiplied by the selected number of spaces) for each opening and closing tag.

Any element that directly contains child Text nodes (including whitespace-only text) or CDATA sections is serialized without internal re-indentation, preserving all inner text spacing intact.

At this time, indentation is inserted around element tags in text-free branches. If existing blank text nodes or line breaks are present between child elements, they are preserved as DOM data and serialized directly.

Because existing whitespace is preserved rather than silently stripped, arbitrary formatting will retain its original character spacing within text-bearing elements.

Note that tab indentation is not provided for XML formatting in this interface, adhering strictly to 2, 4, or 8 space options.

The process for serializing DOM tree nodes back into formatted text strings utilizes the browser's native XMLSerializer API alongside structural indentation calculation.

By relying on XMLSerializer, the tool accurately reproduces node attributes, preserves tag structures, and maintains XML entity escaping according to browser DOM standards.

Attribute values and text content containing special characters such as <, >, &, ", and ' are automatically handled by XMLSerializer, converting them to appropriate entity references (<, &, etc.) or preserving standard escaping without breaking well-formed XML syntax.

Quotes, attribute ordering, and specific entity notation may be normalized according to browser serialization rules.

Furthermore, CDATA sections, comment nodes (<!-- -->), processing instructions (<? ?>), and xml:space directives are preserved as DOM data and output directly.

Any original XML declaration at the beginning of the input (e.g., <?xml version="1.0" encoding="UTF-8"?>) is extracted and retained at the beginning of the output.

However, perfect lexical and byte preservation is not guaranteed: empty tag syntax, attribute ordering, quote styles, and line endings may differ from the source document.

In XML formatting, one of the most critical aspects is handling "mixed content" where text nodes and element nodes coexist within the same parent element.

Common examples include markup like <p>Some <strong>bold</strong> text</p>.

In this tool's implementation, any element containing direct Text nodes—including whitespace-only text or a single space—or CDATA sections is serialized directly without inserting internal indentation, line breaks, or padding.

This prevents the insertion of extraneous spacing that could alter document layout or semantic text parsing in downstream applications.

Additionally, this tool strictly respects the standard xml:space="preserve" attribute. When an element or its ancestor specifies xml:space="preserve", internal indentation formatting is bypassed and the element is serialized directly from the DOM tree, ensuring that intentional whitespace and newlines remain completely intact.

In addition to the "Beautify" function that formats XML documents with 2, 4, or 8 spaces of indentation for enhanced human readability, this tool includes a "Minify" function designed to eliminate unnecessary structural spacing.

When Minify mode is selected, the indentation size parameter is explicitly set to null, which completely prevents the formatter from inserting new indentation spaces or line breaks between tags.

However, it is essential to recognize that this tool never compresses, strips, or deletes existing whitespace inside element text nodes, CDATA sections, comments, or processing instructions.

Crucially, the minification implementation operates directly on the DOM tree produced by the browser's native DOMParser without applying destructive global regular expressions.

If an element contains any direct text child nodes—even if they consist entirely of whitespace or newlines—or CDATA blocks, the formatter preserves the element's existing content in its entirety via XMLSerializer without applying internal reindentation, filtering, or whitespace replacement.

While document-level whitespace separators between the prolog and the document root can be eliminated, the tool does not compress or collapse whitespace nodes located between sibling elements if those whitespace text nodes were already instantiated during parsing.

Consequently, developers should not expect this minification utility to strip pre-existing line breaks or indentation spaces that were already part of element content in the parsed source XML.

Both mixed-content structures and elements explicitly designated with xml:space="preserve" maintain their text values, and all comments, CDATA sections, and processing instructions parsed by the browser DOM remain present in the output.

Because the tool does not delete existing element text whitespace, the parsed DOM node data is retained, though document-level separators or empty element token syntax generated by native XMLSerializer may differ from the original source bytes.

When integrating the output of this tool into production workflows and automated data pipelines, developers must account for several technical constraints.

First, regarding documents containing XML Digital Signatures (XMLDSIG): signature validity depends on the specific signed target elements and the canonicalization algorithms (such as Canonical XML / C14N) configured for verification.

Although this tool retains parsed text nodes and only inserts indentation spaces into element branches free of direct text, serialization through the browser's native XMLSerializer standardizes line breaks, formats empty element tags, and may adjust attribute sequence and whitespace.

Depending on how the signed payload was originally scoped and digested, these serialization differences may alter the resulting bytes and affect signature verification.

Signed XML documents should not be processed prior to cryptographic verification, and raw originals should always be retained.

Second, regarding document validation and schema compliance: this tool evaluates XML exclusively via the browser's built-in DOMParser, performing pure well-formedness checks rather than comprehensive schema validation.

It does not perform external DTD resolution, W3C XML Schema (XSD) validation, XPath evaluations, or XSLT stylesheets. Any document containing a DOCTYPE declaration is rejected at the input boundary prior to DOM parsing to safeguard against external entity injection (XXE) vulnerabilities and document expansion attacks.

Furthermore, parse operations enforce strict resource thresholds: input length is checked before parsing (up to 100,000 UTF-16 code units), and parsed DOM structures must not exceed a maximum tree depth of 64 or a total node count of 20,000 (counting elements, attributes, text nodes, comments, and processing instructions starting from the root).

Output serialization is capped at 2,000,000 UTF-16 code units. Because processing runs synchronously on the browser's main UI thread without a WebWorker, processing time and browser responsiveness cannot be unconditionally guaranteed on low-end hardware.

Third, regarding XML declarations and character encoding handling: the original XML declaration prolog (such as <?xml version="1.0" encoding="UTF-8"?>) is identified and preserved via regular expression matching rather than naive string slicing.

However, this tool operates strictly on in-memory JavaScript UTF-16 strings; it does not perform binary character encoding conversions or output non-UTF byte encodings.

If a declaration specifies an alternate encoding such as Shift_JIS or EUC-JP, the serialized text copied to the clipboard remains in the browser's native UTF-16 string representation, and users must handle physical character encoding conversions in external tooling.

Finally, regarding clipboard actions, execution controls, and operational scope: parsing and formatting take place only when the user explicitly clicks the designated execute button, with no automatic background runs or debounce timers involved.

Any manual edits made to the input textarea or indent configuration immediately clear previously rendered output and prior error notices to prevent stale displays.

Copying formatted output relies on the asynchronous Clipboard API, which awaits the browser clipboard promise and displays an explicit error message if write permission is rejected.

Because results are reset upon new input, unverified partial edits cannot be inadvertently copied from the interface.