"XSLTProcessor is not defined": why it happens and how to fix it

The error

In Chrome's developer console the message reads:

Uncaught ReferenceError: XSLTProcessor is not defined
    at renderReport (app.js:42:21)

Firefox uses the same wording for a missing global. Safari's JavaScript engine phrases a missing global as ReferenceError: Can't find variable: XSLTProcessor. Whatever the wording, the cause is the same: the script refers to a global the browser does not define, so execution stops at that line and anything the transform was meant to draw never appears.

Why it happens

Chrome is removing XSLT, both the processing of <?xml-stylesheet?> in XML documents and the XSLTProcessor API in JavaScript. The full timeline is in our Chrome XSLT removal guide; the dates that matter here:

• December 2025: Chrome Canary, Dev and Beta turn XSLT off by default. Developers on pre-release channels see the error first.
• November 17, 2026: Chrome Stable stops providing XSLT, apart from sites in the origin trial and browsers managed with the XSLTEnabled policy.
• August 17, 2027: the origin trial and the policy end; no Chrome has the API.

Chrome's notice adds that the Firefox and WebKit projects have indicated plans to remove XSLT too. Neither had a date as of October 2026, but code that assumes XSLTProcessor exists is living on borrowed time in every browser.

How to confirm it

Check for the API before using it. This line is safe in any browser, because typeof does not throw on an undeclared name:

const hasXslt = typeof XSLTProcessor !== 'undefined'
console.log('XSLTProcessor available:', hasXslt)

To reproduce the failure in a Chrome that still has XSLT, open chrome://flags/#xslt, set XSLT to Disabled and relaunch. Your page now behaves the way it will for every Chrome Stable user after November 17, 2026. Set the flag back to Default when you are done.

Correct XSLTProcessor usage, for reference

Most code that hits this error follows the same pattern: parse the XML and the stylesheet, import the stylesheet, set parameters, transform into a fragment.

const parser = new DOMParser()
const xml = parser.parseFromString(xmlText, 'application/xml')
const xsl = parser.parseFromString(xslText, 'application/xml')

const processor = new XSLTProcessor()
processor.importStylesheet(xsl)
processor.setParameter(null, 'currency', 'EUR')

const fragment = processor.transformToFragment(xml, document)
if (fragment) {
  document.getElementById('report').replaceChildren(fragment)
} else {
  console.error('The transform failed')
}

Note the if (fragment) check. Chrome returns null from transformToFragment when a transform fails, rather than throwing, so robust code always tests the result.

Fixes for site owners, ranked

If you control the site, fix it there: every visitor benefits and nobody has to install anything.

1. Transform on the server. Run the stylesheet where the data comes from (libxslt, Saxon, .NET, Java and PHP all can) and send finished HTML. This removes the browser dependency entirely, and it is the only option that also opens the door to XSLT 2.0 or 3.0.
2. Precompute the HTML. If the XML changes rarely, run the transform at build or publish time and serve static HTML. No runtime XSLT anywhere.
3. Load a JavaScript polyfill library. The open-source xslt-polyfill library, which Chrome's deprecation notice points to, implements XSLTProcessor with libxslt compiled to WebAssembly. Add its script to your pages and existing code keeps working. Read its README for its limits: for example, resources pulled in by xsl:import or document() are fetched under normal CORS rules.
4. Join the origin trial. Registering your origin for Chrome's XSLT origin trial keeps the native API on your site until August 17, 2027. Use the time to ship one of the fixes above.

Whichever you choose, guard the call so the page fails gracefully instead of throwing. This sketch transforms locally when the API exists and asks the server for the same view when it doesn't:

async function renderReport(xml, xsl, target) {
  if (typeof XSLTProcessor !== 'undefined') {
    const processor = new XSLTProcessor()
    processor.importStylesheet(xsl)
    const fragment = processor.transformToFragment(xml, document)
    if (fragment) {
      target.replaceChildren(fragment)
      return
    }
  }
  // No XSLT in this browser (or the transform failed):
  // fetch the same report rendered on the server.
  const response = await fetch('/reports/latest.html')
  if (!response.ok) throw new Error(`Report request failed: ${response.status}`)
  target.innerHTML = await response.text()
}

Fixes for users and IT teams

If you use the web app but can't change it, the fix has to live in your browser.

• XSLT Prism. XSLT Prism is an XSLT polyfill for Chrome that can restore XSLTProcessor on the sites you pick. When a site tries to use the API, the toolbar badge shows API. Open the popup on that site and turn on XSLTProcessor for this site; then press "Reload the page to apply" and the API is available. Settings can also switch it on for every site, or off entirely.
• The XSLTEnabled policy. On managed machines, administrators can set the XSLTEnabled enterprise policy to keep native XSLT until August 17, 2027.

What XSLT Prism's restored API supports

The API XSLT Prism adds to a page follows Chrome's historical behaviour, so code written for Chrome runs unchanged:

• Methods: importStylesheet, transformToFragment, transformToDocument, setParameter, getParameter, removeParameter, clearParameters and reset.
• Engine: libxslt (XSLT 1.0 with EXSLT), compiled to WebAssembly and bundled in the extension. It is synchronous, like the native API, and starts on the first new XSLTProcessor().
• Failures: like Chrome, the transform methods return null and the reason from libxslt goes to the console.
• Imports and document(): loaded by the page itself, under the page's own origin, cookies and CORS rules, so the engine can read only what the page could.
• Only where needed: it is added only on sites you chose, and only if the browser has no working XSLTProcessor of its own.

Known limits: a page whose Content Security Policy forbids WebAssembly cannot run the engine (the constructor throws a SecurityError saying so), and pages that enforce Trusted Types cannot turn results into DOM nodes. The extension respects both policies rather than bypassing them.