Editorial note: Generated querySelector calls follow the first match rule. Sibling tags with identical names are folded into arrays only when the parent sees repeats. Mixed content, processing instructions, and wildcard XPath rules are out of scope here. For path-based extraction, pair this workflow with the XPath tester when you need precision beyond a single sample tree.
Plain objects versus generated classes
Some teams stop at JSON-shaped data. Others want constructors, serializers, and named methods so the rest of the app reads like a domain model. This page leans toward the second style on purpose.
| Approach | What you gain | What you trade away |
|---|---|---|
| JSON-first pipeline | Smaller bundles, trivial logging | Less structure for XML-only quirks such as attribute ordering |
| Class output from this tool | Named types, toElement hooks, explicit parse steps | More lines to review before you merge into production |
Snapshot: one order fragment
The bundled sample models a tiny order with repeated Line nodes and a tier attribute on Customer. Use rows below to sanity-check what you expect before you paste proprietary feeds.
- Before (XML)
<Line sku="SKU-91" qty="2">Desk mat</Line>sitting beside a secondLineunder the same parent.- After (JS shape)
- A
lineListarray on the parent plus aLineclass capturingsku,qty, and text-derived fields for the label.
What the emitter is doing under the hood
DOMParser turns your string into a live document. The walker inspects each element’s direct children, groups repeated tag names, and promotes attributes into parallel fields. Numeric and boolean literals are detected with conservative rules so currency strings stay strings.
Serialization walks back through the same shape, recreating elements with document.createElement. Nothing posts to Toolexe servers; the entire pass runs where the page already loaded.
Where teams plug this in
- API designers mock SOAP-ish payloads, then diff the generated classes against what backend XSDs eventually require.
- Frontend engineers spike integrations against legacy ERP dumps without waiting on middleware.
- Technical writers freeze illustrative XML next to runnable code for internal workshops.
Why we bias toward browser-side parsing here
Shipping XML to a third-party API for codegen is convenient until contracts change or compliance asks for data residency proof. Keeping DOMParser local means the sample you paste never leaves your session unless you choose to copy results elsewhere. The trade-off is predictable: you inherit browser limits on entity expansion, document size, and error text quality.
We recommend treating every download as a draft. Run your formatter, rename classes to match house style, and add unit tests around the edges you care about (nullable attributes, optional nodes, CDATA blocks). The generator is a fast sketch pad, not a substitute for schema validation or code review.
Stop when the tree stops matching reality
Feeds with recursive depth, arbitrary mixed content, or unpredictable tag soup will produce honest-looking methods that still mis-map data. When structure varies by tenant, generate from the strictest sample you have, then branch manually. Logging the raw string alongside parsed output catches drift faster than staring at minified production bundles alone.
When you only need JSON without methods, the XML to JSON converter stays the lighter stop. If you want static types on top of JSON, follow with the XML to TypeScript flow after you settle on a schema. Invalid markup should surface early; the XML validator helps when the parser error string feels too terse.
