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 16 new features.
View Transition feature uses a pseudo sub-tree of the element, with ::view-transition being the root of that transition. Previously ::view-transition element was specified to have a position: fixed. CSSWG made a decision to make this instead position: absolute. In effect, this should not be noticeable since this element's containing block remains the snapshot containing block in either absolute or fixed case. The only noticeable change is a change in getComputedStyle. #
This feature was specified in this Spec.
These pseudo-classes match scroll markers that are, respectively, before or after the active marker (the one matching :target-current) within the same scroll marker group, as determined by flat tree order: * :target-before matches all scroll markers that precede the active marker in the flat tree order within the group. * :target-after matches all scroll markers that follow the active marker in the flat tree order within the group. #
This feature was specified in this Spec.
Samples: https://drafts.csswg.org/css-overflow-5/#example-cf830461
Currently, FedCM always shows the toplevel site in its UI. This works well when the iframe is conceptually first-party (e.g. foo.com may have an iframe foostatic.com, which is not meaningful to the user). But if the iframe is actually third-party, it would be better to make it possible to show the iframe origin in the UI so that the user better understands who they are sharing their credentials with. For example, a photo editor may be embedded in a book publishing web app and may want to let users access files they have previously stored with the photo editor. This proposal allows doing so. #
This feature was specified in this Spec.
This feature adds an `interestfor` attribute to <button> and <a> elements. This attribute adds "interest" behaviors to the element, such that when the user "shows interest" in the element, actions are triggered on the target element, such as showing a popover. The user agent will handle detecting when the user "shows interest" in the element, via methods such as hovering the element with a mouse, hitting special hotkeys on the keyboard, or long-pressing the element on touchscreens. When interest is shown or lost, an `InterestEvent` will be fired on the target, which have default actions in the case of popovers - showing and hiding the popover. #
This feature was specified in this Spec.
The PointerEvents spec restricted pointerrawupdate to secure contexts in 2020, hiding both the event firing and the global event listeners from insecure contexts. Through this feature, Chrome will match the updated spec and become interoperable with other major browsers. #
This feature was specified in this Spec.
Chrome 142 restricted the ability to make requests to the user's local network, 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 (for example, intranet) to loopback. Gating the ability for websites to perform these requests behind a permission mitigates the risk of cross-site request forgery attacks against local network devices such as routers, and reduces the ability of sites to use these requests to fingerprint the user's local network. This permission is restricted to secure contexts. If granted, the permissions additionally relaxes mixed content blocking for local network requests (since many local devices are not able to obtain publicly trusted TLS certificates for various reasons). This work supersedes a prior effort called [Private Network Access](https://chromestatus.com/feature/5737414355058688), which used preflight requests to have local devices opt in. For more information on this feature, see [Adapting your website for new Local Network Access restrictions in Chrome](https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing). Chrome 145 introduced more granular permissions for websites requesting access to a user's local network. The previous single `local-network-access permission` is being split into two distinct permissions: * `local-network`: Grants access to IP addresses in the local network space (for example, intranets, internal devices). * `loopback-network`: Grants access to loopback IP addresses (for example, `localhost`, `127.0.0.1`). The old `local-network` permission will remain as an alias, ensuring existing configurations and permissions policies continue to function as expected. This change provides both users and Admins with more precise control over how websites interact with internal network resources. Current enterprise policies managing local network access will not be affected by this change. Chrome 146 introduces two new enterprise policies for managing local network access restrictions: [LocalNetworkAccessIpAddressSpaceOverrides](https://chromeenterprise.google/policies/#LocalNetworkAccessIpAddressSpaceOverrides) and [LocalNetworkAccessPermissionsPolicyDefaultEnabled](https://chromeenterprise.google/policies/#LocalNetworkAccessPermissionsPolicyDefaultEnabled). These policies can be set using [custom configurations](https://support.google.com/chrome/a/answer/14749672). Chrome 147 expands Local Network Access restrictions to include WebSocket and WebTransport connections. In Chrome 152, the [LocalNetworkAccessRestrictionsTemporaryOptOut](https://chromeenterprise.google/policies/#LocalNetworkAccessRestrictionsTemporaryOptOut) policy will be removed. #
This feature was specified in this Spec.
Docs: https://github.com/explainers-by-googlers/local-network-accesshttps://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?usp=sharing
Samples: https://local-network-access-testing.glitch.me
Adds `enterPictureInPictureReason` to the `MediaSessionActionDetails` sent to the `enterpictureinpicture` action in the Media Session API. This allows developers to distinguish between `enterpictureinpicture` actions triggered explicitly by the user (e.g. from a button in the user agent) and `enterpictureinpicture` actions triggered automatically by the user agent due to the content becoming occluded. #
This feature was specified in this Spec.
By using the size and multiple attributes, the select element can be rendered as an in-page listbox or a button with a popup. However, these modes are not consistently available across mobile and desktop chrome. Currently, in-page listbox rendering is not available on mobile, and button with popup is not available on desktop when the multiple attribute is present. This feature adds the listbox to mobile and adds a multi-select popup to desktop, and makes the opt-ins with the size and multiple attributes result in the same rendering mode across mobile and desktop. Here is a summary of the changes: - When the size attribute has a value greater than 1, in-page rendering will always be used. Previously, this was ignored on mobile. - When the multiple attribute is set with no size attribute, in-page rendering will be used. Previously, this was a popup instead of an in-page listbox on mobile. - When the multiple attribute is set with size=1, a popup will be used. Previously, this was an in-page listbox on desktop. By making this change, we are providing a foundation to bring customizable select to in-page rendering and multi-select. Customizable select currently only works for single-selects with a popup. #
This feature was specified in this Spec.
This feature enhances CSS style queries and the if() function by adding support for range syntax. This extends style queries beyond exact value matching (e.g., style(--theme: dark)). Developers can now use comparison operators (>, <, etc.) to compare custom properties, literal values (like 10px or 25%), and values from substitution functions like attr() and env(). For a comparison to be valid, both sides must resolve to the same data type. This is limited to the following numeric types: <length>, <number>, <percentage>, <angle>, <time>, <frequency>, and <resolution>. This allows for creating more dynamic components that adapt based on a range of inputs, not just predefined states. Examples: /* Compare a custom property against a literal length */ @container style(--inner-padding > 1em) { .card { border: 2px solid; } } /* Compare two literal values */ @container style(1em < 20px) { ... } /* Using style ranges in if() */ .item-grid { background-color: if(style(attr(data-columns, type<number>) > 2): lightblue; else: white); } #
This feature was specified in this Spec.
This feature preserves the sticky user activation state after a page navigates to another same-origin page. The lack of user activation in the post-navigation page prevents some use cases like showing virtual keyboards on auto-focus, and this has been a blocker for the developers who want to build Multi-page Applications (MPAs) over Single-page Applications (SPAs). Note that browser-initiated navigation requests (reload, history navigation, typed URL in address bar etc) are not covered by this feature. #
This feature was specified in this Spec.
Samples: https://vmpstr.github.io/htmldemos/activation/a.html
Reject JSON module script responses whose MIME type’s type or subtype contains non‑HTTP token code points (e.g. spaces) when matched via *+json; aligns with MIME Sniffing spec and other engines. This change is part of the Interop2025 modules focus area. Related Issues: https://bugs.webkit.org/show_bug.cgi?id=297161 Related PR: https://github.com/web-platform-tests/wpt/pull/54219 Draft CL: https://chromium-review.googlesource.com/c/chromium/src/+/6931461 #
This feature was specified in this Spec.
This feature introduces support for the download attribute on the SVGAElement interface in Chromium, aligning with the SVG 2 specification. The download attribute enables authors to specify that the target of an SVG hyperlink should be downloaded rather than navigated to, mirroring the behavior already supported in HTMLAnchorElement. This enhancement promotes interoperability across major browsers and ensures consistent behavior between HTML and SVG link elements, thereby improving developer experience and user expectations. #
This feature was specified in this Spec.
This feature enables websites to support contextual biasing for speech recognition by adding a recognition phrase list to the Web Speech API. Developers can provide a list of phrases as well as updating them to apply a bias to the speech recognition models in favor of those phrases. This helps improve accuracy and relevance for domain-specific and personalized speech recognition.
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1CBH4r6rxSryY28hOhBQC-DZgjwWbO-FRYg_bbJIfBFo/edit?usp=sharing
No linked samplesThis feature adds a new optional capability to WebGPU that exposes a new WGSL shader builtin, 'primitive_index'. This builtin provides a per-primitive index to fragment shaders on supported hardware, similar to the existing vertex_index and instance_index builtins. The primitive index is useful for advanced graphical techniques, such as virtualized geometry. #
This feature was specified in this Spec.
Extend GPU texture format support with capabilities like render attachment, blending, multisampling, resolve and storage_binding. #
This feature was specified in this Spec.
View Transitions API allows developers to start visual transitions between different states. The primary SPA entry point to this is `startViewTransition()` which returns a transition object. This object contains several promises and functionality to track the transition progress, as well as allow manipulations such as skipping the transition or modifying its types. The proposal here is ergonomic in nature: instead of requiring that users store this object in some sort of way for easy access, provide a `document.activeViewTransition` property that represents this object, or null if there is no transition ongoing. Note this similarly applies to MPA transitions, where the object is only available via `pageswap` and `pagereveal` events. In this proposal `document.activeViewTransition` would be set to this object for the duration of the transition. #
This feature was specified in this Spec.
This release of Chrome had 1 new origin trials.
To enhance user security and combat session cookie theft, Chrome is introducing [Device Bound Session Credentials (DBSC)](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). This feature allows websites to bind a user's session to their specific device, which makes it significantly more difficult for stolen session cookies to be used on other machines. #
This feature was specified in this Spec.
This release of Chrome had 5 are available behind a flag.
Adds support for an explicit time-to-live for dictionaries used in Compression Dictionary Transport. This is a backward-compatible extension to the "Use-As-Dictionary" HTTP response header that adds a "ttl" parameter. The ttl is the number of seconds after the dictionary was last fetched that it is usable as a compression dictionary and overrides the default expiration (which is to expire when the underlying resource expires from the HTTP cache). For example: Use-AsDictionary: match="/*", ttl=600 Would make the response available as a compression dictionary for 10 minutes independent of the HTTP caching headers. This capability was part of the original feature but dropped during the standards process because of a lack of compelling use cases at the time. New use cases have emerged as the feature gains adoption that make it useful to add as an extension. Doc: https://docs.google.com/document/d/1uAutnUWpC6V-ka_MA-4m74YV12LAA6qP1sYjy97S2-0/edit?usp=sharing
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1uAutnUWpC6V-ka_MA-4m74YV12LAA6qP1sYjy97S2-0/edit?usp=sharing
No linked samplesLocal Network Access(LNA) restrictions are being expanded to include WebSockets. WebSockets connections to local address will now start triggering permission prompts. All of the current LNA enterprise policies will still apply to the LNA WebSockets restrictions (LocalNetworkAccessAllowedForUrls, LocalNetworkAccessBlockedForUrls, and LocalNetworkAccessRestrictionsTemporaryOptOut). More information about LNA can be found at https://developer.chrome.com/blog/local-network-access #
This feature was specified in this Spec.
Samples: https://lna-testing.notyetsecure.com
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.
Functionality added to the WebGPU spec after its first shipment in a browser. Allows GPUTextureViews to rearrange or replace the color components from texture's red/green/blue/alpha channels when accessed by a shader. #
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 0 features deprecated.
This release of Chrome had 0 features removed.