Request for Deprecation Trial: Deprecate and remove XSLT

[Mason Freed]

Standard template below. But note that this is a request for a deprecation trial, starting M152 and going until M175. That's inline with the posted timeline, allowing affected sites plenty of extra time to migrate away from XSLT, in case they cannot migrate before the feature is disabled by default in M158 (Nov, 2026). Also note that this deprecation trial is being requested several milestones early to allow plenty of time to test before the feature is disabled.

 

-----

Contact emails

mas...@chromium.org

Explainer

No information provided

Specification

No information provided

Design docs

No information provided
https://github.com/whatwg/html/issues/11523

Summary

[XSLT v1.0](https://www.w3.org/TR/xslt-10/), which all browsers adhere to, was standardized in 1999. In the meantime, XSLT has evolved to v2.0 and v3.0, adding features, and growing apart from the old version frozen into browsers. This lack of advancement, coupled with the rise of JavaScript libraries and frameworks that offer more flexible and powerful DOM manipulation, has led to a significant decline in the use of client-side XSLT. Its role within the web browser has been largely superseded by JavaScript-based technologies, such as JSON and React. Chromium uses the **libxslt** library to process these transformations, and [libxslt was unmaintained](https://discourse.gnome.org/t/stepping-down-as-libxslt-maintainer/27615) for ~6 months of 2025. Libxslt is a complex, aging C codebase of the type notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. For these reasons, Chromium (along with both other browser engines) plans to deprecate and remove XSLT from the web platform. For more details, see this [Chrome for Developers article](https://developer.chrome.com/docs/web-platform/deprecating-xslt).

Blink component

Blink>XML

Web Feature ID

xslt

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

The tentative deprecation/removal plan would be as follows: - M142 (Oct 28, 2025): Early warning console messages added to Chrome. - M143 (Dec 2, 2025): Official deprecation of the API - deprecation warning messages begin to show in the console and in lighthouse. - M148 (March 10, 2026 Canary): Canary, Dev, and Beta releases begin disabling XSLT by default, as an early-warning. - M152 (Aug 25, 2026): Origin Trial (OT) and Enterprise Policy (EP) go live for testing. These allow sites and enterprises to continue using features past the removal date. - M158 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants. - M176 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.

Risks

Interoperability and Compatibility

Removal of this feature constitutes a compat risk, since sites that use XSLT will stop working when the feature is removed. Mitigations include a very long deprecation window, a polyfill, lots of outreach, and both origin trials and enterprise policies to allow sites even more time to migrate. The polyfill (https://github.com/mfreed7/xslt_polyfill) is specifically built to mimic the existing behavior of Chrome as closely as possible. In most cases, it is a single-line drop-in fix for a lack of XSLT in the browser. According to my analysis, about 75% of sites that hit the use counter don't appear to be visibly broken. Of the 25% that do appear broken in some way (e.g. some components not rendering, or raw XML output instead of transformed HTML), 82% have their functionality restored by the addition of the polyfill. Of the 18% that can't use the polyfill, the primary reason seems to be CORS restrictions, as detailed in the polyfill documentation. And even if site owners take no action, individual users can install the browser extension(https://github.com/mfreed7/xslt_extension), which uses the polyfill, to get back full functionality.

Gecko: Positive (https://github.com/whatwg/html/issues/11523#issuecomment-3149788558)

WebKit: Positive (https://github.com/whatwg/html/issues/11523#issuecomment-3149280766)

Web developers: Negative (https://github.com/whatwg/html/issues/11523#issuecomment-3150969971) Existing users of XSLT are understandably negative on this removal, and have been very vocal about it on the standards issue and elsewhere. There are also mixed/positive reactions from some folks in the public discussions, who seem to agree with the removal of XSLT from browsers. But the average/overall developer opinion (as measured by comments on public threads) is negative. Various public discussions: - https://news.ycombinator.com/item?id=44952185 - https://www.reddit.com/r/programming/comments/1mxdm22/xslt_removal_will_break_multiple_government_and/ - https://news.ycombinator.com/item?id=44987346 - https://news.ycombinator.com/item?id=44987552 - https://news.ycombinator.com/item?id=44987239 - https://news.ycombinator.com/item?id=44909599

Other signals:

Activation

See above - the polyfill and extension will ease the migration burden.

Security

This removal constitutes a big win for security, in that it removes a highly-vulnerable external library from Chromium.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

In the same way that this poses a compat risk on the open web, it poses a risk for WebView applications.

Ongoing technical constraints

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
These tests verify the functionality of XSLT. They will need to be changed/removed: https://wpt.fyi/results/dom/xslt

Flag name on about://flags

XSLT

Finch feature name

XSLT

Requires code in //chrome?

False

Tracking bug

https://crbug.com/435623334

Estimated milestones

Origin trial desktop first	152
Origin trial desktop last	175
DevTrial on desktop	143
Origin trial Android first	152
Origin trial Android last	175
DevTrial on Android	143
Origin trial WebView first	152
Origin trial WebView last	175
Rollout step 1	176
Rollout step 2	143
Rollout step 3	152
Rollout step 4	158

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4709671889534976?gate=5148216907661312

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhO%3D2mNq8QyzU5Ah9z8FR6pO9tct9G_prKD6bdtAE7cwA%40mail.gmail.com.