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 19 new features.
Now that prefetches and prerenders are utilizing the Sec-Purpose header for prefetches and prerenders, we will move to remove the legacy `Purpose: prefetch` header that is still currently passed. This will be behind a feature flag/ kill switch to prevent compatibility issues. This will be scoped to speculation rules prefetch, speculation rules prerender, <link rel=prefetch>, and Chromium's non-standard <link rel=prerender>. #
This feature was specified in this Spec.
Docs: https://fetch.spec.whatwg.org/#ref-for-http-sec-purpose%E2%91%A0https://wicg.github.io/nav-speculation/prefetch.html#ref-for-http-sec-purpose
No linked samplesariaNotify provides a JavaScript API that enables content authors to directly tell a screen reader what to read. ariaNotify improves reliability and developer control compared to ARIA live regions, allowing for announcing changes not tied to DOM updates. This enables more consistent and ergonomic accessibility experiences across dynamic web applications. Iframe usage of this feature can be controlled via a permission policy "aria-notify". #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1tFT-4_sDvgnZoS8AYEcQquXzqAYaoB53DBH0C2T5rMk
No linked samplesWhen iterating over window.getComputedStyle(element) in Chromium, there is a bug where it forgets to include any custom properties set on the element. (length() on the returned object forgets to account for the number of custom properties set.) We would like to fix this bug; it brings us closer to web standards, and to Firefox and Safari, which have never had this bug. There is a performance interaction with JavaScript libraries html2canvas and html-to-image; see the document below. More information: https://docs.google.com/document/d/17zz_asZ7E5ITjejp6Q6p4vqzETE3nEa28k2AC01X--s/edit?tab=t.0
This feature was specified in this Spec.
Websites can and do get credentials from mobile wallet apps through a variety of mechanisms today (custom URL handlers, QR code scanning, etc.). This Web Platform feature would allow sites to request identity information from wallets via Android's IdentityCredential CredMan system. It is extensible to support multiple credential formats (eg. ISO mDoc and W3C verifiable credential) and allows multiple wallet apps to be used. Mechanisms are being added to help reduce the risk of ecosystem-scale abuse of real-world identity (see https://docs.google.com/document/u/1/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit). #
This feature was specified in this Spec.
Samples: https://digitalcredentials.dev/docs/requirements
Adds support for phone numbers and usernames, in addition to or instead of a user's full name and email address as identifiers for disambiguating accounts in the account selector. Also, makes these new fields available for websites to affect the disclosure text. #
This feature was specified in this Spec.
This feature adds the getAllRecords() API to IndexedDB's IDBObjectStore and IDBIndex. It also adds a direction parameter to getAll() and getAllKeys(). This functionality enables certain read patterns to be significantly faster when compared to the existing alternative of iteration with cursors. One key workload from a Microsoft property showed a 350ms improvement. getAllRecords() effectively combines getAllKeys() and getAll() by enumerating both primary keys and values at the same time. For an IDBIndex, getAllRecords() also provides the record's index key in addition to the primary key and value. getAllRecords() can optionally return records in either ascending or descending order. This option is also back-ported to the existing operations getAll() and getAllKeys(). #
This feature was specified in this Spec.
Samples: https://patrickbrosset.com/articles/2024-11-19-even-faster-indexeddb-reads-with-getallrecordshttps://microsoftedge.github.io/Demos/idb-getallrecords
Normally, when navigateEvent.intercept() is called, the intercepted navigation commits (and therefore the URL updates) as soon as the NavigateEvent finishes dispatch. Adding a `precommitHandler` option to navigateEvent.intercept(), similar to `handler`, would defer the commit until that handler (and all other precommit handlers) are resolved, also allowing the handler to change the navigation's URL, info, status, and history handling behavior (push/replace). #
This feature was specified in this Spec.
Enables the HTTP disk cache to use the No-Vary-Search response header to share a cache entry between URLs that differ only in the query parameters. Developers can use No-Vary-Search to specify query parameters that have no impact on the user experience. A common example might be an id used to track conversions. Supporting this header in the HTTP disk cache means that if the user later goes back to that same page without the conversion id, it can be used or revalidated from the cache rather than having to be fetched from scratch from the network. Previously, No-Vary-Search support shipped for the navigation prefetch cache, prefetch and prerender speculation rules, and prerender. This launch makes it generally available to any feature that uses the HTTP disk cache. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1RS3q6qZ7-k9CvZsDYseGOXzcdQ9fGZ6YYnaW7fTPu7A/edit
No linked samplesThe new Permissions Policy enables restricting access to the Device Attributes API, which is available only for policy-installed kiosk web apps and policy-installed Isolated Web Apps, both only on managed ChromeOS devices. Additionally, the feature is controlled by content settings. 2 new policies are introduced: [DeviceAttributesBlockedForOrigins](https://chromeenterprise.google/policies/#DeviceAttributesBlockedForOrigins) and [DefaultDeviceAttributesSetting](https://chromeenterprise.google/policies/#DefaultDeviceAttributesSetting), to complement the introduced earlier [DeviceAttributesAllowedForOrigins](https://chromeenterprise.google/policies/#DeviceAttributesAllowedForOrigins). The feature is enabled by default for the supported scenarios described above.
This feature was specified in this Spec.
This feature provides web developers with a mechanism to verify the provenance of resources they depend upon, creating a technical foundation for trust in a site's dependencies. In short: servers can sign responses with a Ed25519 key pair, and web developers can require the user agent to verify the signature using a specific public key. This offers a helpful addition to URL-based checks offered by Content Security Policy on the one hand, and Subresource Integrity's content-based checks on the other. #
This feature was specified in this Spec.
On desktop, "eager" eagerness speculation rules prefetches and prerenders now trigger when users hover on a link for a shorter time than the "moderate" mouse hover time. The previous behavior, of starting prefetch/prerenders as soon as possible, was the same as "immediate" eagerness. This new behavior is more useful as it better reflects the author's intent to be more eager than the "moderate" and less eager than "immediate". More detail on this and other upcoming improvements to speculation rules eagerness are available at https://docs.google.com/document/d/1YPbtUPfZIDElzBZNx8IQMzRFvy8oauLG_i1XIr6jgTs/edit?usp=sharing. #
This feature was specified in this Spec.
In Chrome 141, Storage Access API semantics now strictly follow the Same Origin policy, to enhance security. Using `document.requestStorageAccess()` in a frame only attaches cookies to requests to the iframe's origin (not site) by default. The [CookiesAllowedForUrls](https://chromeenterprise.google/policies/#CookiesAllowedForUrls) policy or Storage Access Headers can still be used to unblock cross-site cookies. #
This feature was specified in this Spec.
restrictOwnAudio is a captured display surfaces constrainable property. This constrainable property changes the behavior of system audio in a captured display surface. The restrictOwnAudio constraint will only have an effect if the captured display surface inherently includes system audio; otherwise, it will have no impact. By default, when system audio is captured, it includes all audio played out by the system on audio output devices. When restrictOwnAudio is enabled, the captured system audio will be filtered to exclude audio originating from the document that performed getDisplayMedia. The restrictOwnAudio constraint allows for cleaner screen recordings for some use cases. Without it, if the capturing web page itself is playing audio (e.g. a video embedded on the on the recording page), that audio would be included in the capture. This could lead to an undesirable echo or interfere with the intended audio sources from other tabs or applications. The restrictOwnAudio constrainable property is described in the specification. https://www.w3.org/TR/screen-capture/#dfn-restrictownaudio
This feature was specified in this Spec.
This feature supports applying width and height as presentation attributes on nested <svg> elements through both SVG markup and CSS. This dual approach provides even greater flexibility for developers, allowing them to manage and style SVG elements more efficiently within complex designs. With this feature the below two html will now have the same output: With CSS Properties for nested <svg> element: <svg width="100px" height="100px"> <svg style="width:50px;height:50px;"> <circle cx="50px" cy="50px" r="40px" fill="green" /> </svg> </svg> Without CSS Properties for nested <svg> element: <svg width="100px" height="100px"> <svg width="50px" height="50px"> <circle cx="50px" cy="50px" r="40px" fill="green" /> </svg> </svg> #
This feature was specified in this Spec.
The spec recently had some small changes to the revealing algorithms for hidden=until-found and details elements in order to prevent the browser from getting stuck in an infinite loop: https://github.com/whatwg/html/pull/11457 #
This feature was specified in this Spec.
This API allows processing of encoded media flowing through an RTCPeerConnection. Chromium shipped an early version of this API in 2020. Since then, the spec has changed and other browsers have shipped the updated version of the spec (Safari in 2022 and Firefox in 2023). This launch refers to the latest spec version and is part of Interop 2025. This launch does not cover the generateKeyFrame method, which is still under discussion https://github.com/w3c/webrtc-encoded-transform/issues/143 https://github.com/w3c/webrtc-encoded-transform/issues/271 https://github.com/w3c/webrtc-encoded-transform/pull/269 #
This feature was specified in this Spec.
Samples: https://webrtc.github.io/samples/src/content/insertable-streams/endtoend-encryption
RTP stats objects, of type "outbound-rtp" or "inbound-rtp" in this case, represents a WebRTC stream. The identifier of this stream is the SSRC (a number). We should collect stats for streams that "exist", but implementations and spec has disagreed on when the stream should exist: if the SSRC information is conveyed via SDP, does the stream still exist before packets are sent or received? https://crbug.com/406585888 tries to reach alignment between browsers and spec. #
This feature was specified in this Spec.
Extends echoCancellation behavior of MediaTrackConstraints dictionary - former true/false - by values "all" and "remote-only". Allows the clients to modify echo cancellation behavior applied to audio tracks received from microphones, controlling how much of the user system playout (all, or only audio received from PeerConnections) is removed from the microphone signal.
This feature was specified in this Spec.
Extends DisplayMediaStreamOptions for getDisplayMedia() with a windowAudio option. This new option allows web applications to hint to the user agent whether the user should be offered the ability to share audio when a window is selected. windowAudio can be set to exclude, system, or window based on application preference. A web application that is configured for audio capture but wants to limit system audio capture when a window is selected should set windowAudio: "exclude".
This feature was specified in this Spec.
This release of Chrome had 4 new origin trials.
Introduces a new keywords to the script-src Content Security Policy (CSP) directive. This adds two new hash based allowlisting mechanisms: script sources based on hashes of URLs and contents of eval() and eval() like functions. We loosely refer to this as script-src-v2, although it is backwards compatible with the existing script-src, and uses the same directive. Extending hashes to cover URL and eval() hashes allows developers to set reasonably strict security policies by narrowly allowlisting scripts by their hashes even when script contents are subject to frequent changes, and known-safe contents of eval() without permitting unchecked use of eval() broadly. The new keywords override host-based script-src when provided. This allows a single header to be compatible with browsers that both do or do not implement the new keywords. #
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
A JavaScript API for proofreading input text with suggested corrections, backed by an AI language model. #
This feature was specified in this Spec.
Allows WebAssembly to store data associated with source-level types more efficiently in new "custom descriptor" objects. These custom descriptors can be configured with prototypes for the WebAssembly objects of that source-level type. This allows methods to be installed on a WebAssembly object's prototype chain and called directly from JS using normal method call syntax. The prototypes and methods can be configured declaratively using an imported builtin function. #
This feature was specified in this Spec.
This release of Chrome had 3 are available behind a flag.
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
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.
Enables smart card (PC/SC) applications to move to the Web platform. It gives them access to the PC/SC implementation (and card reader drivers) available in the host OS. Administrators can control the availability of this API either: - Globally—using the DefaultSmartCardConnectSetting policy. - Per-application—using the SmartCardConnectAllowedForUrls and SmartCardConnectBlockedForUrls policies. #
This feature was specified in this Spec.
Samples: https://github.com/GoogleChromeLabs/web-smartcard-demo
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.