Intent to Deprecate and Remove: Deprecate and remove XSLT

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

None

Summary

XSLT v1.0, 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+React.

Chromium uses the libxslt library to process these transformations, and libxslt was unmaintained 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 would like to deprecate and remove XSLT. WHATWG decided to move XSLT deprecation to stage 3, indicating broad agreement. Both other browser engines are also planning to deprecate XSLT. The proposed timeline for Chromium is to deprecate in M143, remove in M155 (except for Origin Trial and Enterprise Policy users), and discontinue the Origin Trial and Enterprise Policy in M164. See below for more details.

Blink component

Blink>XML

Web Feature ID

xslt

Motivation

Security risks for all users outweigh the very small usage of this feature on the open web.

Usage of the JS XSLTProcessor API is fairly volatile, registering somewhere between 0.01% and 0.1% of page loads, averaging around 0.05% over time. These numbers are above the typical 0.001% deprecation threshold. Again, we feel that the increased potential for breakage is balanced by the reduced security risk to 100% of Chromium users. And we are doing everything we can to mitigate this breakage and be proactive in reaching out to potentially affected sites and particularly libraries that might account for significant chunks of the overall usage. In addition, several sites we surveyed that use XSLTProcessor have feature detection code with fallbacks to JS libraries like Saxonica. Of the ~220 sites we've surveyed so far, roughly 72% of them are still functional even with XSLT disabled.

The usage of declarative XSL Processing Instructions is significantly lower, around 0.001% for the last few years. This is at or below the safe deprecation threshold.

Initial public proposal

https://github.com/whatwg/html/issues/11523

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Removal of this feature constitutes a compat risk, since sites that use XSLT may 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 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 single-line 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, 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, many of whose participants 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.

Deprecation/Removal Plan

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 and Enterprise Policy go live for testing. These allow sites and enterprises to continue using features past the removal date.

- M155 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.

- M164 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.

Debuggability

None

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

No milestones specified

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

[j.j.]

see also

https://github.com/mozilla/standards-positions/issues/1287

[Vladimir Levin]

Hey, we discussed this at API owners today.

Generally, we're supportive of removing XSLT. As for the plan, I think it would be best if we disable this in Canary as soon as possible (via Finch) to find real breakages that we may be missing. Further, disabling in Beta and Dev shortly after to get more data is also good. 

LGTM1 for the plan with the above changes. We would like you to check in with results of Canary / Dev / Beta and warning steps in 3 months to see how we proceed further.

Thanks,

Vlad

On Monday, October 27, 2025 at 9:37:51 AM UTC-4 j.j. wrote:

see also

https://github.com/mozilla/standards-positions/issues/1287

[Chris Harrelson]

LGTM2 for the steps Vlad mentioned.

--
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/4aa38aaf-702e-41d6-91f1-7ba8b18ff675n%40chromium.org.

[Mason Freed]

On Wed, Oct 29, 2025 at 8:42 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2 for the steps Vlad mentioned.

On Wed, Oct 29, 2025 at 8:38 AM Vladimir Levin <vmp...@chromium.org> wrote:

Generally, we're supportive of removing XSLT. As for the plan, I think it would be best if we disable this in Canary as soon as possible (via Finch) to find real breakages that we may be missing. Further, disabling in Beta and Dev shortly after to get more data is also good. 

LGTM1 for the plan with the above changes. We would like you to check in with results of Canary / Dev / Beta and warning steps in 3 months to see how we proceed further.

Yep, that makes sense. I was planning to do that later in the process (M148 in my plan) but I like the idea of doing it ASAP - will do. I missed the M143 branch, and I think to do that responsibly I'd want to include a customized console message for the pre-stable channels. So I'll get that landed in M144, and report back here after it goes through the channels.

Thanks,

Mason

[Mike Taylor]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9BLUzVTz_-ioPp0ie%2Bn3g4gbS4wo5LvC3ZQLbzRzUa%2Bg%40mail.gmail.com.

[Mason Freed]

Thank you all, I appreciate it. I'll be back in a few months with an update on the pre-stable experiment, plus any other feedback I've received.

Thanks,

Mason

[PhistucK]

Just to verify, this will not remove document.evaluate which depends on XPath - right? It is the only way to natively find an element by text and other advanced combinations as far as I know.

☆PhistucK

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjFNC8jF%2BFchRke6SFnV-n6BUTe41qD0Y%3D1OpcxWeDNEA%40mail.gmail.com.

[Mason Freed]

On Thu, Oct 30, 2025 at 3:44 PM PhistucK <phis...@gmail.com> wrote:

Just to verify, this will not remove document.evaluate which depends on XPath - right? It is the only way to natively find an element by text and other advanced combinations as far as I know.

Yep, great question. We are absolutely *not* removing `document.evaluate()` or XPath generally. That's part of XML, not XSLT. (Side note, there are other native methods such as NodeIterator / TreeWalker, but those obviously don't offer such a compact way to search for text content.)

Thanks,

Mason

[tbodt]

Was shipping the xslt polyfill as part of the browser considered? That would seem to satisfy everyone

[optimi zix]

Well technically XPath is an autonous language and is a strong basis of XSLT

(1) It would help to clarify XPath status 
(2) it would be helpful to know if there is way to reactivate those API if we solve the security issues (via rust implementation ?)

[Mason Freed]

On Sat, Nov 1, 2025 at 2:08 PM optimi zix <opti...@gmail.com> wrote:

Well technically XPath is an autonous language and is a strong basis of XSLT

(1) It would help to clarify XPath status 

That's fair! To clarify, we are absolutely *not* removing `document.evaluate()` or XPath generally.

 

(2) it would be helpful to know if there is way to reactivate those API if we solve the security issues (via rust implementation ?)

By "those APIs" I assume you mean XSLT. If so, unfortunately that's not our current plan, no.

Thanks,

Mason

[xeere]

I have a statically hosted website and I should like to add formatting to my RSS feed so that other people will get a pleasant experience when they click on the link. This seems impossible without XSLT. Perhaps I'm just old fashioned, but I think generally browser should support the basic technologies you'd need to write HTML documents and serve them to people.

[Chris Harrelson]

On Mon, Nov 10, 2025 at 8:21 AM xeere <xeer...@gmail.com> wrote:

I have a statically hosted website and I should like to add formatting to my RSS feed so that other people will get a pleasant experience when they click on the link. This seems impossible without XSLT.

Hi,

It's not impossible. To achieve this, you can include the script for the XSLT polyfill mentioned in this thread in the response from your server.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/550d1172-6854-4383-8612-7b5a5112e4fan%40chromium.org.

[xeere]

If the solution is this simple, why are users being expected to implement it and potentially break the standards compliance of their XML documents? Surely the browser could be made to dispatch this polyfill whenever it encounters a document with the stylesheet tag.

[Chris Harrelson]

On Tue, Nov 11, 2025 at 10:08 AM xeere <xeer...@gmail.com> wrote:

If the solution is this simple, why are users being expected to implement it and potentially break the standards compliance of their XML documents? Surely the browser could be made to dispatch this polyfill whenever it encounters a document with the stylesheet tag.

Unfortunately, for lots of technical reasons, integrating it directly into the browser (and maintaining thereafter) is much harder than it might seem.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKmAaPO%3D-mep7dgvgd8Pe%3DKONCGLm6BJYaA-y8Q-T-hO5Owrvw%40mail.gmail.com.

[Mason Freed]

On Wed, Oct 29, 2025 at 10:26 AM Mason Freed <mas...@chromium.org> wrote:

Generally, we're supportive of removing XSLT. As for the plan, I think it would be best if we disable this in Canary as soon as possible (via Finch) to find real breakages that we may be missing. Further, disabling in Beta and Dev shortly after to get more data is also good. 

LGTM1 for the plan with the above changes. We would like you to check in with results of Canary / Dev / Beta and warning steps in 3 months to see how we proceed further.

It's taken a bit longer than I expected, but I'm finally back with the requested update. I've added console warnings starting in M142 (Oct, 2025), and disabled XSLT completely in all pre-stable channels (Canary/Dev/Beta) starting in M145 (Dec, 2025). I also published a blog post, added XSLT to the enterprise release notes, and proactively reached out to several enterprises and public sites. As a result of that outreach, I've received a grand total of two Chromium bugs (one was a bug in Chrome's feature flag implementation, and one was a bug in the polyfill). Both have been fixed. I've also had two other private contractors (for enterprise/government clients) reach out to me privately, and those conversations seem to be going well. In both cases, they are in the process of migrating away from client-side XSLT. The polyfill repo has also seen strong engagement, with many issues filed and fixed.

Overall, while the community is definitely feeling some migration pain, I'm trying to stay on top of it and ensure the polyfill is a functional replacement.

If the Blink API owners have any questions or concerns, please let me know. Otherwise, I will stick to the plan, targeting M152 to start the deprecation trial, and M155 to disable the feature by default. 

Thanks,

Mason

[Mike Taylor]

On 2/20/26 2:14 p.m., Mason Freed wrote:

On Wed, Oct 29, 2025 at 10:26 AM Mason Freed <mas...@chromium.org> wrote:

Generally, we're supportive of removing XSLT. As for the plan, I think it would be best if we disable this in Canary as soon as possible (via Finch) to find real breakages that we may be missing. Further, disabling in Beta and Dev shortly after to get more data is also good. 

LGTM1 for the plan with the above changes. We would like you to check in with results of Canary / Dev / Beta and warning steps in 3 months to see how we proceed further.

It's taken a bit longer than I expected, but I'm finally back with the requested update. I've added console warnings starting in M142 (Oct, 2025), and disabled XSLT completely in all pre-stable channels (Canary/Dev/Beta) starting in M145 (Dec, 2025). I also published a blog post, added XSLT to the enterprise release notes, and proactively reached out to several enterprises and public sites. As a result of that outreach, I've received a grand total of two Chromium bugs (one was a bug in Chrome's feature flag implementation, and one was a bug in the polyfill). Both have been fixed. I've also had two other private contractors (for enterprise/government clients) reach out to me privately, and those conversations seem to be going well. In both cases, they are in the process of migrating away from client-side XSLT. The polyfill repo has also seen strong engagement, with many issues filed and fixed.

Overall, while the community is definitely feeling some migration pain, I'm trying to stay on top of it and ensure the polyfill is a functional replacement.

If the Blink API owners have any questions or concerns, please let me know. Otherwise, I will stick to the plan, targeting M152 to start the deprecation trial, and M155 to disable the feature by default. 

Thanks Mason for the detailed update, and for doing the work to land this removal safely (or as safe as possible). No concerns with sticking to the plan.

[Mason Freed]

On Thu, Sep 3, 2026 at 5:57 AM Khristine Belandres <khrist...@gmail.com> wrote:

Given the 2-week release starting M152 (Aug 25, 2027), is the plan also changing specifically for M155 and M164? Do we follow the dates or the release version?

- M155 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.

- M164 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.

Thanks for highlighting that! When the 2 week cycle was announced, I updated the chromestatus entry accordingly (look for either "Experiment goals" or "Rollout steps" on that page) and the blog post timeline. The new milestones are M158 and M176, respectively; they follow the original dates, not the old milestone numbers. I suppose I should have emailed this thread, also!

Thanks,

Mason

[Khristine Belandres]

Given the 2-week release starting M152 (Aug 25, 2027), is the plan also changing specifically for M155 and M164? Do we follow the dates or the release version?

- M155 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.

- M164 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.

On Saturday, October 25, 2025 at 5:58:49 AM UTC+8 Mason Freed wrote:

[Mason Freed]

I'm following up on this intent, since the branch point for M157 is coming up on Oct 12, after which Canary will be M158. The plan is to disable XSLT by default starting in M158, so I have flipped the API owners review bit for this removal. Here are some updates related to this deprecation:

- XSLT was disabled by default in all pre-stable channels starting in M145 (154 for WebView).
- A user-visible warning (with significant community feedback and fixes) is present on XSLT-transformed pages (and XSLTProcessor-transformed documents) since M156 (just for the last two milestones before removal).
- The Enterprise Policy has been available since M146 (allowing both opt-back-in, and early-opt-out). This deprecation was also published in the enterprise release notes starting Oct, 2025.
- The Deprecation Trial has been available since M152 (allowing only opt-back-in).
- Lots of great feedback and bug fixes on the polyfill and Chrome extension. Both seem to be rather functional across most use cases.
- When XSLT is disabled in the browser, a user-visible warning links directly to an extension search, where the polyfill extension shows up. So in still-broken cases, users have recourse.
- CAP Alerts (emergency alerts) are exempted from the initial default-removal, because they can't use deprecation trials. They will have a user-visible warning banner, and will be disabled in the final removal milestone of M176.
- The HTML standard and DOM standard now mark XSLT as "do not use", and CanIUse says "Discouraged".
- I've had lots of conversations (public and private) with folks who are migrating away from the browser-native feature. All have been resolved, at least as far as I can tell.
- The use counters are still roughly flat. This is not a surprise - deprecations usually make counters go up, in my experience.

In my view, we should proceed with the removal now, keeping to the published schedule. I'm requesting API owner approval to disable XSLT by default in M158.

Thanks,

Mason

[Chris Harrelson]

LGTM1

Thanks for the diligent work to make this API removal as smooth as possible. I think the risk is low, and in addition security risks of not removing the API are high and growing.

--
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%3DNeDgUxoR_bnwAW_6GAXRJ3tx401GKKdMee1E%3DkU%2BxPcVtQg%40mail.gmail.com.

[Mike Taylor]

LGTM2. +1 - thanks Mason for (nearly) achieving the near-impossible. Good luck with the final steps!

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8NAKebB6QQ%2BRJBe_ec1TAYu9OP%3Dii5Meq4Ne_2ZJfyVA%40mail.gmail.com.

[Daniel Bratell]

LGTM3

It is a bit strange sending the LGTM3 here when I was one of the people that many, many years ago claimed that removal could not be done but I guess persistence sometimes pays off. I'm impressed.

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8eb9aa16-e8e9-43fa-bc68-deae1da19a27%40chromium.org.

[Mason Freed]

Thank you all! I appreciate it.

I also appreciate the XSLT community, which has been working to migrate off this tech over the last year. I know this has been a monumental headache, and I’m so grateful to everyone who suffered through it.

Thanks,

Mason