https://developer.chrome.com/docs/web-platform/deprecating-xslt

Skip to main content
Chrome for Developers

  * 

Docs

  * Build with Chrome
  * Learn how Chrome works, participate in origin trials, and build
    with Chrome everywhere.
  *  
    Web Platform
  *  
    Capabilities
  *  
    ChromeDriver
  *  
    Extensions
  *  
    Chrome Web Store
  *  
    Chromium
  *  
    Web on Android
  *  
    Origin trials
  *  
    Release notes

  * Productivity
  * Create the best experience for your users with the web's best
    tools.
  *  
    DevTools
  *  
    Lighthouse
  *  
    Chrome UX Report
  *  
    Accessibility

  * Get things done quicker and neater, with our ready-made
    libraries.
  *  
    Workbox
  *  
    Puppeteer

  * Experience
  * Design a beautiful and performant web with Chrome.
  *  
    AI
  *  
    Performance
  *  
    CSS and UI
  *  
    Identity
  *  
    Payments
  *  
    Privacy and security

  * Resources
  * More from Chrome and Google.
  *  
    All documentation
  *  
    Baseline
  *  
    web.dev
  *  
    PageSpeed Insights audit
  *  
    The Privacy Sandbox
  *  
    Isolated Web Apps (IWA)

Case studies Blog New in Chrome
[                    ]
/
  * English
  * Deutsch
  * Espanol - America Latina
  * Francais
  * Indonesia
  * Italiano
  * Nederlands
  * Polski
  * Portugues - Brasil
  * Tieng Viet
  * Turkce
  * Russkii
  * `bryt
  * l`rbyW@
  * frsy
  * hiNdii
  * baaNlaa
  * phaasaaaithy
  * Zhong Wen  - Jian Ti 
  * Zhong Wen  - Fan Ti 
  * Ri Ben Yu 
  * hangugeo

Sign in

  * Web Platform

Web Platform New releases WebGPU
[                    ]
Chrome for Developers

  * 

  * Docs
      + More
      + Web Platform
      + New releases
      + WebGPU
  * Case studies
  * Blog
  * New in Chrome

  * Chrome concepts
  * Chrome release channels
  * Chrome flags
  * Chrome variations
  * Understand origin trials
  * Third-party origin trials
  * Troubleshoot origin trials
  * Browser development
  * Chrome and Chromium
  * Blink rendering engine
  * Blink Intents
  * Features and APIs
  * Shipped to the web platform
      + Back/forward cache notRestoredReasons API
      + Compute Pressure API
      + Conditional focus API
      + Early Hints
      + Handwriting Recognition API
      + Long Animation Frames API (LoAF)
      + Navigation API
      + Page Lifecycle API
      + Picture-in-Picture for any Element
      + Prerender with the Speculation Rules API
      + Privacy-preserving screen sharing controls
      + Region Capture
      + Element Capture
      + Captured Surface Control
      + Tab sharing with Capture Handle
      + VirtualKeyboard API
      + View Transitions API
          o Overview
          o Same-Document View Transitions for SPA
          o Cross-Document View Transitions for MPA
      + WebGPU
  * Origin trials
      + Launch Handler API
      + Soft navigation experiment
      + Device-Bound Session Credentials API
      + AI trials
          o Translator API
          o Language Detector API
          o Summarizer API
  * Deprecating
      + Deprecating the unload event
      + Deprecating XSLT
  * No longer pursuing
      + Declarative link capturing
      + Storage foundation API
      + Notification triggers
      + Web bundles
  * Best practices
      + URL protocol handler registration for PWAs
      + Video processing with WebCodecs
  * Version History API
      + Guide
      + Reference
      + Examples
  * Sign up for origin trials
  * Chrome Platform status
  * Chromium projects

  * Build with Chrome
  * Web Platform
  * Capabilities
  * ChromeDriver
  * Extensions
  * Chrome Web Store
  * Chromium
  * Web on Android
  * Origin trials
  * Release notes
  * Productivity
  * DevTools
  * Lighthouse
  * Chrome UX Report
  * Accessibility
  * Workbox
  * Puppeteer
  * Experience
  * AI
  * Performance
  * CSS and UI
  * Identity
  * Payments
  * Privacy and security
  * Resources
  * All documentation
  * Baseline
  * web.dev
  * PageSpeed Insights audit
  * The Privacy Sandbox
  * Isolated Web Apps (IWA)

  * Home
  * 
    Docs
  * 
    Web Platform

Removing XSLT for a more secure browser Stay organized with
collections Save and categorize content based on your preferences.

Mason Freed
Mason Freed
  
Dominik Rottsches
Dominik Rottsches
  

Published: October 29, 2025

Chrome intends to deprecate and remove XSLT from the browser. This
document details how you can migrate your code before the removal in
late-2026.

Chromium has officially deprecated XSLT, including the XSLTProcessor
JavaScript API and the XML stylesheet processing instruction. We
intend to remove support from version 155 (November 17, 2026). The
Firefox and WebKit projects have also indicated plans to remove XSLT
from their browser engines. This document provides some history and
context, explains how we are removing XSLT to make Chrome safer, and
provides a path for migrating before these features are removed from
the browser.

Note: To further improve security, we also plan to migrate XML
parsing within Chrome from libxml2 to an XML parser written in Rust.

What is being removed?

There are two APIs in the browser that implement XSLT, and both are
being removed:

  * The XSLTProcessor class (for example, new XSLTProcessor()).
  * The XSLT Processing Instruction (for example, <?xml-stylesheet ...
    ?>).

Timeline For Chrome

Chrome has the following plan:

  * Chrome 142 (Oct 28, 2025): Early warning console messages added
    to Chrome.
  * Chrome 143 (Dec 2, 2025): Official deprecation of the API -
    deprecation warning messages begin to show in the console and in
    lighthouse.
  * Chrome 148 (March 10, 2026 Canary): Canary, Dev, and Beta
    releases begin disabling XSLT by default, as an early-warning.
  * Chrome 152 (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.
  * Chrome 155 (Nov 17, 2026): XSLT stops functioning on Stable
    releases, for all users other than Origin Trial and Enterprise
    Policy participants.**
  * Chrome 164 (Aug 17, 2027): Origin Trial and Enterprise Policy
    stop functioning. XSLT is disabled for all users.**

What is XSLT?

XSLT, or Extensible Stylesheet Language Transformations, is a
language used to transform XML documents, commonly into other formats
such as HTML. It uses an XSLT stylesheet file to define the rules for
this conversion, and an XML file containing the data used as input.

In browsers, when an XML file is received that links to an XSLT
stylesheet, the browser uses the rules in that stylesheet to
rearrange, format, and convert the raw XML data into a structured
page (often HTML) that can be rendered for the user.

For example, an XSLT stylesheet could take the following XML input:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

and this XSL stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="/page/message">
    <body>
      <p>Message: <xsl:value-of select="."/></p>
    </body>
  </xsl:template>
</xsl:stylesheet>

and process them into this HTML for the browser to display: HTML

<body>
  <p>Message: Hello World.</p>
</body>

In addition to the XSL processing instruction shown in the previous
example, there's also the XSLTProcessor JavaScript API which can be
used to process local XML documents with local XSLT stylesheets.

History of XSLT

XSLT was recommended by the World Wide Web Consortium (W3C) on
November 16, 1999, as a language for transforming XML documents into
other formats, most commonly HTML for display in web browsers. Before
the official 1.0 recommendation, Microsoft took an early initiative
by shipping a proprietary implementation based on a W3C working draft
in Internet Explorer 5.0, released in March 1999. Following the
official standard, Mozilla implemented native XSLT 1.0 support in
Netscape 6 in late 2000. Other major browsers, including Safari,
Opera, and later Chrome, also incorporated native XSLT 1.0
processors, making client-side XML-to-HTML transformations a viable
web technology in the early 2000s.

The XSLT language itself continued to evolve, with the release of
XSLT 2.0 in 2007 and XSLT 3.0 in 2017, which introduced powerful
features like regular expressions, improved data types, and the
ability to process JSON. Browser support, however, stagnated. Today,
all major web browser engines only provide native support for the
original XSLT 1.0 from 1999. This lack of advancement, coupled with
the rise of the use of JSON as a wire format, and JavaScript
libraries and frameworks (like jQuery, React, and Vue.js) that offer
more flexible and powerful DOM manipulation and templating, has led
to a significant decline in the use of client-side XSLT. Its role
within the web browser has been largely superseded by these
JavaScript-based technologies.

Why does XSLT need to be removed?

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. For example,
security audits and bug trackers have repeatedly identified
high-severity vulnerabilities in these parsers (e.g., CVE-2025-7425
and CVE-2022-22834, both in libxslt). 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. The security risks of maintaining this brittle, legacy
functionality far outweighs its limited modern utility.

Furthermore, the original purpose of client-side XSLT--transforming
data into renderable HTML--has been superseded by safer, more
ergonomic, and better-maintained JavaScript APIs. Modern web
development relies on things like the Fetch API to retrieve data
(typically JSON) and the DOMParser API to safely parse XML or HTML
strings into a DOM structure within the browser's secure JavaScript
sandbox. Frameworks like React, Vue, and Svelte then manage the
rendering of this data efficiently and securely. This modern
toolchain is actively developed, benefits from the massive security
investment in JavaScript engines, and is what virtually all web
developers use today. Indeed, only about 0.02% of web page loads
today actually use XSLT at all, with less than 0.001% using XSLT
processing instructions.

This is not a Chrome or Chromium-only action: the other two major
browser engines also support the removal of XSLT from the web
platform: WebKit, Gecko.

For these reasons, deprecating and removing XSLT reduce the browser's
attack surface for all users, simplify the web platform, and allow
engineering resources to be focused on securing the technologies that
actually power the modern web, with no practical loss of capability
for developers.

Improving XML parsing security

Similar to the severe security issues in libxslt, severe security
issues were recently reported against libxml2 which is used in
Chromium for parsing, serialization and testing the well-formedness
of XML. To address future security issues with XML parsing In
Chromium we plan to phase out the usage of libxml2 and replace XML
parsing with a memory-safe XML parsing library written in Rust.
Importantly, we won't be removing XML from the browser; only XSLT is
being considered for removal here. We intend to ensure that replacing
libxml2 is entirely transparent to web developers.

How to migrate

There are a few alternative paths for migration.

JSON

For sites that are fully built on XML and XSL there is no
one-size-fits all way to make the transition. Migration options
include moving the XSLT processing pipeline to the server side and
sending down the rendered HTML to the client, or migrating
server-side XML API endpoints to JSON, and performing client-side
rendering using JavaScript to transform JSON into HTML DOM and CSS.

Client-side XSLT in JavaScript

There are a few client-side (JavaScript-based) XSLT libraries
available, but the largest by far is produced by Saxonica (view the
comprehensive documentation for Saxonica). The implementation goes
well beyond the XSLT 1.0 implementation in web browsers, implementing
full support for the latest v3.0 standard, and eventually the
in-progress v4.0 standard.

Polyfill

There is a polyfill that attempts to allow existing code, which
depends on web browsers' implementations of XSLT 1.0, to continue
functioning, while not using native XSLT features from the browser.
The polyfill is located on GitHub.

The polyfill contains a functional WASM-based polyfilled replacement
for the XSLTProcessor class, so existing JavaScript code can continue
to work as-is:

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

The polyfill also provides an automatic utility function for an easy
way to replace XML documents that use XSLT processing instructions:

For an original demo.xml file like this:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

One line can be added to invoke the polyfill and transform the
document with the referenced XSLT stylesheet:

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

In this case, the new <script> element loads the polyfill, which
detects the XML document type and the XSLT processing instruction and
transparently loads it, replacing the document.

Extension

There's also a Chrome extension that can be added to supported
browsers, which will apply the same XSLT polyfill to all raw XML
pages that contain XSLT processing instructions or calls to
XSLTProcessor. This can be used for applications where the source XML
or XSLT cannot be changed, to maintain functionality.

In particular, when XSLT is disabled, Chrome now shows a warning
banner that links directly to an extension search page, to help users
locate an extension:

The message shown in Chrome when xslt is detected.

Specific use cases

In the discussion in HTML standards, several concrete use cases were
identified. This section talks specifically about each of them, to
recommend paths forward for developers publishing XML resources that
use XSLT today.

RSS and Atom Feeds

In many existing RSS or Atom feeds, XSLT is used to make raw XML
feeds human-readable when viewed directly in a browser. The primary
use case is that when a user accidentally clicks on a site's RSS feed
link, rather than pasting that link into their RSS reader, they get a
formatted HTML response that they can read, rather than the raw XML
itself.

There are two paths forward for this use case. The "standard" HTML
way to do this is to add <link rel="alternate" type="application/
rss+xml"> to an (HTML-based) site, rather than adding an explicit
(user-visible) <a href="something.xml"> that users might accidentally
click. This solution allows RSS readers to find the feed if a user
pastes in just the website URL, but it also allows human users to see
the regular HTML content without getting confused by a link to an XML
resource. This also follows the normal web paradigm that HTML is for
humans and XML is for machines. Of course this doesn't solve the case
where a user just "has" an RSS link from somewhere, and they paste it
into their web browser (rather than their RSS reader).

When that solution isn't wanted, the polyfill offers another path. As
mentioned previously, the RSS/Atom XML feed can be augmented with one
line, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/
1999/xhtml"></script>, which will maintain the existing behavior of
XSLT-based transformation to HTML. That shouldn't affect RSS reader's
ability to continue parsing the XML, since the <script> is a direct
child of the root element.

API output for embedded devices

Some commercial embedded devices measure or otherwise generate XML
data for consumption by users on the local network. Some of these
devices do this by generating a single XML data feed that uses XSLT
to transform it into a human-readable HTML format. That allows the
API to be directly viewed in a browser without needing additional
code on the device or in the browser.
Since this is a very application specific use case, the shape of the
solution might vary. For applications where the source code of the
embedded device can be updated, any of the options described
previously (JSON, Polyfill) could work. In particular, however, many
such devices are difficult or impossible to update, for various
reasons. In that case, the extension is likely the best option, since
it allows client browsers to continue to read the data in exactly the
same way, without modifying the device.

Lazy templating for web sites

Web developers sometimes use XSLT on the client side to apply
presentation markup to semantic markup, functioning as a lazy
templating language that is separate from the JavaScript ecosystem.

There are two solutions to this more general problem. For an existing
site built in this way, the easiest solution is likely just to add
the polyfill to maintain existing functionality. Or perhaps perform
the XSLT transformation on the server side, and serve the resulting
HTML to the client, rather than the raw XML. The more long-term
solution for such properties would be to migrate to a more modern
JavaScript or JSON-based framework.

If you encounter a specific problem in Chrome related to this XSLT
deprecation, report a bug here.

Except as otherwise noted, the content of this page is licensed under
the Creative Commons Attribution 4.0 License, and code samples are
licensed under the Apache 2.0 License. For details, see the Google
Developers Site Policies. Java is a registered trademark of Oracle
and/or its affiliates.

Last updated 2025-10-29 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my
problem","solvedMyProblem","thumb-up"],
["Other","otherUp","thumb-up"]],[["Missing the information I
need","missingTheInformationINeed","thumb-down"],["Too complicated /
too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of
date","outOfDate","thumb-down"],["Samples / code
issue","samplesCodeIssue","thumb-down"],
["Other","otherDown","thumb-down"]],["Last updated 2025-10-29 UTC."],
[],[]]

  * Contribute

      + File a bug
      + See open issues
  * Related content

      + Chromium updates
      + Case studies
      + Archive
      + Podcasts & shows
  * Follow

      + @ChromiumDev on X
      + YouTube
      + Chrome for Developers on LinkedIn
      + RSS

  * Terms
  * Privacy
  * Manage cookies

  * English
  * Deutsch
  * Espanol - America Latina
  * Francais
  * Indonesia
  * Italiano
  * Nederlands
  * Polski
  * Portugues - Brasil
  * Tieng Viet
  * Turkce
  * Russkii
  * `bryt
  * l`rbyW@
  * frsy
  * hiNdii
  * baaNlaa
  * phaasaaaithy
  * Zhong Wen  - Jian Ti 
  * Zhong Wen  - Fan Ti 
  * Ri Ben Yu 
  * hangugeo