Deprecate and remove XSLT

at a glance

reference routes

• XSLTProcessor — the removed JavaScript API: verbatim WHATWG DOM IDL vs Chromium's shipping IDL, per-member behavior, feature detection, and the polyfill/SaxonJS replacements.
• <?xml-stylesheet type="text/xsl" ?> — the removed processing-instruction behavior: grammar, what happens when disabled, what stays (CSS), and the one-line polyfill migration.
• “XSLT” deprecation origin trial + XSLTEnabled policy — the two sanctioned ways to keep XSLT working until Chrome 176, with exact registration and token-serving steps.

why it is being removed

Three converging reasons, per the removal guide and the Intent to Deprecate and Remove:

• Security attack surface. Chromium processes XSLT with libxslt, a complex aging C library of the type susceptible to memory-safety vulnerabilities (the guide cites CVE-2025-7425 and CVE-2022-22834). libxslt was unmaintained for ~6 months of 2025, and XSLT has been the source of recent high-profile browser exploits. A niche feature processing untrusted content receives far less security scrutiny than core JS engines.
• Stagnation. Browsers are frozen at XSLT 1.0 (1999); the language moved on to XSLT 3.0 (2017) with no browser interest in following.
• Superseded role. JSON as a wire format plus JS frameworks (React/Vue/Svelte) cover the transformation use case; measured usage is ~0.02% of page loads overall and ~0.001% for processing instructions.

Of ~220 surveyed sites using XSLTProcessor, roughly 72% still function with XSLT disabled (many have JS fallbacks such as Saxonica); of the visibly broken remainder, the polyfill restored functionality in 82% of cases — the rest mostly hit CORS limits (details).

what exactly is removed

deprecation and removal timeline

The current plan (per the ChromeStatus record, updated 2026-07-15, and the removal guide). The original Intent (Oct 2025) proposed removal in M155 with trial/policy ending M164; the timeline was extended after feedback — the dates below are the extended, current ones. One source discrepancy is recorded honestly: the removal guide says pre-stable disabling began in M145 Canary while the ChromeStatus experiment plan says M148 (Mar 10, 2026 Canary).

As a compact checklist:

142 (2025-10-28)  console early warnings
143 (2025-12-02)  DEPRECATED — console + Lighthouse warnings
145/148           pre-stable channels disable XSLT by default
146 (2026-03-10)  XSLTEnabled enterprise policy live for testing
152 (2026-08-25)  "XSLT" deprecation origin trial live (152-175)
158 (2026-11-17)  REMOVED from Stable (trial/policy holders excepted)
176 (2027-08-17)  trial + policy end — disabled for everyone

how to detect XSLT usage

• Console warnings — since Chrome 143, any use of XSLTProcessor or an XSL processing instruction logs a deprecation warning; Lighthouse also flags it.
• ReportingObserver — subscribe to deprecation reports and filter on the "XSLT" report id:

new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    if (report.body.id === "XSLT") {
      // XSLT usage was detected — report it back here.
    }
  });
}, { types: ["deprecation"], buffered: true }).observe();

• Enterprise Legacy Technology Report — admins can automatically collect deprecated-feature usage across the fleet (see the Google Support article).
• Manual feature check — when XSLT is disabled, window.XSLTProcessor is undefined (the interface is [RuntimeEnabled=XSLT]-gated). typeof XSLTProcessor !== "undefined" is the in-page feature detect; see detection patterns.

migration paths

In rough order of long-term preference, per the removal guide:

Use-case guidance from the removal guide:

• RSS/Atom feeds styled with XSLT for accidental human clicks: prefer <link rel="alternate" type="application/rss+xml"> discovery on HTML pages (HTML for humans, XML for machines); or add the one-line polyfill <script> to the feed — RSS readers still parse it because the script is a direct child of the root.
• Embedded devices serving XML+PI on a LAN: update firmware to any path above if possible; otherwise the browser extension keeps client browsers working unchanged.
• XSLT-as-templating sites: polyfill now; migrate to a JS/JSON framework over time.

standards discussion and vendor positions

The standards venue is whatwg/html#11523 — “Should we remove XSLT from the web platform?” (opened Aug 2025, labeled removal/deprecation, stage: 3 — the WHATWG stage indicating broad agreement to proceed). Much of XSLT was never fully specified: the WHATWG DOM Standard carries a minimal §9 XSLT / XSLTProcessor section whose complete definition is still tracked as open work in whatwg/dom#181, and Chromium's own IDL comments that Gecko's interface definition is the closest thing to a spec.

• Gecko (smaug----): “I think this is definitely worth trying” — with a hope that all browsers ship a console warning early, citing the Mutation Events removal (discussed 2011–12, removed 2025) where warnings were inconsistent (comment).
• WebKit (annevk): “cautiously supportive” — would probably wait for one implementation to fully remove support first, possibly moving sooner against a known reverse-trial origin list; suggested coordinating a console warning (comment).
• Web developers: vocal and negative on the standards issue — XSLT works with JS disabled, and the user-side attack-surface argument is contested; alternatives proposed include adopting safer-language XSLT libraries (comment). ChromeStatus records the position as “Negative” with that context.

Existing WPT coverage under wpt.fyi/results/dom/xslt will need to change or be removed as engines remove the feature (per the ChromeStatus record).

examples

Feature-detecting the removal and falling back to the polyfill (full contract on the XSLTProcessor page):

if (typeof XSLTProcessor === "undefined") {
  // Native XSLT is gone (Chrome 158+, or pre-stable channels now).
  // Load the WASM polyfill, which restores window.XSLTProcessor:
  await import("xslt-polyfill");
}
const processor = new XSLTProcessor();
processor.importStylesheet(xsltDoc);
const fragment = processor.transformToFragment(xmlDoc, document);

Migrating a PI-styled XML document with one line (details on the processing-instruction page):

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<page>
  <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>
  ...content...
</page>

browser compatibility

XSLT 1.0 is Baseline widely available (webstatus xslt, high since 2018-01-29). BCD support for api.XSLTProcessor as of 2026-07-29 — note that BCD has not yet recorded the deprecation (status.deprecated: false); the removal columns below come from the ChromeStatus record and removal guide, not BCD:

specifications

see also

• Chrome Platform Status — Deprecate and remove XSLT (API record; metrics: XSLTProcessor, XSL processing instructions)
• blink-dev — Intent to Deprecate and Remove: XSLT (Oct 2025) · Request for Deprecation Trial (Jun 2026)
• Chromium tracking bug 435623334
• MDN — XSLTProcessor (the API as it exists today; MDN does not document the removal plan — this page exists to fill that gap)
• gendn — XML parsing in Rust for non-XSLT scenarios (v151) (the sibling libxml2→Rust work, explicitly not a removal)
• XSLT polyfill · npm · Chrome Web Store extension · SaxonJS
• Chrome Platform Showcase — interactive demos for this feature