DOMParser Silently Fails on Invalid XML — How to Actually Detect It

Published 24 Sep 2026 · 7 min read

Most parsers in JavaScript follow the same contract: feed them something broken, they throw. JSON.parse() does it. new URL() does it. atob() does it. DOMParser does not. Call new DOMParser().parseFromString(brokenXml, "text/xml") on malformed XML and nothing throws — you get back a real Document object, your try/catch block never runs, and unless you go looking for it, the error is invisible until something downstream chokes on the garbage data. This walkthrough covers exactly what DOMParser does instead of throwing, the one check that reliably catches it, and a check that looks correct but silently misses more than half of real-world cases — every result verified live in this browser's own DOMParser, with a working example in XML ↔ JSON Converter.

Quick reference

Every row below was produced by pasting the exact input into this browser's own DOMParser and reading back the real result — not assumed from documentation. All eight cases share one thing: none of them threw an exception.

1. What actually happens instead of throwing

The DOM spec's parseFromString() is defined to never fail loudly. On success it returns a Document matching your input. On failure it also returns a Document — just one whose tree includes a <parsererror> element with a human-readable description of the problem, rendered the way a browser would render an error page. Code that expects an exception and never checks the return value keeps running as if parsing succeeded.

const parser = new DOMParser();
const doc = parser.parseFromString("<root><child></root>", "text/xml");

// No exception was thrown. This line runs.
console.log("Parsed fine, apparently");

// But the tree actually contains an error:
doc.getElementsByTagName("parsererror")[0]?.textContent;
// "This page contains the following errors:
//  error on line 1 at column 21: Opening and ending tag mismatch:
//  child line 1 and root
//  Below is a rendering of the page up to the first error."

This is by design, not a bug — DOMParser predates widespread use of exceptions for this kind of failure in the DOM, and every major engine (Chromium, WebKit, Gecko) still follows the same never-throw contract today.

2. The check that actually works

MDN's own recommendation, and the one that held up against every case tested here, is a single line run after every parse:

function parseXml(xmlString) {
  const doc = new DOMParser().parseFromString(xmlString, "text/xml");
  const errorNode = doc.getElementsByTagName("parsererror")[0];
  if (errorNode) {
    throw new Error("Invalid XML: " + errorNode.textContent);
  }
  return doc;
}

This is exactly the check this site's own XML ↔ JSON Converter uses internally before attempting to convert anything — it's why the example above shows a clean error instead of trying to convert a half-parsed tree into JSON.

3. The check that looks right but silently fails

A pattern that shows up in a lot of older answers checks the parsed document's root element directly instead of searching for parsererror:

// This looks reasonable. It is not reliable.
function isValidXml(xmlString) {
  const doc = new DOMParser().parseFromString(xmlString, "text/xml");
  return doc.documentElement.nodeName !== "parsererror";
}

The safe version doesn't inspect the root at all; it searches the whole tree for parsererror, the same way the working check in section 2 does. If you're maintaining code with the documentElement.nodeName pattern today, it's worth swapping it out — it isn't a style preference, it's a real gap that lets malformed XML through undetected.

4. Why this matters more than it seems

The failure mode isn't a crash — it's silent data corruption downstream. Code that walks the parsed tree assuming it's well-formed will either throw a confusing, unrelated error several function calls later (a TypeError on a property that doesn't exist, because the tree shape isn't what was expected), or worse, quietly extract wrong values from whatever fragment did parse before the error. Neither failure mode points back to the actual problem: the XML was invalid, and nothing said so at the time.

Debugging checklist

1. After every parseFromString() call, check doc.getElementsByTagName("parsererror").length > 0 — never rely on the absence of a thrown exception as proof the XML was valid.
2. If you're using doc.documentElement.nodeName === "parsererror" anywhere in an existing codebase, replace it — verified above, it misses a majority of real structural errors.
3. Read parsererror.textContent for a human-readable description before deciding how to handle the failure; it names the exact line and column.
4. Remember this applies to text/xml and application/xml parsing specifically — text/html parsing through DOMParser has separate, much more forgiving error-recovery behavior and generally won't produce a parsererror at all.

Related to this: if your data is JSON rather than XML, the equivalent silent-failure trap doesn't exist — JSON.parse() throws reliably on malformed input, covered in Unexpected Token in JSON. For a broader look at when XML still makes sense over JSON in the first place, see the JSON vs YAML vs XML comparison guide.

← Back to Blog · See also: Unexpected Token in JSON →