Chrome version: 151, 150, 149, 148, 147, 146, 145, 144, 143, 142, 141, 140, 139, 138, 137, 136, 135, 134, 133, 132, 131, 130, 129, 128, 127, 126, 125, 124, 123, 122, 121, 120, 119, 118, 117, 116, 115, 114, 113, 112, 111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
This release of Chrome had 26 new features.
Allows authors to style descendants of containers based on the most recent scrolling direction. Example: .scrolling-up { translate: 80px 0; transition: 0.4s translate; } html { container-type: scroll-state; } @container scroll-state(scrolled: top) { .scrolling-up { translate: 0 0; } } #
This feature was specified in this Spec.
When an anchor-positioned element is tethered against an anchor that has a transform (or is contained by something with a transform), resolve anchor() and anchor-size() functions against the bounding box of the transformed anchor. #
This feature was specified in this Spec.
The shape of the caret in native applications is most commonly a vertical bar, an underscore or a rectangular block. In addition, the shape often varies depending on the input mode, such as insert or replace. The CSS caret-shape property allows sites to choose one of these shapes for the caret inside editable elements, or leave the choice up to the browser. The recognized property values are auto, bar, block and underscore. #
This feature was specified in this Spec.
This feature exposes **find-in-page** search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the browser defaults have insufficient contrast with the page colors or are otherwise unsuitable. #
This feature was specified in this Spec.
Docs: https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md
No linked samplesThe "clipboardchange" event fires whenever the system clipboard contents are changed either by a web app or any other system application. This allows web-apps like remote desktop clients to keep their clipboards synchronized with the system clipboard. It provides an efficient alternative to polling the clipboard(using Javascript) for changes. #
This feature was specified in this Spec.
See the discussion in this issue for more context: - https://github.com/w3c/html-aam/issues/545 The code to create aria-details relationships for non-popover use cases of anchor positioning was likely a mistake. Since popovers and other semantic relationships *do* create aria-details, and the remaining use cases are likely non-semantic, there is a desire *not* to create these relationships in the non-semantic cases. Since most common use cases use popovers, this change should hopefully not be too noticeable to users. #
This feature was specified in this Spec.
After an event target gets removed from the DOM, the logical target of the pointer as implied by the Pointer and Mouse boundary events (i.e. over, out, enter and leave events) should be the nearest ancestor still attached to the DOM. PEWG has recently reached consensus on this behavior, see https://github.com/web-platform-tests/interop/issues/380. Chrome has been keeping track of a node even after it gets removed from DOM. As a result, if the pointer moves to a new node B after the hit-test node A is removed from DOM, the boundary event sequence (pointerover, pointerout, pointerenter, pointerleave events and the corresponding mouse events) used to imply a pointer movement from A to B. As per the new consensus, the event sequence should imply a pointer movement from the "parent of A" to B. #
This feature was specified in this Spec.
Samples: https://output.jsbin.com/yumacid
Support for character-level and glyph-level mirroring when rendering MathML operators in right-to-left mode. When using RTL mode some operators can be mirrored by changing them to another code point (e.g. a right parentheses becomes a left parentheses). This is character-level mirroring, with equivalences defined by Unicode's `Bidi_Mirrored` property. There are operators that have no appropriate mirroring character. Glyph-level mirroring applies in this case, with the `rtlm` font feature, where another glyph can replace it in a mirrored context. Some existing implementations mirror the original glyph directly, but this may change the meaning for asymmetrical characters, such as the clockwise contour integral. #
This feature was specified in this Spec.
Samples: https://people.igalia.com/fwang/mathml-operator-mirroring-explainer.html
This feature allows [Isolated Web Apps](https://chromeos.dev/en/web/isolated-web-apps) (IWAs) to subscribe to multicast groups and receive User Datagram Protocol (UDP) packets from there. IWAs can now also specify additional parameters when sending UDP packets to multicast addresses.
This feature was specified in this Spec.
Docs: https://github.com/WICG/direct-sockets/blob/main/docs/multicast-explainer.mdhttps://docs.google.com/document/d/1Wna0lkTrhYoTxOO1GjOrut2nWHO19HEyo9YCk39tXqY/edit?usp=sharing
No linked samplesIgnore tree-scope when matching container-name for @container queries. Previously, container-name matching for container queries used tree-scoped names/references for matching, which meant the same name would not match if the @container rule and the container-type property were originating from different trees such that that container-type declaration came from an inner shadow tree. With this change container names match regardless of @container rule or container-type declaration origins. #
This feature was specified in this Spec.
The Event Timing API is part of the Performance Timeline and is used to measure the performance of user interactions. Certain Events will have an interactionId value assigned to them, and this is useful for grouping related interactions based on common physical user inputs or gestures. This feature adds a very trivial performance.interactionCount, which is just the total number of interactions that have occured on the page. In particular, this feature is useful for computing the Interaction to Next Paint (INP) metric value, which requires knowing the total number of interactions in order to compute a high percentile score (p98 for pages with greater than 50 total interactions). This feature has been specced for a long while, was prototypes in Chromium a long time ago but never shipped, is part of Interop 2025, and is already available in other browsers. (Note: there is already a more powerful performance.eventCounts map for specific events, but it is not possible to accurately map event counts to interaction counts.)
This feature was specified in this Spec.
Docs: https://www.w3.org/TR/event-timing/#dom-performance-interactioncounthttps://www.w3.org/TR/event-timing/#sec-increasing-interaction-count
Samples: https://chrome.dev/inp-demo
Provides access to raw mouse movement by locking the target of mouse events to a single element and hiding the mouse cursor. #
This feature was specified in this Spec.
Samples: https://mdn.github.io/dom-examples/pointer-lock
"maintain-framerate-and-resolution" disables WebRTC's internal video adaptation. This enables the application to implement its own adaptation logic and prevents interference from the internal adaptation. From https://www.w3.org/TR/mst-content-hint/#dom-rtcdegradationpreference-maintain-framerate-and-resolution: Maintain framerate and resolution regardless of video quality. The user agent SHOULD NOT prefer reducing the framerate or resolution for quality and performance reasons, but MAY drop frames before encoding if necessary not to overuse network and encoder resources. #
This feature was specified in this Spec.
When you set `overscroll-behavior` to a value other than `auto`, the browser should not perform scroll chaining. We respect this for mouse or touch scrolling, however keyboard scrolls were ignoring it. This change makes keyboard scrolling respect overscroll-behavior as well. #
This feature was specified in this Spec.
Samples: https://jsfiddle.net/qy78w5ga
The overscroll-behavior applies to all scroll container elements, regardless of whether those elements currently have overflowing content or are user scrollable. Developers can use overscroll-behavior to prevent scroll propagation on an `overflow: hidden` backdrop or an `overflow: auto` element without needing to consider whether it will currently be overflowing.
This feature was specified in this Spec.
Samples: https://ebidel.github.io/demos/chatbox.htmlhttps://codepen.io/rctneil/pen/rJYONj
Align the Blink implementation with the SVG2 specification for matching CSS rules in <use> element trees. Match selectors against the <use> instantiation elements instead of the originating element subtree. This means selectors will no longer match ancestor and sibling elements outside the cloned subtree. More importantly, state selectors like :hover will now start matching in <use> instances. #
This feature was specified in this Spec.
Adds support for ping, hreflang, type, and referrerPolicy attributes on SVGAElement, aligning its behavior with HTMLAnchorElement for consistent link handling across HTML and SVG. #
This feature was specified in this Spec.
Temporal API https://github.com/tc39/proposal-temporal in ECMA262 is a new API that provides standard objects and functions for working with dates and times. Date has been a long-standing pain point in ECMAScript. This proposes Temporal, a global Object that acts as a top-level namespace (like Math), that brings a modern date/time API to the ECMAScript language. Full documentation can be found here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal #
This feature was specified in this Spec.
Introduces the <geolocation> element, a declarative, user-activated control for accessing the user's location. It streamlines the user and developer journey by not only handling the permission flow but also directly providing location data to the site, often eliminating the need for a separate JavaScript API call. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into the capability-specific <geolocation> element to provide a more tailored and powerful developer experience. Explainer: https://github.com/WICG/PEPC/blob/main/geolocation_explainer.md Instructions: https://github.com/WICG/PEPC/blob/main/HOWTO.md #
This feature was specified in this Spec.
Samples: https://permission.site/pepc
Adds support for a 'ch-ua-high-entropy-values' permissions policy that enables a top-level site to restrict which documents are able to collect high-entropy client hints via the navigator.userAgentData.getHighEntropyValues() JS API. Restricting collection of high-entropy hints over HTTP is already possible via existing per-client-hint permissions policies. #
This feature was specified in this Spec.
The ViewTransition automatically constructs a pseudo-element tree to display and animate participating elements in the transition. Per spec, this subtree is constructed when the view transition starts animating and is destroyed when the animations associated with all view transition pseudo-elements are in the finished state (or more precisely in a non-running non-paused state). This works for a vast majority of cases and provides a seamless experience for the developers. However, for more advanced cases, this is insufficient as there are times when developers want the view transition pseudo-tree to persist beyond the animation finish state. One example is tying view transitions with Scroll Driven Animations. When the animation is controlled by a scroll timeline, we don't want the subtree to be destroyed when the animations finish since scrolling back should still be able to animate the pseudo elements. In order to enable advanced uses of view transition, this intent adds a waitUntil() function on the ViewTransition object which takes a promise. This promise then delays destruction of the pseudo-tree until it is settled. #
This feature was specified in this Spec.
Specify an update eligibility algorithm in the manifest spec. This makes the update process more deterministic and predictable, giving the dev more control over whether (and when) updates should apply to existing installations, and allowing removal of the 'update check throttle' that user agents currently need to implement to avoid wasting network resources. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. Uniform buffers declared in WGSL shaders are no longer required to have 16-byte alignment on array elements, or to pad nested structure offsets to a multiple of 16 bytes. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. The `subgroup_id` and `num_subgroups` built-in values are now available when the subgroups extension is enabled. #
This feature was specified in this Spec.
Adds an XRVisibilityMaskChange event that will provide a list of vertices and a list of indices to represent the mesh of the visible portion of the user's viewport. This data can then be used to confidently limit the amount of the viewport drawn to in order to improve performance. To better support this event, XRView's are also given unique identifiers to allow easier pairing with the associated masks. This is an extension to the core WebXR specification. #
This feature was specified in this Spec.
Samples: https://github.com/cabanier/three.js/commit/78a3227d95fc29e001d8cd139504c643987430c5
Defines the background image's position relative to one of its edges. This syntax gives web authors a more flexible and responsive mechanisms to define the background image position, instead of using fixed values that need to be adapted to the window's or frame's size. This feature is applied also to the "-webkit-mask-position" to ensure webcompat levels are the same. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/CSS/background-position-x#try_it
This release of Chrome had 3 new origin trials.
Usermedia Capability Element, is a declarative, user-activated control for accessing the starting and interacting with media streams. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into capability-specific elements to provide a more tailored and powerful developer experience. #
This feature was specified in this Spec.
Samples: https://tungnh28.github.io/pepc
Expand the TextMetrics Canvas API to support selection rectangles, bounding box queries, and glyph cluster-based operations. This new functionality should enable complex text editing applications with accurate selection, caret positioning, and hit testing. Additionally, cluster-based rendering facilitates sophisticated text effects such as independent character animations and styling. #
This feature was specified in this Spec.
This extends speculation rules to introduce a new action called prerender_until_script. It is designed as an intermediate option between the existing prefetch (which only fetches the main document) and prerender (which fully renders the page and runs all scripts). This new action will fetch and parse a page, discover and download its subresources like images and stylesheets, but will pause all script execution. When the user navigates to the page, it activates, and all the deferred scripts are then executed in order. This allows for a near-instant page load for content-heavy sites without the performance cost or side effects of running analytics or third-party scripts prematurely. #
This feature was specified in this Spec.
Samples: https://github.com/WICG/nav-speculation/blob/main/prerender-until-script.md
This release of Chrome had 7 are available behind a flag.
Usermedia Capability Element, is a declarative, user-activated control for accessing the starting and interacting with media streams. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into capability-specific elements to provide a more tailored and powerful developer experience. #
This feature was specified in this Spec.
Samples: https://tungnh28.github.io/pepc
See the discussion in this issue for more context: - https://github.com/w3c/html-aam/issues/545 The code to create aria-details relationships for non-popover use cases of anchor positioning was likely a mistake. Since popovers and other semantic relationships *do* create aria-details, and the remaining use cases are likely non-semantic, there is a desire *not* to create these relationships in the non-semantic cases. Since most common use cases use popovers, this change should hopefully not be too noticeable to users. #
This feature was specified in this Spec.
Chromium's IndexedDB implementation is rewritten on top of SQLite, to replace the previous implementation that uses a hybrid of LevelDB and flat files. There is no change to the Web API. This is expected to improve reliability and, to a lesser extent, performance. For now this is applied only to in-memory contexts such as Incognito mode in Chromium and Google Chrome. This limits the impact of any new bugs, as well as puts off the need to worry about migration of existing data persisted to disk. #
This feature was specified in this Spec.
Samples: https://evanstade.github.io/web-storage-demos/idb-txn-scopes
Restricts the ability to make requests to the user's local network using WebTransport, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (e.g. intranet) to loopback. Gating the ability for websites to perform these requests behind a permission reduces the ability of sites to use these requests to fingerprint the user's local network. This permission is restricted to secure contexts. This work is adding to the Local Network Access Restrictions work here: https://chromestatus.com/feature/5152728072060928 #
This feature was specified in this Spec.
Samples: https://lna-testing.notyetsecure.com
This feature adds scroll-position-based control of animations, e.g. playing, pausing, and resetting an animation. A common pattern on pages across the web is to kick off an animation when a scroll position is reached. Developers often do this by using JavaScript to manually detect that an element is within its scroll container's viewport and to kick off a corresponding animation (e.g. perhaps sliding that element into view). Many of such use cases are based on information that can be provided declaratively. This feature gives authors the ability to create such interactions declaratively via CSS, allowing the user agent to offload the handling of this interaction to a worker thread. The API also includes JavaScript interfaces that allow the feature to be extended to web animations in addition to CSS animations. #
This feature was specified in this Spec.
Docs: https://github.com/explainers-by-googlers/scroll-triggered-animations/blob/main/README.md
Samples: https://davmila.github.io/sta-demos/explore
This extends speculation rules to introduce a new action called prerender_until_script. It is designed as an intermediate option between the existing prefetch (which only fetches the main document) and prerender (which fully renders the page and runs all scripts). This new action will fetch and parse a page, discover and download its subresources like images and stylesheets, but will pause all script execution. When the user navigates to the page, it activates, and all the deferred scripts are then executed in order. This allows for a near-instant page load for content-heavy sites without the performance cost or side effects of running analytics or third-party scripts prematurely. #
This feature was specified in this Spec.
Samples: https://github.com/WICG/nav-speculation/blob/main/prerender-until-script.md
This feature introduces a WebRequest.SecurityInfo API for [ControlledFrame](https://developer.chrome.com/docs/iwa/controlled-frame). It allows a web app to intercept an HTTPS, WSS, or WebTransport request to a server, retrieve the server's certificate fingerprint (as verified by the browser), and then use that fingerprint to manually verify the certificate of a separate raw TCP/UDP connection to the same server. This provides a simple way for the app to confirm it's communicating with the correct server. #
This feature was specified in this Spec.
Docs: https://github.com/explainers-by-googlers/security-info-web-request
No linked samplesTo 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 8 features deprecated.
The Protected Audience API provides a method of interest-group advertising without third-party cookies or user tracking across sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Protected Audience API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page).
This feature was specified in this Spec.
Related Website Sets (RWS), formerly known as First Party Sets, provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the Storage Access API (SAA) and requestStorageAccessFor (rSAFor). RWS was designed for use in a browser 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 Related Website Sets (RWS). Once RWS is deprecated; existing usage of SAA across contexts within a set will fall back to the API’s behavior outside of RWS as specified here. The difference in SAA behavior outside of RWS is well illustrated in our developer blogpost here. The companion rSAFor API will also be deprecated via a separate intent. We also intend to deprecate RWS-related Chrome Enterprise policies, as well as the chrome.privacy.relatedWebsiteSetsEnabled extension API; and will follow the relevant processes.
This feature was specified in this Spec.
The Shared Storage API is a privacy-preserving web API to enable storage that is not partitioned by first-party site. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Shared Storage API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page). [0]: https://privacysandbox.com/news/privacy-sandbox-next-steps/ #
This feature was specified in this Spec.
The requestStorageAccessFor (rSAFor) API is an extension to the Storage Access API that allows a top-level site to request access to unpartitioned ("first-party") cookies on behalf of embedded sites. Browsers will have discretion to grant or deny access, with mechanisms like Related Website Sets (RWS) membership as a potential signal. This allows for use of the Storage Access API by top-level sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove rSAFor, as it is only usable in Chrome to request storage access between RWS sites. Related Website Sets will also be deprecated via a separate intent.
This feature was specified in this Spec.
The Attribution Reporting API is a privacy-preserving web API designed to measure ad conversions without third-party cookies or user tracking across sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Attribution Reporting API (along with other Privacy Sandbox APIs). [0]: https://privacysandbox.com/news/privacy-sandbox-next-steps/
This feature was specified in this Spec.
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.
To align desktop and ChromeOS behavior with mobile and to simplify sync management, the individual `savedTabGroups` datatype is now deprecated and is no longer an individually customizable value within the [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) policy. Previously, the [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) enterprise policy allowed administrators to disable the synchronization of `savedTabGroups` datatype on desktop and ChromeOS platforms. On mobile platforms, however, tab group synchronization is already managed by the `tabs` datatype. Starting with Chrome 144, if your [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) policy disables either `tabs` or `savedTabGroups`, both data types are now considered disabled. This means that disabling tabs also disables saved tab groups, and the other way around. The `savedTabGroups` value is entirely removed from the list of supported datatypes for this policy. For admins who have saved tab groups disabled, and intend to keep this behavior, make sure to explicitly disable the `tabs` datatype. This guarantees the desired behavior before the `savedTabGroups` value is fully removed.
Chrome synchronously fetches external XML entities/DTDs and incorporates them into parsing under specific circumstances. I propose to remove this functionality. http/tests/security/contentTypeOptions/xml-external-entity.xml gives an example: External entities can be defined in the trailing part of the DOCTYPE statement - and then refer to resources that are to be synchronously loaded and included as context when parsing XML. Another syntax example would be a DOCTYPE that, using the SYSTEM keyword followed by a URL pointing to a DTD which contains additional entity definitions. Such external load requests are passed up from the parser. According to https://www.w3.org/TR/xml/#proc-types non-validating processor are not required to read external entities. We plan to deprecate loading of external entity definitions in XML documents that do not use XSLT. #
This feature was specified in this Spec.
This release of Chrome had 0 features removed.