Paste XML and choose Parse structure to inspect ordered child indexes, node kinds, element names, namespace metadata, and attributes. In the supplied example, an empty item remains distinct from an item containing 0. Input stays literal text, and an edit clears the prior tree before another parse.
Trace an original mixed-content record
Start with this one-line sample:
<record code="R1"><title>A<em>B</em>C</title><item id="1"/><item id="2">0</item></record>
The root element is record, with attribute code="R1". Its ordered element children are title, item with id="1", then item with id="2". Attributes belong in their own inspection area; they are not child text nodes.
| Location in the sample | What to look for |
|---|---|
| title child 0 | Text node containing A |
| title child 1 | Element em, containing a Text node B |
| title child 2 | Text node containing C |
| item with id="1" | Empty child-node list |
| item with id="2" | One Text node containing 0 |
The title's combined text is ABC, but that summary alone loses the em boundary. Likewise, 0 is a nonempty text value, not absence. The empty item has no children; the second item contains the text value 0.
MDN distinguishes childNodes, which includes all child nodes, from children, which includes only elements; it also places attributes outside the main child tree. Attributes appear separately from the child-node list. MDN: Anatomy of the DOM
Retain the nodes the parser actually supplies
Follow the child indexes in order. The inspector includes elements, text, comments, and CDATA, along with whitespace text nodes supplied by the parser. A line break or indentation can therefore appear as a node between elements.
Each branch names the node kind and nodeName. Element and attribute details include localName and namespaceURI; an absent namespace appears as none. Compare the namespace URI when interpreting a prefixed name, since the prefix alone does not identify the namespace.
Use the Inspector path to trace a branch through its child indexes. These paths belong to the current parsed tree and are not XPath expressions or stable file addresses. Adding a whitespace node can change an index.
Open or close a disclosure arrow to focus on one branch. This changes what you see without altering the XML source or the parsed node values.
Keep the input source separate from the DOM view
Parsing leaves the pasted source unchanged in the input field. You can compare that source with the parsed values without an automatic formatting step rewriting it.
XML parsing can normalize line endings and expand character references. The XML specification describes those operations, so a DOM view is not a byte-preserving representation of the original file. W3C: XML 1.0
For example, an escaped character can appear as its decoded text value in the tree while the source still shows the escape sequence. Use the input to inspect the spelling and the tree to inspect the parsed value; neither a paste operation nor a DOM serialization establishes the original file's exact bytes.
A mismatched closing tag produces a diagnostic without an accepted tree. The tool also reserves the local name parsererror because browsers use that name in error documents. A diagnostic for that name can mean either a parsing failure or an unsupported user element; it does not prove that every element named parsererror is malformed.
Parse within the declared limits
Choose Parse structure after reviewing the pasted source. This tool rejects raw DOCTYPE and processing-instruction markers, including XML declarations, before parsing. That is a conservative tool restriction, not a rule that valid XML cannot contain declarations. Input is limited to 20,000 UTF-16 code units, element depth 20 and 500 represented nodes plus attributes.
After a diagnostic, correct the source and parse again. Clear empties both source and tree.
Expand a branch to inspect its children in order. Attributes remain outside child indexes, and URL-looking values stay text. The viewer creates its own controls and never inserts parsed XML nodes into the active page. It does not validate a business schema, fetch external files, transform XML or promise security certification.
Copy a prompt for this example
Create a single self-contained HTML XML inspector with embedded styles and JavaScript. Arrange a labeled source textarea beside a readable tree, stacking the panels on small screens. Include Parse structure, Load sample, and Clear buttons.
Use this exact sample: <record code="R1"><title>A<em>B</em>C</title><item id="1"/><item id="2">0</item></record>. Parse with DOMParser in application/xml mode. Represent the Document and its childNodes in order using expandable disclosure controls. Show each node's kind, name, and child-index Inspector path. For text, comments, and CDATA, show the literal node value. Preserve whitespace nodes supplied by the parser.
Show element localName and namespaceURI, using none when absent. List attributes separately with their names, values, local names, and namespace URIs. The title must show text A, an em element containing text B, and text C. The first item must have no children; the second must contain text 0.
Limit input to 20,000 UTF-16 code units, element depth to 20, and represented nodes plus attributes to 500. Reject raw DOCTYPE and processing-instruction markers, including XML declarations, as explicit tool restrictions. Catch parsing exceptions and explain the ambiguity of the reserved parsererror local name.
Clear the previous tree whenever the source changes. Clear must empty the source and tree. Render source-derived values as literal text in controls created by the inspector. Wrap unbroken node and attribute values within the available width while preserving displayed whitespace. Keep the source unchanged during parsing and make no schema-validation or byte-preservation claim. Return only the complete HTML file.
Display the HTML inspector in NOS and expand title to trace A, em containing B, and C in order. Then compare the two item elements before pasting a small XML record you need to understand.