Chrome’s XSLT Removal Deadline Arrives in November

MOUNTAIN VIEW, Calif. — Legacy web standards rarely die with a dramatic explosion; they usually fade away quietly while developers ignore deprecation console warnings until something breaks entirely.

Exactly one year after Google engineers Mason Freed and Dominik Röttsches first published Chrome’s official deprecation roadmap, that quiet exit is turning into a hard deadline.

Native support for XSLT in Google Chrome is officially scheduled to stop functioning on stable releases with version 158 on November 17, 2026.

Key Takeaways

• Imminent Removal Date: XSLT processing and the XSLTProcessor JavaScript API will stop working in Chrome Stable on November 17, 2026, matching similar removal plans across Firefox and WebKit.
• Memory Safety Vulnerabilities: Google is stripping out XSLT to shrink the browser’s attack surface, citing persistent high-severity buffer overflow bugs in aging C/C++ parsers like libxslt.
• Migration Paths & Polyfills: Developers managing legacy XML feeds or embedded device interfaces must transition to server-side rendering, JSON APIs, or adopt open-source WASM XSLT polyfills.

The writing has been on the wall for client-side XSLT (Extensible Stylesheet Language Transformations) for years. Introduced way back in 1999 as a W3C recommendation to transform raw XML data into renderable HTML inside the browser, the technology was widely adopted during the early 2000s.

But as the modern web shifted decisively toward JSON wire formats, asynchronous JavaScript fetch requests, and frontend frameworks like React, Vue, and Svelte, client-side XSLT usage withered into complete obscurity.

According to telemetry data cited by Chromium maintainers, roughly 0.02% of total web page loads currently touch XSLT at all, with less than 0.001% relying on XML-stylesheet processing instructions. Yet despite that microscopic usage share, the underlying C/C++ codebases powering these transformations—namely libxslt—continue to generate high-severity memory safety vulnerabilities.

The Chromium team laid out the security rationale behind the purge in stark terms:

“The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. The security risks of maintaining this brittle, legacy functionality far outweighs its limited modern utility.”

The Rollout and Enterprise Safety Nets

Google’s deprecation timeline has given enterprise administrators and legacy developers an extended runway to audit their codebases. Early console warnings began appearing back in late 2025, followed by Canary and Beta channels disabling the feature by default earlier this year.

For large organizations trapped using internal applications that still depend on native XSLT, Google built temporary escape hatches:

• Enterprise Policy (EP): Rolled out in March 2026 (Chrome 146), allowing enterprise administrators to test disabling XSLT early or maintain temporary compatibility past the removal date.
• Origin Trials (OT): Launched in August 2026 (Chrome 152), giving specific web domains temporary authorization to run native XSLT past the cutoff.
• Hard Cutoff Date: For standard users, Chrome 158 on November 17, 2026, will permanently disable native execution, with both Enterprise Policies and Origin Trials completely expiring by August 17, 2027.

Crucially, Google is drawing a strict line between XSLT and basic XML parsing. While XSLT execution is getting wiped out, the browser still needs to parse XML.

To secure that side of the equation, Chromium is concurrently migrating its XML parsing layer from the aging libxmll2 library over to a memory-safe XML parsing library written entirely in Rust.

How Developers Can Migrate

For the tiny fraction of developers still publishing raw XML feeds transformed via client-side XSLT—such as legacy RSS/Atom feed aesthetic wrappers or embedded local networking hardware—the sudden removal requires an operational workaround.

Developers have three primary paths forward:

1. Server-Side Rendering: Shift the XSLT transformation pipeline entirely to backend servers, serving pre-rendered HTML down to the client instead of raw XML.
2. WASM Polyfills: Implement Saxonica’s comprehensive XSLT libraries or drop a lightweight WebAssembly XSLT polyfill script directly into the XML root.
3. Browser Extensions: Install community-built Chrome extensions designed to intercept raw XML pages and apply client-side transformation scripts on devices where source code cannot be patched. Extensions such as XSLT Polyfill, XSLT Prism – XSLT Polyfill, XML Viewer & XSLT Tester and of course XSLT Browser Support – XSLT Polyfill, XML Viewer & Tester.

With Firefox and WebKit engines mirroring Google’s removal plans, client-side XSLT 1.0 is officially reaching the end of the road across the entire modern web platform.

If your internal tools or legacy public feeds still depend on browser-native stylesheet transformations, you have roughly a month to patch your pipelines before Chrome 158 locks the door.