v152 · origin trial · enterprise policy · escape hatches

“XSLT” deprecation trial & `XSLTEnabled`

Two sanctioned mechanisms keep XSLT working past the Chrome 158 removal: the “XSLT” deprecation origin trial (a reverse trial — a token that re-enables a removed feature for your origin, Chrome 152–175) and the XSLTEnabled enterprise policy (admin-deployed, same window). This page documents both contracts: registration, token serving, scope, and end-of-life.

Time-boxed by design — plan the real migration

The trial and policy stop functioning in Chrome 176 (Aug 17, 2027), after which XSLT is disabled for all users. Registering is cheap; migrating is the actual work — see migration paths.

the “XSLT” deprecation origin trial

Trial name	`XSLT` (origin trials console; ChromeStatus origin-trial id `1902207892610613249`)
Type	Deprecation trial (`origin_trial_type: "deprecation"` in the runtime flag record) — a token restores the disabled feature instead of enabling a new one
Window	Chrome 152–175 (desktop, Android, WebView) — live from Aug 25, 2026; ends before the final M176 removal
Effect	Both removed surfaces return on the served origin: `window.XSLTProcessor` is present again and XSLT processing instructions run
Third-party tokens	Supported (`origin_trial_allows_third_party: true`) — embedders can enable XSLT for their embedded contexts
Insecure origins	Allowed (`origin_trial_allows_insecure: true`) — notable because intranet/embedded XML devices often run plain HTTP
Owner	masonfreed@google.com; feedback template on issues.chromium.org

registration and serving

Register your origin for the XSLT trial at the origin trials console (or for third-party use, request a third-party token). Registration opened ahead of M152 — the Request for Deprecation Trial (Jun 2026) deliberately runs the trial early so sites can test before M158.
Serve the token on every page that needs XSLT, either as a meta tag or an HTTP header:

<meta http-equiv="origin-trial" content="TOKEN_FROM_DEVELOPER.CHROME.COM/ORIGINTRIALS">

# or, as a response header:
Origin-Trial: TOKEN_FROM_DEVELOPER.CHROME.COM/ORIGINTRIALS

For local development, the equivalent is the feature flag rather than a token: chrome://flags/#xslt set to Enabled, or launch with --enable-blink-features=XSLT (the runtime feature is public: true).

Source: ChromeStatus API record, origin-trial stage; runtime flag record; blink-dev — Request for Deprecation Trial.

the XSLTEnabled enterprise policy

Policy	`XSLTEnabled` (Chrome Enterprise policy list)
Available	Live for testing from Chrome 146 (Mar 10, 2026) per the removal guide — before the M158 removal, so enterprises can test both states
Type and default	Boolean policy; template `default: null` means unset, not enabled or disabled. With no policy, the browser default and field trials determine availability.
States	`true` explicitly enables XSLT; `false` explicitly disables it; unset (`null` in the template) follows browser defaults and field trials. The policy covers both `XSLTProcessor` and XSL processing instructions.
Supported platforms	Template `supported_on`: `chrome.*:146-`, `chrome_os:146-`, `android:146-`, `webview_android:146-`. Dynamic refresh and per-profile configuration are supported.
Effect	Lets an enterprise keep XSLT enabled past the removal date for managed browsers; also usable to test the disabled state early
End of life	The current Chrome removal guide plans Chrome 176 (Aug 17, 2027) for both mechanisms. The machine-readable policy template still says removal in M164 in its description (checked 2026-10-08); these primary sources disagree. Re-check before relying on the policy beyond M164.
Discovery	Pair with the Legacy Technology Report to find deprecated-feature usage across the fleet before deciding where to set the policy

Deployment uses the standard Chromium policy mechanisms — for example:

# Linux: /etc/opt/chrome/policies/managed/xslt.json
{ "XSLTEnabled": true }

# Windows (registry): HKLM\Software\Policies\Google\Chrome
"XSLTEnabled" = 1 (DWORD)

# macOS: defaults write com.google.Chrome XSLTEnabled -bool true

Source: Chrome Enterprise policy definition data (XSLTEnabled, id 1429; schema, default, platforms and description); removal guide (timeline); rendered policy list.

error and edge behavior

Situation	Behavior
Token expired or for the wrong origin	Standard origin-trial handling: the feature stays disabled — no XSLT-specific error surface is defined by the sources (2026-07-29)
Token served only on some pages	Trial state is per-document: pages without the token see the removed behavior (raw XML / no `XSLTProcessor`)
Trial window ends (M176)	Tokens and the `XSLTEnabled` enterprise policy stop being honored; XSLT is disabled for everyone — there is no second extension on the record
Policy vs trial conflict	Not specified in the sources; both independently restore the feature, and the sources define no precedence (recorded as an open question in the critique)

Source: removal guide; ChromeStatus record.

browser compatibility

Browser	Escape hatch	Window
Chrome	Deprecation trial + `XSLTEnabled` policy	152–175 (both end in 176)
Edge	Chromium-based; the enterprise policy applies — no separate statement on the record	Follows Chromium
Firefox	None on the record	—
Safari	None on the record (WebKit's position mentions possibly matching a reverse-trial origin list)	—

Source: ChromeStatus record; WebKit position comment.

security and privacy

Why the hatches are time-boxed — every day the trial/policy keeps libxslt alive is a day of continued memory-safety exposure (the reason for removal); the M176 hard stop is the security endgame.
Third-party + insecure allowances widen exposure deliberately — the runtime flag record permits both, so intranet XML devices and embedded contexts can be reached; treat third-party tokens as extending an attack surface you are responsible for retiring.
Origin-scoped — the token restores the feature only on your origin; it does not re-expose other origins' users.

Source: runtime flag record; removal guide.