This release of Chrome had 15 new features.
Starting in Chrome 152, Chrome will introduce the CPU Performance API, which allows web applications to determine the CPU performance of a user's device. This API targets web applications that will use this information to provide an improved user experience, possibly in combination with the Compute Pressure API, which provides information about the user device’s CPU pressure or utilization and allows applications to react to changes in CPU pressure. Users can override the reported performance in Chrome's Performance settings. Administrators can also control this behavior using the [CpuPerformanceTierOverride](https://chromeenterprise.google/policies/#CpuPerformanceTierOverride) policy (which takes precedence over the user setting). For more details, see [CPU Performance API Explainer](https://github.com/WICG/cpu-performance). #
This feature was specified in this Spec.
Support for CSSPseudoElement - which is currently only defined for ::after, ::before, and ::marker - is now being extended to include several new pseudo-elements: ::backdrop: useful for closing a dialog when the backdrop is clicked, without interfering with clicks inside the dialog's content. This eliminates the need for complex intersection logic to determine where the click occurred. ::scroll-marker: can be used to collect click statistics. view transitions: enables geometry-aware view transitions.It also allows you to intercept a view transition mid-flight to start a new one, utilizing the coordinates of the currently animating element to avoid sudden visual jumps.
This feature was specified in this Spec.
Connection Allowlists is a feature designed to provide explicit control over external endpoints by restricting connections initiated via the Fetch API or other web platform APIs from a document or worker. The proposed implementation involves the distribution of an authorized endpoint list from the server through an HTTP response header. Prior to the establishment of any connection by the user agent on behalf of a page, the agent will evaluate the destination against this allowlist; connections to verified endpoints will be permitted, while those failing to match the entries in the list will be blocked. More details on the proposal can be found here: https://github.com/WICG/connection-allowlists Design doc: https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA/edit?usp=sharing Implementation Design: https://source.chromium.org/chromium/chromium/src/+/main:docs/connection_allowlist_design.md #
This feature was specified in this Spec.
The HTML autocorrect attribute allows web authors to control whether autocorrection should be applied to user input in editable elements including <input>, <textarea>, and contenteditable hosts. The feature makes the 'autocorrect' attribute to be exposed to web authors. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect#examples
The :playing, :paused, :seeking, :buffering, :stalled, :muted, and :volume-locked CSS pseudo-classes match <audio> and <video> elements based on their state. This is one of the focus areas in https://wpt.fyi/interop-2026. #
This feature was specified in this Spec.
Adds the `encryptionScheme` attribute to the `KeySystemTrackConfiguration` dictionary used in `navigator.mediaCapabilities.decodingInfo()`. This allows web applications to query whether a specific encryption scheme (such as `'cenc'` or `'cbcs'`) is supported. *Note: This feature is already approved by the W3C spec and the underlying backend implementation in Chromium already exists. This launch is purely to plumb the `encryptionScheme` property from the Blink IDL layer to the existing backend.* #
This feature was specified in this Spec.
Chrome is rolling out notification attribution for installed Progressive Web Apps (PWAs) on macOS. When a PWA is installed on macOS, its notifications will now be natively attributed to the PWA itself (using its own name and icon in the Notification Center) rather than Google Chrome. This update also changes how notifications are displayed to the user, aligning PWA notifications with native macOS applications. It introduces two changes that align with current behavior in [WebKit](https://webkit.org/): - For app notifications, Chrome will no longer support the `requireInteraction` field for notifications. On macOS, the user controls whether the notification is temporary or persistent on a per-app basis. - For app badging, the Badging API now requires notifications permissions for the app badge to show up. If the user does not grant notifications permission, the API will silently do nothing. Administrators who pre-grant notification permissions using Chrome policies must update their configurations if they want to keep that behavior for PWAs on macOS: In addition to the Chrome origin-based policy [NotificationsAllowedForUrls](https://chromeenterprise.google/policies/#NotificationsAllowedForUrls), administrators must deploy a macOS MDM configuration profile to pre-grant notification permissions to the PWA's specific bundle ID. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/pwa-testing/notificationsapi/index.html
`OpaqueRange` represents a live span of text within a form control’s value, such as a `<textarea>` or text-based `<input>`, so developers can work with value text using range-like APIs. It enables operations such as `getBoundingClientRect()`, `getClientRects()`, and integration with the CSS Custom Highlight API for UI such as inline suggestions, highlights, and anchored popovers. It preserves encapsulation by exposing only value offsets while returning `null` for `startContainer` and `endContainer`, so DOM endpoints and internal structure are not exposed. #
This feature was specified in this Spec.
Samples: https://github.com/MicrosoftEdge/Demos/tree/main/opaque-range
Reference Target enables ID attributes like <label for>, aria-labelledby, popovertarget, and commandfor to be forwarded to elements inside a component's shadow DOM, while maintaining the shadow's encapsulation of its internal state. When a shadow host specifies an element in its shadow tree to act as its reference target, all ID references pointing to the shadow host are forwarded to the reference target element instead. <label for="my-checkbox">Checkbox value (click me to toggle checkbox)</label> <custom-checkbox id="my-checkbox"> <template shadowrootmode="open" shadowrootreferencetarget="real-checkbox"> <input id="real-checkbox" type="checkbox"> </template> </custom-checkbox> The reference target can be set declaratively like in the above example, or in JavaScript with ShadowRoot's referenceTarget property. #
This feature was specified in this Spec.
Samples: https://microsoftedge.github.io/Demos/reference-target
Relative alpha colors refer to an origin color, and only change the alpha channel. The meaning of alpha channels is defined in CSS Color 4 § 4.2 Representing Transparency in Colors: the <alpha-value> syntax. #
This feature was specified in this Spec.
Sub apps allow developers to create multiple apps under a single Isolated Web App ([IWA](https://chromeos.dev/en/web/isolated-web-apps)) installation. Each Sub app has its own distinct name, icons and OS integrations. Sub apps appear on the desktop shelf with a distinct identity from the parent IWA, offering separate OS capabilities, such as file type association. This allows a single software package to present different, isolated functionalities to the user while maintaining a single, unified IWA install and update process. There are three new enterprise policies available to control the Sub apps API: - [DefaultSubAppsWithoutPromptsSetting](https://chromeenterprise.google/policies/#DefaultSubAppsWithoutPromptsSetting) specifies globally (for all IWAs) if user permission prompts are required to install Sub apps. The policies below can override this default. - [SubAppsWithoutPromptsAllowedForOrigins](https://chromeenterprise.google/policies/#SubAppsWithoutPromptsAllowedForOrigins) specifies a list of IWA URLs that can add or update Sub apps without user permission prompts. - [SubAppsWithoutPromptsBlockedForOrigins](https://chromeenterprise.google/policies/#SubAppsWithoutPromptsBlockedForOrigins) specifies a list of IWA URLs that can add Sub apps with user permission prompts only. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/sub-apps
Samples: https://github.com/vkrot-cell/subapps-demo
Unframed display mode allows [Isolated Web Apps](https://chromeos.dev/en/web/isolated-web-apps) to occupy the entire browser window, which optimizes the workspace available. By removing standard window borders and title bars, developers can implement unique user experiences with branding and menu hierarchies that match the look-and-feel of native applications. Administrators can manage this feature with existing policies for window management: - [DefaultWindowManagementSetting](https://chromeenterprise.google/policies/#DefaultWindowManagementSetting) configures the default state for the window management for all apps. The policies below can override this default. - [WindowManagementAllowedForUrls](https://chromeenterprise.google/policies/#WindowManagementAllowedForUrls) allows IWAs with specified origins to enter unframed mode without any user interaction. - [WindowManagementBlockedForUrls](https://chromeenterprise.google/policies/#WindowManagementBlockedForUrls) blocks unframed mode for IWAs with specified origins, forcing Chrome to fallback to other available display modes. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/manifest-incubations/blob/gh-pages/unframed-explainer.md
Samples: https://github.com/edman/unframed-demo
Adds the optional GPU feature "subgroup-size-control" that allows explicitly setting the subgroup size in a compute shader. This technique is particularly useful for the applications that need to optimize the performance of the compute shader using subgroup operations with specifc subgroup size on certain platforms, such as the AI workloads. #
This feature was specified in this Spec.
Adds an audioPreference attribute to the DisplayMediaStreamOptions dictionary used in the getDisplayMedia API. This hint allows web applications to signal to the UA that they prefer audio sharing along with video. This helps developers ensure that applications relying on audio capture work seamlessly. #
This feature was specified in this Spec.
The `window-drag` CSS property allows web content to designate regions of an installed desktop web app’s UI that should behave as draggable window titlebar areas. When applied, user pointer interactions (e.g., click-and-drag) on that region move the top-level application window rather than triggering normal page interaction. This is primarily used by desktop PWAs or apps using features like Window Controls Overlay to implement custom title bars and draggable areas when the browser-provided title bar is hidden. This feature standardizes and renames the existing `app-region` CSS property, changes its value names to `move` and `none`, and adds explicit inheritance behavior. This property is used by installed web apps and Electron-based applications for the same purpose. #
This feature was specified in this Spec.
This release of Chrome had 2 new origin trials.
[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, Gecko and WebKit) plans to deprecate and remove XSLT from the web platform. The modern web is powered by three major browser engines: [Blink](https://www.chromium.org/blink/) (Chromium), [Gecko](https://firefox-source-docs.mozilla.org/overview/gecko.html) (Firefox), and [WebKit](https://webkit.org/) (Safari). They interpret code to render pages. For more details, see this [Chrome for Developers article](https://developer.chrome.com/docs/web-platform/deprecating-xslt). #
Docs: https://github.com/whatwg/html/issues/11523
No linked samplesCurrent viewport heuristics for speculation rules don't give any room for developer experimentation. This experimental feature will provide such controls, and enable developers to figure out if different heuristics parameters give them better results than the default ones. This is a feature only aimed at experimentation, and there are no plans to ship it as is. #
This release of Chrome had 3 are available behind a flag.
Gamepad API defines standard indices for 17 common gamepad buttons. The GamepadButton type attribute provides an alternate, interoperable identifier for common buttons that are not included in the standard set, like "trackpad". #
This feature was specified in this Spec.
Adds support for decoding and playing back the Immersive Audio Model and Formats (IAMF) container within HTML media elements via Media Source Extensions (MSE). IAMF is an open, royalty-free spatial audio format that supports channel-based, scene-based, and object-based audio presentations. Supporting this standard allows web developers to deliver consistent, immersive 3D audio experiences across different devices without relying on proprietary formats or managing complex discrete audio channel routing in JavaScript. #
This feature was specified in this Spec.
Samples: https://crsrc.org/c/media/test/data/iamf_alternating_sine_waves_stereo.mp4https://crsrc.org/c/media/test/data/iamf_alternating_sine_waves_714.mp4https://aomediacodec.github.io/iamf-tools/web_demo
Adds an audioPreference attribute to the DisplayMediaStreamOptions dictionary used in the getDisplayMedia API. This hint allows web applications to signal to the UA that they prefer audio sharing along with video. This helps developers ensure that applications relying on audio capture work seamlessly. #
This feature was specified in this Spec.
To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:
Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.
Chrome currently has a process for deprecations and removals of API's, essentially:
You can find a list of all deprecated features on chromestatus.com using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.
This release of Chrome had 1 features deprecated.
The Private Aggregation API is a generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. It was originally designed for a future without third-party cookies. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Private Aggregation API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page[0]). This API is only exposed via the Shared Storage and Protected Audience APIs, which are also planned to be deprecated and removed. So, no additional work will be required for Private Aggregation. [0]: https://privacysandbox.google.com/overview/status
This feature was specified in this Spec.
This release of Chrome had 0 features removed.