v151 · shipped · dom · svg · security
XML Parsing in Rust for non-XSLT scenarios
Chrome 151 enables by default the memory-safe Rust-based XML parser that replaces the C-based libxml2 parser with a memory-safe Rust-based parser for all non-XSLT XML parsing in Blink — including DOMParser, XMLHttpRequest.responseXML, SVG documents, and XHTML.
at a glance
| Shipped in | Chrome 151 (Enabled by default, all platforms — after a stepped rollout that began at 1% in Chrome 147) |
|---|---|
| Status | Enabled by default (stepped rollout) |
| Finch feature | XMLRustForNonXslt |
| Affected APIs | DOMParser, XMLHttpRequest.responseXML, SVG documents, XHTML |
| Not affected | XSLT processing (separate deprecation track, removal planned Chrome 158) |
| Blink component | Blink>DOM, Blink>SVG |
| ChromeStatus | 5309598397497344 — XML Parsing in Rust for non-XSLT scenarios |
why it exists
Blink has historically relied on libxml2, a C library, for XML parsing. libxml2 has accumulated a long history of memory-safety vulnerabilities — use-after-free bugs, buffer overflows, heap corruption — that are fundamentally difficult to prevent in C. In addition, libxml2 experienced periods of slow security-disclosure response.
Replacing the parser with a Rust implementation eliminates this entire class of memory-safety vulnerability by construction. XSLT scenarios are excluded from the initial rollout because libxml2 and libxslt are tightly entangled; the Rust parser cannot yet be applied there without also replacing the XSLT engine (which is on a separate deprecation track).
The rollout began at 1% of Chrome 147 stable users and reached enabled-by-default in Chrome 151 (chromestatus milestone listing). During the rollout, Chromium engineers monitored with Chromium engineers monitoring a real-world parsing performance histogram (Blink.XMLParsing.NonXsltXmlParsingTime.Combined) before expanding. A ~50% throughput regression was observed on a 3 MB heavy-XML microbenchmark, so the team is gathering production data to validate real-world impact is acceptable.
what changes
This is a transparent implementation swap — the web-facing APIs are unchanged. All of the following continue to work identically for well-formed XML:
| API / scenario | Uses Rust parser in Chrome 151+ |
|---|---|
DOMParser.parseFromString(str, 'text/xml') | Yes |
DOMParser.parseFromString(str, 'application/xhtml+xml') | Yes |
XMLHttpRequest.responseXML | Yes |
Top-level SVG navigation (.svg file in address bar) | Yes |
SVG external image (<img src="...svg">) | Yes |
| XHTML documents | Yes |
| XSLT processing | No — still uses libxml2/libxslt |
example: DOMParser (unchanged API)
// API shape is identical — only the underlying parser changes
const parser = new DOMParser();
const doc = parser.parseFromString(
'<root><item id="1">Hello</item></root>',
'text/xml'
);
console.log(doc.querySelector('item').textContent); // "Hello"
// Malformed XML still produces a parsererror document
const bad = parser.parseFromString('<unclosed', 'text/xml');
console.log(bad.querySelector('parsererror')); // HTMLElementbrowser support
| Browser | XML parser |
|---|---|
| Chrome 151+ (all platforms) | Rust parser for non-XSLT (enabled by default; stepped rollout began at 1% in M147) |
| Firefox | Own XML parser (Expat-based) |
| Safari | Own XML parser (libxml2-based historically) |