XML delivers character data to applications. Without a content model, a formatter cannot universally know whether a whitespace-only node is decoration, prose spacing, a delimiter, or an application value.
Element-only layout policy
When an element has markup children but no direct non-whitespace text, no CDATA child, and no effective xml:space preserve instruction, XMLClear treats whitespace-only children as layout. Format replaces those nodes with line feeds and the selected depth; Minify removes them. Start tags, end tags, attributes, entities, comments, processing instructions, and child source remain text from the original. This makes compact configuration and data XML easier to scan while keeping the transformation boundary visible.
Mixed content stays together
In `<p>Hello <strong>world</strong>!</p>`, spaces and punctuation connect prose around a child element. Adding a line feed before strong would change the character data delivered to the application. XMLClear marks any element with direct non-whitespace text or CDATA as mixed and emits its complete inner source unchanged. An effective xml:space preserve instruction similarly keeps source whitespace until a descendant explicitly returns to default. This conservative choice can leave one compact line inside an otherwise indented hierarchy, which is preferable to silently rewriting prose.
A practical review before use
Keep the original document beside the derived result and compare the part you intend to use. Confirm that element and attribute names, namespace prefixes and declarations, entity spellings, comments, processing instructions, CDATA boundaries, and mixed text read as expected. If the receiving system treats whitespace-only text as data, prefer Check or keep the original source rather than assuming a formatter can infer a missing content model. Finally run the result through the same schema, tests, signature checks, and application workflow that normally accepts this XML. XMLClear deliberately cannot prove those separate contracts.