Issue
Sign In
StepCodex FeaturedStepCodex Reviews
Notion Docs

Well‑formedness check via DOMParser; Pretty / Minify, namespaces, CDATA, processing instructions, and comment policy. Free online tool, no login, no sign-up.

LocalPersonal data security

Loading Tool Engine

Usage Guide & Tech FAQ

Usage Guide

  1. Paste or upload UTF-8 text; a leading UTF-8 BOM is stripped before parsing when present.
  2. Choose `Pretty` for hierarchical indentation (reviews/diffs) or `Minify` for a compact, wire-style payload.
  3. Indent width (2/4 spaces) applies only to Pretty mode; Minify ignores indentation settings.
  4. Toggle `Keep comments`: when off, Pretty omits comments in the formatted text; Minify removes comment nodes before serialization.
  5. If you see a parser error, fix well‑formedness issues first (unclosed tags, illegal characters, unescaped `&`, etc.).
  6. Namespaces and prefixes (`soap:`, `xmlns:`) are handled by the browser XML engine; prefixes and declarations are preserved where possible.
  7. CDATA sections keep raw text without entity escaping; formatting preserves `<![CDATA[...]]>` blocks.
  8. Large documents consume RAM; very long single lines can be slow—pre-wrap externally or split work to reduce jank.
  9. This page checks well‑formedness only, not XSD/DTD validity (schema validation needs a separate toolchain).
  10. After handling secrets or PII, clear inputs and close the tab to reduce local session exposure.
  11. Read the title and description first to confirm this utility matches your task (avoid using the wrong tool and misinterpreting output).
  12. Paste or type input in the editor; if a sample/template is provided, load it first to learn the expected output shape.

Related Tech Knowledge

  • Pipeline: `DOMParser.parseFromString(..., "application/xml")` → detect `parsererror` → walk the DOM with escaped text/attributes for Pretty output.
  • Minify uses `XMLSerializer.serializeToString` plus whitespace trimming between tags; formatting may differ slightly from hand-written whitespace while staying parse-equivalent.
  • Browsers do not automatically validate arbitrary XSDs; use CI or dedicated validators for schema conformance.
  • Predefined entities are expanded per XML rules; undeclared custom entities may fail parsing.
  • Processing instructions (e.g. `xml-stylesheet`) appear on their own lines in Pretty output when present.
  • Mixed content (text interleaved with elements) preserves child-node order, unlike naive regex formatters.
  • Unlike HTML parsing, `application/xml` is strict about mismatched tags and implicit structures.
  • Performance is roughly linear in node count; extremely deep trees may hit engine limits.
  • Security: malicious entity expansion or “billion laughs” patterns can still stress the parser—do not automate untrusted inputs without limits.
  • Interoperability: re-validate in your server stack (libxml, JAXB, etc.) to catch dialect or config differences.
  • Core parsing and computation run in your browser; by default your raw business payload is not persisted to this site’s servers (see on-page privacy notes).
  • The pipeline is typically: read input → parse (lexical/syntactic/structured) → transform → render; failures aim to be diagnosable.