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.
For a small number (hundreds) of hand-curated static third-party script, stylesheet and compression-dictionary resources that are used on a large portion of the web, Chrome will use a single-keyed HTTP cache to store those resources. This helps users and site owners with faster performance for those resources that are very widely used while maintaining the privacy protections of the partitioned disk cache. This feature targets the resources that most users are likely to see multiple times across multiple sites in any given browsing session. They are usually not in the critical path of the page loading and may not impact the common performance metrics but they are still important for the healthy operation of the web. The list of candidate scripts is curated from the HTTP Archive dataset. This includes site-independent things like common analytics scripts, social media embeds, video player embeds, captcha providers and ads libraries. It allows for code that uses versioned URLs as long as the versioning is not a manual process by embedders and that the same version is sent to everybody at a given point in time with the same contents. This does not include things like common Javascript libraries where they are commonly self-hosted or where the URL references a specific version of the library and it is up to site owners to manually select a version. #
Docs: https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing
No linked samplesPreserve MIME type parameters (e.g., charset, boundary) in data URL Content-Type headers per the Fetch Standard. CL: https://chromium-review.googlesource.com/c/chromium/src/+/7135039 #
This feature was specified in this Spec.
A TC39 proposal to create iterators by sequencing existing iterators. Introduces Iterator.concat ( ...items ). #
This feature was specified in this Spec.
Changes the LCP algorithm to emit candidates based on the largest painted image instead of the largest pending-but-not-yet-painted image. This might cause more intermediate candidates to be emitted to the performance timeline. In each animation frame, after it has been presented, the LCP algorithm will emit a new candidate (at most one) to the performance timeline if there is a new largest text or image that was painted in that frame. But the algorithm also tracks the "largest pending image", which is the largest still-loading image, and uses that image's size to determine whether the new candidate is largest. This means a slow loading large image can prevent emission of intermediate LCP candidates, and such candidates are often useful information for developers to understand the loading progression. This behavior came up during Interop 2025 as a difference with other engines, and we all agreed to align on emitting at most one candidate per frame based on the set of painted image/text elements for that frame. #
This feature was specified in this Spec.
Currently when intercepting navigations with the `navigate` event, precommitHandlers and post-commit ordinary handlers are passed separately. This works well when there is only one or the other, but can be a bit clunky when the flow includes a precommitHandler that leads to a post-commit handler. This addition is a small ergonomic improvement that enables registering a post-commit handler while invoking a precommit handler. #
This feature was specified in this Spec.
This feature adds an AudioContext.playbackStats attribute which returns an AudioPlaybackStats object. This object provides audio playback statistics such as average latency, minimum/maximum latency, underrun duration, and underrun count. This API allows web applications to monitor audio playback quality and detect glitches. Note: This feature was previously tracked as AudioContext.playoutStats. It has been renamed to AudioContext.playbackStats to align with the final Web Audio API specification. The old name is supported as a deprecated alias for backward compatibility. #
This feature was specified in this Spec.
Update the Launch Handler implementation to ensure LaunchParams.targetURL is populated when a PWA is launched via File Handling. Previously, this property was null when a file launch was directed to an existing window. This change ensures that the URL from the developer's manifest "action" field (the same url the document is required to be currently loading) is available to the launchQueue consumer. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/pwa-testing/principled-ring-yarrow
The HTML5 Drag and Drop API allows web applications to handle drag-and-drop operations through a series of events: `dragstart`, `dragenter`, `dragover`, `dragleave`, `drop`, and `dragend`. During these events, the [`dataTransfer.dropEffect`](https://www.w3.org/TR/2011/WD-html5-20110113/dnd.html#dom-datatransfer-dropeffect) property indicates which operation (copy, move, link, or none) should be performed. According to the [HTML5 specification](https://www.w3.org/TR/2011/WD-html5-20110113/dnd.html#dndevents), the `dropEffect` value set by web applications during the last `dragover` event should be preserved and available in the subsequent `drop` event. However, Chromium-based browsers were overwriting the web application's `dropEffect` value with the browser's own negotiated operation before the `drop` event fired, breaking specification compliance and limiting developer control over drag-and-drop behavior. #
This feature was specified in this Spec.
The Sanitizer API offers an easy to use and safe by default HTML Sanitizer API, which developers can use to remove content that may execute script from arbitrary, user-supplied HTML content. The goal is to make it easier to build XSS-free web applications. This follows previous attempts at establishing a Sanitizer API (https://chromestatus.com/feature/5786893650231296), which we unshipped again (https://chromestatus.com/feature/5115076981293056). The specification has meanwhile progressed and now has widespread support. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_APIhttps://sanitizer-api.dev
This feature allows for multiple custom element definitions for a single tag name to exist within a page to prevent custom element name conflicts when a web app uses libraries from multiple sources. This is achieved by allowing user code to create multiple custom element registries and associate them with tree scopes and elements that function as scoping object for custom element creation/definition/upgrade. #
This feature was specified in this Spec.
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
When a user grants a website permission to access a powerful API (specifically Bluetooth, Camera, Clipboard, DisplayCapture, Geolocation, Microphone, Serial, and USB), their consent is intended for the site, not necessarily to every third-party script running on the page. In particular, embedded ad scripts running in the main frame or same-origin iframes can currently leverage the page's permission to opportunistically access this sensitive data. The user may not be aware that an advertisement is accessing their information. This intervention aims to better align a granted permission with user intent by preventing ad script in a context with API permission from using it, reinforcing user trust and control over their data. #
This feature was specified in this Spec.
Prevent the launchQueue from re-sending the last LaunchParams (including file handles) when a user reloads the page. Currently, a page refresh triggers the launch consumer again with the data from the original launch. This change ensures that a reload is treated as a standard navigation rather than a "re-launch," and the launchQueue will not be populated with duplicate files unless a new file launch event occurs. The re-queueing was never spec'd, and was an unfortunate never-removed stop-gap that was implemented before file handles could be saved to IndexedDB. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/pwa-testing/principled-ring-yarrow
The two optional keywords for the `text-indent` property extends the capability and the usability of the property. The `hanging` keyword changes indentation to "hanging", that is, all lines except the first line will be indented. The `each-line` keyword makes indentation to affect not only the first line but also each line after a forced line break. #
This feature was specified in this Spec.
Adds an opt-in, lightly restricted subset of the WebGPU API capable of running older graphics APIs such as OpenGL and Direct3D11. By opting into this mode and obeying its constraints, developers can extend the reach of their WebGPU applications to many older devices that do not have the modern, explicit graphics APIs that core WebGPU requires. For simple applications, the only required change is to specify the "compatibility" featureLevel when calling requestAdapter. For more advanced applications, some modifications may be necessary to accommodate the mode's restrictions. Since Compatibility mode is a subset, the resulting applications are also valid WebGPU Core applications and will run even on user agents that do not support Compatibility mode. #
This feature was specified in this Spec.
Samples: https://webgpu.github.io/webgpu-samples/?sample=helloTrianglehttps://webgpu.github.io/webgpu-samples/?sample=computeBoidshttps://webgpu.github.io/webgpu-samples/?sample=deferredRendering
Add a language feature to WGSL, `texture_and_sampler_let` that adds the ability to store texture and sampler objects into a let declaration in WGSL. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. A new TRANSIENT_ATTACHMENT GPUTextureUsage lets developers create attachments that allow render pass operations to stay in tile memory, avoiding VRAM traffic and potentially avoiding VRAM allocation for the textures. #
This feature was specified in this Spec.
Makes the root element's default font size scale in proportion to both the operating system's and browser's text scale setting. This allows pages that follow best practices around font-relative units (i.e. use rem and em for font sizes and page elements that should change with the user's text size preferences) to respect the user's OS-level text scale setting. This also causes the browser to disable existing browser-based mechanisms (i.e. full-page zoom on windows) and heuristics (i.e. text autosizing on mobile). Now web developers can signal to the browser that the page is constructed in a way (i.e. with rem and em) that will scale well across various user-selected font size preferences. Similar to env(preferred-text-scale), which provides authors with a way to access the text scale; this API extends that by enabling scaling via the root element's default font size and opting-out of automatic text scaling. #
This feature was specified in this Spec.
trigger-scope gives authors the ability to limit the names of animation triggers declared by trigger-instantiating properties. Trigger-Instantiating properties, such as timeline-trigger, declare names which can be referenced by the animation-trigger property in order to attach animations to triggers. However, these names are global by default (similar to anchor-name) and it is often useful for author to limit the visibility of the names so as to isolate animation-to-trigger interactions. #
This feature was specified in this Spec.
This release of Chrome had 3 new origin trials.
Starting in Chrome 151, Chrome will introduce the CPU Performance API, which allows web applications to determine the performance tier 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/utilization and allows applications to react to changes in CPU pressure. Users can override the reported performance tier 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.
Gives authors the ability to declaratively give composite widgets arrow key navigation, a guaranteed tab stop, and last-focused memory, replacing hand-coded roving tabindex scripts. Example: <div focusgroup="toolbar wrap" aria-label="Formatting"> <button>Bold</button> <button>Italic</button> <button>Underline</button> </div> #
This feature was specified in this Spec.
This extends speculation rules syntax to allow developers to specify the form_submission field for prerender. This field directs the browser to prepare the prerender as a form submission, so that it can be activated by real form submission navigations. Examples include a simple search form which results in a /search?q=XXX GET request navigation, support of which has been requested by web developers. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/13Xr_kSYZtvhRNaKpCiP7wLKYtDcpLdDWSH4y6gHq0kQ/edit?usp=sharing
Samples: https://chrome.dev/prerender-demos/prerender-get-form.html
This release of Chrome had 6 are available behind a flag.
Gives authors the ability to declaratively give composite widgets arrow key navigation, a guaranteed tab stop, and last-focused memory, replacing hand-coded roving tabindex scripts. Example: <div focusgroup="toolbar wrap" aria-label="Formatting"> <button>Bold</button> <button>Italic</button> <button>Underline</button> </div> #
This feature was specified in this Spec.
This extends speculation rules syntax to allow developers to specify the form_submission field for prerender. This field directs the browser to prepare the prerender as a form submission, so that it can be activated by real form submission navigations. Examples include a simple search form which results in a /search?q=XXX GET request navigation, support of which has been requested by web developers. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/13Xr_kSYZtvhRNaKpCiP7wLKYtDcpLdDWSH4y6gHq0kQ/edit?usp=sharing
Samples: https://chrome.dev/prerender-demos/prerender-get-form.html
Prevent the launchQueue from re-sending the last LaunchParams (including file handles) when a user reloads the page. Currently, a page refresh triggers the launch consumer again with the data from the original launch. This change ensures that a reload is treated as a standard navigation rather than a "re-launch," and the launchQueue will not be populated with duplicate files unless a new file launch event occurs. The re-queueing was never spec'd, and was an unfortunate never-removed stop-gap that was implemented before file handles could be saved to IndexedDB. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/pwa-testing/principled-ring-yarrow
Unframed mode extends the Isolated Web App (IWA) client area to encompass the entire window, including the regions normally reserved for the title bar and system window controls. This provides developers with complete control over the application's visual layout, enabling bespoke, immersive experiences and custom window branding. In this mode, the application is responsible for rendering all visual elements and handling user input across the entire window surface. #
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
WebMCP is a proposal for a web API that enables web pages to provide agent-specific paths in their UI. With WebMCP, agent-service interaction takes place via app-controlled UI, providing a shared context available to app, agent, and user. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1ZaQvuj4YnUnoqOfEhbfgFynpDRKk2zZZHavTNJ151gM/edit?tab=t.0#heading=h.ggi78l861caahttps://docs.google.com/document/d/1ycdzuXA-VE8lRDFSArh0Um3PChHV0Hq6Om1MSMG8qPE/edit?tab=t.0#heading=h.edohi3f5z12h
No linked samplesThe named-feature() function allows CSS @supports rules to query for a small set of specific named features that are not possible to test for using other @supports mechanisms but which are considered highly valuable to test for. #
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.