XML viewer that keeps the namespaces straight

Almost always because the document declares a default namespace and your expression does not account for it. Once an ancestor carries xmlns="http://www.w3.org/2005/Atom", every element inside it belongs to that namespace, and in XPath 1.0 an unprefixed name means the no-namespace name — so //entry cannot match the Atom entry no matter how it is spelled. There are two ways out: bind a prefix in your XPath engine and write //atom:entry, or sidestep bindings entirely with //*[local-name()='entry']. This viewer hands you the second form on any element that has a namespace, because it is the one that works in a shell one-liner.

Because they are whitespace-only text nodes, and showing them would double the length of the tree without adding anything. Every newline and run of indentation between two tags is a real node in the DOM — a pretty-printed 200-element document typically holds around 200 of them — which is why walking childNodes in code returns text where you expected the next element. The count is printed under the tree so you know how many were set aside, and any text node with something in it is shown against its element.

A CDATA section is an escape hatch that tells the parser to treat everything up to ]]> as character data rather than markup. It is how an RSS feed carries a whole HTML fragment inside <content:encoded> without escaping every angle bracket. To the parser the result is text, not structure, so this viewer shows it as the element's text with a CDATA badge instead of building child nodes from it. If you need the markup inside as a tree, copy it out and open it as its own document.

The prefix is only a local nickname for a namespace URI, and it is the URI that identifies the element. A feed that writes xmlns:dc="http://purl.org/dc/elements/1.1/" could rename dc: to anything and mean exactly the same thing, while an element with no prefix belongs either to the default namespace or to no namespace at all. The panel under the tree spells out which URI the selected element resolves to, and the footer lists every binding in the document, because two files that look different often differ in nothing but their choice of prefixes.

Up to 5 MB, yes, because the tree draws only what is unfolded. The model is built once and holds up to 100,000 elements; the pane then renders at most 2,000 rows however many branches are open, so scrolling stays smooth on a feed with tens of thousands of entries. Filtering is the faster way through a big file: it narrows the tree to matching elements and their ancestors in a single pass rather than making you fold your way down.

No — this is a reading tool, and nothing you do to the tree alters the document. That is deliberate: exploring a payload and editing it want different interfaces, and a viewer that quietly re-serialises what it parsed will normalise your quoting, your empty-element style and your attribute order along the way. For reshaping the markup itself use format-xml.com, our dedicated XML tool, and for turning the document into something a script can loop over, the XML to JSON converter.

The document did not parse, and XML parsers stop at the first fault rather than recovering. The bar under the tree shows the browser's message and the line it stopped on; the XML validator on this site gives you the column, the source line with a caret under it and the rule that was broken. Unescaped ampersands, a mismatched closing tag and two root elements account for most of it.