XMLビューアー
XML Viewer renders a document as a collapsible tree in your browser. The tree is virtualized, so a large SOAP response or sitemap opens at the same speed as a small one, and attributes are shown distinctly from child elements — which is the distinction that makes an unfamiliar XML document readable.
このツールの画面は英語表記です。
以下の解説は英語のみでご覧いただけます。
How does XML Viewer work?
Nobody opens an XML viewer for a twenty-line document. They open one for a SOAP response, a sitemap, an SVG, a Maven POM or a config file that is too large to read as text and too nested to follow with a text editor's folding. So the only question that matters is what happens at size.
The tree is virtualized, so size barely matters
The obvious implementation renders one component per node, which means a fifty-thousand-node document produces fifty thousand DOM elements of which perhaps forty are visible. Scrolling stutters and the tab consumes hundreds of megabytes. Here the document is flattened into an array of rows first — each carrying its depth, its type and where its subtree ends — and only the rows inside the viewport are rendered. The DOM holds around fifty elements no matter how big the document is.
Recording where each subtree ends is what makes collapsing cheap: hiding a branch is one index comparison rather than a walk over everything inside it. Collapsing the root of a huge document is instant.
Attributes are shown separately from elements
XML has two kinds of member and most viewers flatten them into one, which loses the distinction between <line sku="X"/> and <line><sku>X</sku></line>. Attributes appear under an @ prefix so both survive and neither overwrites the other — which matters, because an element carrying both an attribute and a child element of the same name is common in real vocabularies.
Search covers the whole document, not the open part
A match buried in a collapsed subtree is found and shown, with every ancestor on the path to it, because a value without its path tells you nothing about where it came from.
Malformed input is named, not guessed at
Mismatched tags and unclosed elements produce an error identifying the tag and the line. Truncated XML is the most common thing anyone pastes into a viewer — it is why they are looking at it — so a viewer that renders something plausible from a broken document is actively unhelpful.
The formatted view is separate and lossless: it re-indents without touching content, preserving CDATA, comments, processing instructions and the exact text inside elements.
XML
<order id="1"><line sku="A" qty="2"/></order>
Tree
▾ order { 2 }
@id "1"
▾ line { 2 }
@sku "A"
@qty "2"What options and edge cases does XML Viewer support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Virtualization | viewport only | — | Around fifty rows exist in the DOM at any moment regardless of document size. This is the difference between opening a 10 MB SOAP log and hanging the tab. |
| Attributes | @ prefix | shown | Kept distinct from child elements, so an element with both a sku attribute and a sku child shows both rather than one silently winning. |
| Text nodes | #text | shown | Element text appears under its own row rather than being collapsed into the element, so an element that has text and children shows both. |
| Comments | #comment | shown | Kept, because a comment in a config file is frequently the only documentation of why a value is what it is. |
| CDATA | literal | — | Shown verbatim. Entities inside a CDATA section are not entities, which is the whole point of the construct. |
| Namespaces | preserved | prefix kept | soap:Body stays soap:Body, and xmlns declarations appear as attributes. Stripping them is available in the XML to JSON converter, where it is a conversion choice rather than a display one. |
| Search | substring | case-insensitive | Matches names and values across the entire document, including collapsed branches, and keeps every ancestor of a match so the path stays visible. |
| Malformed input | error | named | Mismatched or unclosed tags are reported with the tag name and line. The tree keeps showing the last document that parsed rather than blanking as you type. |
| Input size | bytes | 8 MB | Tokenizing runs on the main thread. Above the ceiling the tool declines rather than freezing; the tree itself handles far more nodes than that allows. |
Frequently asked questions
Will it open a large SOAP response or sitemap?
Up to the 8 MB ceiling, and the tree is not the bottleneck — it renders only what is on screen, so node count has almost no effect on it. The limit is the tokenizer, which runs on the main thread and declines above 8 MB rather than attempting it, because attempting it locks the tab for seconds.
Why do some rows start with @?
Those are attributes. XML has attributes and child elements; JSON-shaped trees have one kind of member, so attributes are prefixed to keep them distinct. Without the prefix, an element carrying both a sku attribute and a sku child element would show only one of them, and you would have no way to tell which.
Can I edit the XML here?
You can edit the text pane and the tree follows, but the tree itself is read-only. Keeping it read-only is what lets it stay fast on documents an editing tree would struggle with — an editable tree has to reconcile two sources of truth on every keystroke. For re-indenting, use the formatted view or the XML Formatter.
My document is invalid. Why does the tree still show something?
Because it is showing the last version that parsed, so a single keystroke mid-edit does not blank the whole view. The error banner names the mismatched or unclosed tag and its line. Once the document parses again the tree updates.
Does the formatted view change my document?
It changes whitespace between elements and nothing else. Text content, CDATA sections, comments, processing instructions and attribute values are preserved byte for byte. Be aware that whitespace between elements is significant to a strict XML parser, so the re-indented document is not always interchangeable with the original for a machine — only for a person.
Is my XML uploaded?
No. Tokenizing and rendering both happen in the tab you already have open — open DevTools, watch the Network panel and paste. This matters for XML more than most formats: what people actually need to read is SOAP traffic, SAML assertions and financial messages, which is some of the most sensitive material a developer handles.