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.
The HTML parser has always (or for a long time) allowed elements and attributes to have a wide variety of valid characters and names, but the javascript DOM APIs to create the same elements and attributes are more strict and don't match the parser. This change relaxes the validation of the javascript DOM APIs to match the HTML parser. More context here: https://github.com/whatwg/dom/issues/849 I don't anticipate any compat issues from this change because all of the previously allowed element/attribute names are still allowed with the new behavior. #
This feature was specified in this Spec.
Introduce @container anchored(fallback) to style descendants of anchor positioned elements based on which of position-try-fallbacks is applied. Such queries can be used to e.g. style an anchored element's tether, its animations, etc. based on how the anchor and the anchored element are positioned relative to each other. Example: #anchored { position-try-options: flip-block; container-type: anchored; } @container anchored(fallback: flip-block) { #anchored > .arrow { --arrow-rotation: 180deg; } } #
This feature was specified in this Spec.
Samples: https://codepen.io/una/pen/ZYbzrLg
Populate the dataTransfer property on input events with inputType of insertFromPaste, insertFromDrop, and insertReplacementText to provide access to clipboard and drag-drop data during editing operations in contenteditable elements. The dataTransfer object contains the same data that was available during the beforeinput event. This feature only applies to contenteditable elements. For form controls (textarea, input), the behavior remains unchanged - the data property contains the inserted text and dataTransfer remains null. Both Safari and Firefox already support this functionality. Chromium adopting this feature will enhance interoperability across browsers, providing a more consistent experience for web authors. #
This feature was specified in this Spec.
Chromium shipped https://developer.mozilla.org/en-US/docs/Web/API/EditContext with a bug where the https://developer.mozilla.org/en-US/docs/Web/API/TextFormat object supplied by the https://developer.mozilla.org/en-US/docs/Web/API/EditContext/textformatupdate_event provides incorrect values for the underlineStyle and underlineThickness properties. In Chromium the possible values are {“None”, “Solid”, “Dotted”, “Dashed”, “Squiggle”} and {“None”, “Thin”, “Thick”}, when per https://w3c.github.io/edit-context/#dom-underlinestyle they should be {“none”, “solid”, “dotted”, “dashed”, “wavy”} and {“none”, “thin”, “thick”}. This Intent covers switching TextFormat.underlineStyle and TextFormat.underlineThickness to use the spec values. This change is valuable because it aligns these attributes with existing CSS https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-style and the https://www.w3.org/TR/design-principles/#casing-rules. Since the purpose of the TextFormat properties is to be used in applying these text styles to text being composed on behalf of an IME, it will be more convenient for developers if the underlineStyle value can be applied directly from the event to CSS without need for a remapping. For both underlineStyle and underlineThickness, matching the platform lower-case convention will reduce the likelihood of developer confusion. #
This feature was specified in this Spec.
To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700. In Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
This feature was specified in this Spec.
Migration of nonce to params Field: The nonce parameter in navigator.credentials.get() is moving from a top-level field to the params object for better API design, extensibility, and maintainability. This structured approach simplifies parsing for Identity Providers, supports future-proofing without versioning, and aligns with modern API patterns. For Relying Parties, the impact is minimal—they provide the same nonce value in a new location. In Chrome 143 (Warning Phase): nonce accepted both at top level and inside params. Top-level usage triggers a console warning. Rename code to error in IdentityCredentialError: The code attribute in IdentityCredentialError is renamed to error for clearer semantics, better developer experience, and alignment with web standards. This change reduces ambiguity and avoids conflicts with DOMException.code. Additionally, error.code becomes error.error, retaining its DOMString type. In Chrome 143 (Warning Phase): Both error and code attributes are supported. Using code triggers a console warning, guiding developers to migrate. #
This feature was specified in this Spec.
Allows Identity Providers (IdPs) to return structured JSON objects instead of plain strings to Relying Parties (RPs) via the id_assertion_endpoint. This change simplifies integration for developers by eliminating the need to manually serialize and parse JSON strings. It enables more dynamic and flexible authentication flows, allowing RPs to interpret complex responses directly and support varied protocols like OAuth2, OIDC, or IndieAuth without out-of-band agreements. #
This feature was specified in this Spec.
Add ongamepadconnected and ongamepaddisconnected event handlers to the WindowEventHandlers interface mixin. This would enable support for window.ongamepad[dis]connected or document.body.ongamepad[dis]connected event handler attributes. #
This feature was specified in this Spec.
The Unicode support library, International Components for Unicode (ICU), is upgraded from version 74.2 to version 77.1, adding support for Unicode 16 and updating locale data. Two changes could pose some risk for web applications that assume a specific format from the [Intl](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Internationalization) JS APIs: 1. The default Italian number formatting changed to omit the thousand separator for 4-digit numbers. For example, `new Intl.NumberFormat("it").format(1234)` will return `1234` instead of `1.234`. The old behavior can be achieved with the `useGrouping` parameter for the `Intl.NumberFormat` constructor. 2. In some English locales (en-AU, en-GB, and en-IN), a comma was added after full-length weekdays, for example, changing Saturday 30 April 2011 to Saturday, 30 April 2011. Web applications should avoid relying on the precise formatting of dates and they may change again in future. #
This feature was specified in this Spec.
Docs: https://unicode-org.github.io/icu/download/77.htmlhttps://cldr.unicode.org/downloads/cldr-47https://www.unicode.org/versions/Unicode16.0.0
Samples: https://mathiasbynens.github.io/caniunicode
This feature introduces support for the font-language-override CSS property in Chromium. The property allows developers to override the system language used for OpenType glyph substitution by specifying a four-character language tag directly in CSS. This enables fine-grained typographic control, particularly useful for multilingual content or fonts with language-specific glyph variants. #
This feature was specified in this Spec.
This experiment would change when spelling and grammar hints are applied to text fields to reduce the of websites ability to extract information about the user’s dictionary, specifically: * Hints would not be applied to a text field that has not had user interaction (an autofocus is insufficient, there must be a click or key press of some kind relative to that field). * Hints would only be applied once per user interaction (the text cannot be changed programmatically and have hints applied without a click or key press of some kind relative to that field). #
On mobile, "eager" eagerness speculation rules prefetches and prerenders now trigger when HTML anchor elements are in the viewport for a short 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.
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
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.
Users of https://chromestatus.com/feature/5680189201711104 found that the API as specified was not ergonomic for subsequent offer/answer. The WG has adopted a revised behavior, merged to spec in https://github.com/w3c/webrtc-extensions/pull/238, that ensures that subsequent offer/answer does not permute the header extensions negotiated unless the user wants that to happen. #
This feature was specified in this Spec.
WebTransport Application Protocol Negotiation allows negotiation of the protocol used by the web application within the WebTransport handshake. A web application can specify a list of application protocols offered when constructing a WebTransport object, which are then conveyed to the server via HTTP headers; if the server picks one of those protocols, it can indicate that within response headers, and that reply is available within the WebTransport object. #
This feature was specified in this Spec.
This release of Chrome had 3 new origin trials.
This Web Platform feature enables issuing websites (e.g., a university, government agency, or bank) to securely initiate the provisioning (issuance) process of digital credentials directly into a user's mobile wallet application. On Android, this capability leverages the Android IdentityCredential CredMan system (Credential Manager). On Desktop, it leverages cross-device approaches using the CTAP protocol similar to Digital Credentials presentation. #
This feature was specified in this Spec.
By exploiting limits in the connection pool size on Chrome, knowledge can be gained about cross-site state which would otherwise be inaccessible. Specifically, it’s possible (with some statistical certainty) to evaluate the login state, visited history, or even something more specific like whether gmail has pending messages in the inbox. To mitigate this we are adding randomization to the way that TCP socket pools are limited so that an observing site cannot infer this information with high certainty. #
Allows a website to install a web app. The API provides 3 signatures, with 0, 1, and 2 parameters, respectively. When invoked, the website installs either itself, or another site from a different origin, as a web app (depending on the provided parameters). All 3 signatures will be experimented with in parallel. *Terminology - A site installing itself is a "current document install". A site installing another site is a "background document install". #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/12nSXJLm8mW0gWZ_yjlXfrV8r9gwJliVt4WVa-209-KA/edit?tab=t.0
Samples: https://kbhlee2121.github.io/pwa/web-install/index.htmlhttps://microsoftedge.github.io/Demos/pwa-pwastore
This release of Chrome had 7 are available behind a flag.
[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) plans to deprecate and remove XSLT from the web platform. 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 samplesThe bytes() method of the Blob interface returns a Promise that resolves with a Uint8Array containing the contents of the blob as an array of bytes.
This feature was specified in this Spec.
Docs: https://w3c.github.io/FileAPI/#dom-blob-bytes
No linked samplesThis experiment would change when spelling and grammar hints are applied to text fields to reduce the of websites ability to extract information about the user’s dictionary, specifically: * Hints would not be applied to a text field that has not had user interaction (an autofocus is insufficient, there must be a click or key press of some kind relative to that field). * Hints would only be applied once per user interaction (the text cannot be changed programmatically and have hints applied without a click or key press of some kind relative to that field). #
ECMAScript proposal for Map.prototype.getOrInsert, Map.prototype.getOrInsertComputed, WeakMap.prototype.getOrInsert, and WeakMap.prototype.getOrInsertComputed. #
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.
This feature adds an `at-rule()` function to CSS `@supports` which enables authors to feature-detect support for CSS at-rules. #
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.
Intl Locale Info API is a Stage 3 ECMAScript TC39 proposal to enhance the Intl.Locale object by exposing Locale information, such as week data (first day in a week, weekend start day, weekend end day, minimun day in the first week), and text direction hour cycle used in the locale. https://github.com/tc39/proposal-intl-locale-info We ship our implementation in m99 (https://chromestatus.com/feature/5566859262820352 ) . But later on the propose made some change in Stage 3 and move several getters to functions. We need to remove the deprecated getters and relaunch the renamed functions #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1BSpa-LKE69LL1g5CHZ3G06XEfffauwS24atfSUQiIDY/edit
Samples: https://github.com/tc39/proposal-intl-locale-info
This release of Chrome had 0 features removed.