Chrome Enterprise and Education release notes

Last updated on: March 25, 2026 

For administrators who manage Chrome browser or ChromeOS devices for a business or school.

 

Select the required tab to see Chrome browser or ChromeOS updates.

Want to remotely manage ChromeOS devices? Start your Chrome Enterprise Upgrade trial at no charge today

 

Important update: Starting March 26th, 2026, the release notes for Chrome browser for Enterprise are moving! Find them exclusively on our website: chromeenterprise.google. Please update your bookmarks. (Note that ChromeOS release notes will continue to be published at this current link and will not move.)

Chrome 147 release summary

 
Chrome browser changes Security/ Privacy User productivity/ Apps Management
AI Mode and Lens enhancements   ✓  
Gemini in Chrome   ✓  
X25519Kyber768 key encapsulation for TLS ✓    
CSS update: decoupling of Width and Style properties     ✓
Chrome for iOS background customization for New tab page   ✓  
Device Bound Session Credentials ✓    
Local network access restrictions ✓    
Report-a-Scam ✓    
Vertical tabs   ✓  
UI Automation accessibility framework provider on Windows   ✓  
New policies in Chrome browser     ✓
Removed policies in Chrome browser     ✓
Chrome Enterprise Core changes Security/ Privacy User productivity/ Apps Management
Block extensions based on third-party risk scores ✓   ✓
Block extensions using Chrome Web Store categories ✓   ✓
New organization publishing option in the Chrome Web Store ✓   ✓
Gen AI and SaaS app usage reporting ✓   ✓
Chrome Enterprise Premium changes Security/ Privacy User productivity/ Apps Management
Increased file size support for DLP scans ✓   ✓
New templates for Data Loss Prevention rules ✓   ✓
Streamlined Chrome Enterprise to Google SecOps Integration ✓    
Support for allowlist and blocklist for Developer Tools ✓   ✓
Support for allowlist and blocklist for Incognito mode ✓   ✓
Upcoming Chrome browser changes Security/ Privacy User productivity/ Apps Management
Chrome Profile Bootstrapping via Custom URI ✓ ✓  
Enhanced autofill   ✓  
Extended lifetime shared workers     ✓
PWA origin migration   ✓  
Prompt API   ✓ ✓
Chrome for ARM64 Linux devices   ✓  
Update to No HTTPS warning ✓    
Always Use Secure Connections by default ✓    
Deprecation and removal of Privacy Sandbox APIs ✓ ✓  
Isolated Web Apps     ✓
SafeBrowsing API v4 to v5 migration ✓    
Chrome to remove support for macOS 12     ✓
Deprecate and remove XSLT ✓ ✓ ✓
Chrome moving to a 2-week release cycle     ✓
PostQuantum cryptography for DTLS in WebRTC ✓    
Disallow spaces in non-file:// URL hosts ✓    
Upcoming Chrome Enterprise Core changes Security/ Privacy User productivity/ Apps Management
Chrome client certificate support on iOS ✓   ✓
Managed profile reporting support     ✓
Upcoming Chrome Enterprise Premium changes Security/ Privacy User productivity/ Apps Management
Chrome Enterprise Connectors API ✓   ✓
Drag support for data controls ✓    
Enterprise extension DOM activity telemetry ✓    
New policy setting for DataControlRules ✓   ✓
Hardening against local policy tampering ✓   ✓

 

↑ back to top

The enterprise release notes are available in 9 languages. You can read about Chrome's updates in English, German, French, Dutch, Spanish, Portuguese, Korean, Indonesian, and Japanese. Allow 1 to 2 weeks for translation for some languages.

Chrome Enterprise and Education release notes are published in line with the Chrome release schedule, on the Early Stable date for Chrome browser.

 

Important update: Starting March 26th, 2026, the release notes for Chrome browser for Enterprise are moving! Find them exclusively on our website: chromeenterprise.google. Please update your bookmarks. (Note that ChromeOS release notes will continue to be published at this current link and will not move.)

Chrome browser changes  

   

  • AI Mode enhancements back to top

    Chrome 143 integrates new AI Mode capabilities into Chrome on macOS and Windows. Users will be able to access AI Mode directly from the New tab page and the omnibox, allowing users to ask complex questions directly from where they start browsing. This will start rolling out in Chrome 143 on macOS and Windows. Admins can turn off these features (value 1) using the AIModeSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see the relevant section in the Help Center.

    Also coming in Chrome 144 is the multi-tab context feature. Users can choose to share the contents of one or more of their open tabs with AI Mode, helping them ask questions, compare, summarize, and find information more efficiently. Admins will be able to turn off these features (value 1) using the SearchContentSharingSettings policy (available in Chrome 144) or by using the GenAiDefaultSettings (value 2).

    In Chrome 145, we rolled out the multi-tab context feature on AI Mode and Lens. Users can choose to share the contents of one or more of their open tabs, helping them ask questions, compare, summarize, and find information more efficiently. Admins can turn off these features (value 1) using the SearchContentSharingSettings policy or by using the GenAiDefaultSettings (value 2). Also in Chrome 145 on Android and iOS, new AI Mode capabilities were integrated into Chrome browser.

    In Chrome 146, Google Drive files become available as context. Admins can turn off these features (value 1) using the SearchContentSharingSettings policy.

    In Chrome 147, admins use SearchContentSharingSettings to control these features. Google Lens policies are deprecated: LensOverlaySettings, LensDesktopNTPSearchEnabled and LensRegionSearchEnabled.

   

  • Gemini in Chrome back to top

    Gemini is now integrated into Chrome on macOS, Windows and selective ChromeOS devices, and can understand the content of your current page. Users can now seamlessly get key takeaways, clarify concepts, and find answers, all without leaving their Chrome tab. This integration includes both chat—where users can interact with Gemini via text, and Gemini Live, with which users can interact with Gemini via voice.

    In Chrome 143, Gemini in Chrome started to roll out to most Google Workspace users with access to the Gemini app in the US. Admins can turn off this feature (value 1) using the GeminiSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see Gemini in Chrome in the Help Center or this blog post.

    Also in Chrome 143, we announced the multi-tab context feature. Gemini in Chrome can now see more of your opened tabs (10 max) so you can ask questions across multiple pages to help you compare, find information more efficiently. Gemini in Chrome also serves as a productivity agent. Gemini in Chrome automatically uses public information from these Google services: Google Search, Google Maps, YouTube. With your permission, Gemini in Chrome can help you connect your personal information and content in Google Workspace services (Gmail, Drive, Keep, Calendar, and Tasks).

    In Chrome 144, auto browse in Gemini in Chrome was made available to some users (non-enterprise). An enterprise policy GeminiActOnWebSettings will be available at launch.

    For more details, see the rollout steps below.

   

  • X25519Kyber768 key encapsulation for TLS back to top

    Chrome 124 enabled by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism X25519Kyber768, based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both TLS 1.3 and QUIC connections.

    However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary PostQuantumKeyAgreementEnabled enterprise policy, which will be available through Chrome 145. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed in Chrome 147. Post-quantum cryptography is required for CSNA 2.0. To learn more, see Protect Chrome Traffic with Hybrid Kyper KEM.

    • Chrome 131 on Linux, macOS, Windows: Chrome will switch the key encapsulation mechanism to the final standard version of ML-KEM.
    • Chrome 147 on Linux, macOS, Windows: PostQuantumKeyAgreementEnabled enterprise policy will be removed.

   

  • CSS update: decoupling of Width and Style properties back to top

    Chrome 147 aligns with updated CSS specifications regarding the behavior of border-width, outline-width, and column-rule-width properties. Previously, if the corresponding border-style, outline-style, or column-rule-style was set to none or hidden, the computed width of these properties would be forced to 0px, regardless of the specified value.

    With this change, the computed values of border-width, outline-width, and column-rule-width will always reflect the author-specified values, independent of the *-style property. Additionally, the resolved values (as returned by getComputedStyle()) for outline-width and column-rule-width will also reflect the specified values.

    The change aligns Chrome with Firefox and WebKit, which have already implemented this behavior.

    • Chrome 147 on Windows, macOS, Linux, Android: No rollout step.

   

  • Chrome for iOS background customization for New tab page back to top

    Chrome for iOS will now allow users to customize their New tab page background. Admins can set NTPCustomBackgroundEnabled to True or False, which allows users to customize their New tab page background. The admin can set the BrowserThemeColor, which supports a hex code for specifying a color. If a hex value is specified, the user will not be able to override it. Admins can also specify a recommended hex value, which the user can override. If fully enabled, users can also choose from the pre-selected gallery within Chrome, or from their phone's camera roll.

    • Chrome 147 on iOS - Feature rolls out gradually: In Chrome 146 on iOS, background customization begins gradual roll-out, following usual gradual roll-out. In Chrome 147 on iOS, syncing themes feature begin to roll out gradually.

   

  • Device Bound Session Credentials back to top

    To enhance user security and combat session cookie theft, Chrome is introducing Device Bound Session Credentials (DBSC). 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.

    • Chrome 145 on Windows: Feature rolls out gradually.
    • Chrome 147 on macOS: Feature rolls out gradually.

   

  • Local network access restrictions back to top

    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, 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.

    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 provided 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 and LocalNetworkAccessPermissionsPolicyDefaultEnabled. These policies can be set using custom configurations.

    Chrome 147 expands Local Network Access restrictions to include WebSocket and WebTransport connections.

    • Chrome 145 on Android, Linux, macOS, Windows, Fuchsia: The permission split is rolled out.
    • Chrome 146 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Two new enterprise policies will be available for managing local network access restrictions: LocalNetworkAccessIpAddressSpaceOverrides could be used to mark IPv4 and IPv6 address blocks as public or private. IP ranges that are treated as public will not cause permission prompts when accessed by other pages. For example, CGNAT 100.64.0.0/10 can be marked as public. This is useful for certain VPN and proxy setups. Marking 0.0.0.0/0 and ::/0 as public is equivalent to disabling the local network access restrictions. LocalNetworkAccessPermissionsPolicyDefaultEnabled can be used to cause the LNA permission to be automatically delegated to iframes by the parent frame, without requiring explicit annotation of the child iframes. This is useful in situations where local network access is performed by an embedded SaaS tool inside of a different SaaS tool. This includes certain locally hosted documentation and knowledgebase softwares.
    • Chrome 147 on Android, ChromeOS, Linux, macOS, Windows: Local Network Access restrictions expanded to include WebSocket and WebTransport connections.
    • Chrome 152 on Android, ChromeOS, Linux, macOS, Windows: LocalNetworkAccessRestrictionsTemporaryOptOut policy will be removed.

   

  • Report-a-Scam back to top

    With Safe Browsing switched on, users can report web pages directly to Safe Browsing from Chrome using the Help menu.
    Admins can opt out of this feature by turning off Safe Browsing using SafeBrowsingProtectionLevel or by disallowing user feedback with the UserFeedbackAllowed policy.

    • Chrome 147 on ChromeOS, Linux, macOS, Windows - Feature rolls out gradually.

   

  • Vertical tabs back to top

    Chrome Desktop introduces a vertical tab strip to improve tab management for users who handle many tabs. This feature addresses the difficulty of finding and organizing tabs by displaying full page titles, enhancing tab group usage, and optimizing the use of vertical screen space.

    • Chrome 147 on Linux, macOS, Windows - Feature rolls out gradually: Feature rolls out gradually on MacOS, Windows and Linux.
    • Chrome 148 on ChromeOS: Feature rolls out gradually on ChromeOS.

   

  • UI Automation accessibility framework provider on Windows back to top

    Chrome 126 began to directly support accessibility client software that uses Microsoft Windows's UI Automation accessibility framework. Prior to this change, such software interoperated with Chrome by way of a compatibility shim in Microsoft Windows. This change is being made to improve the accessible user experience for many users. It provides complete support for Narrator, Magnifier, and Voice Access; and will improve third-party apps that use Windows's UI Automation accessibility framework. Users of Chrome will find reduced memory usage and processing overhead when used with accessibility tools. It will also ease development of software using assistive technologies.

    Administrators can use the UiAutomationProviderEnabled enterprise policy starting in Chrome 125 to either force-enable the new provider (so that all users receive the new functionality), or disable the new provider.

    This policy will be supported through Chrome 146 and will be removed in Chrome 147. This one-year period allowed enterprises sufficient time to work with third-party vendors so that they might fix any incompatibilities resulting from the switch from Microsoft's compatibility shim to Chrome's UI Automation provider.

    • Chrome 125 on Windows: The UiAutomationProviderEnabled policy is introduced so that administrators can enable Chrome's UI Automation accessibility framework provider and validate that third-party accessibility tools continue to work.
    • Chrome 126 on Windows: The Chrome variations framework will be used to begin enabling Chrome's UI Automation accessibility framework provider for users. It will be progressively enabled to the full stable population, with pauses as needed to address compatibility issues that can be resolved in Chrome. Enterprise administrators may continue to use the UiAutomationProviderEnabled policy to either opt-in early to the new behavior, or to temporarily opt-out through Chrome 146.
    • Chrome 147 on Windows: The UiAutomationProviderEnabled policy will be removed from Chrome. All clients will use the browser's UI Automation accessibility framework provider.

    

   

 

Chrome Enterprise Core changes

   

  • Block extensions based on third-party risk scores back to top

    As early as Chrome 147, admins can configure a risk threshold in the Google Admin Console's Apps and Extensions settings to automatically block extensions using third-party risk assessments (Spin.Ai and LayerX). This feature simplifies extension management and reduces the manual work required to assess and block high-risk extensions. Extensions that exceed the configured risk score threshold will be automatically disabled on the client side, and new installations will be blocked. Chrome 147 allows a Trusted Tester preview, with the feature gradually rolling out in Chrome 148.

    • Chrome 147 on Linux, macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester.
    • Chrome 148 on Linux, macOS, Windows - Feature rolls out gradually.

   

  • Block extensions using Chrome Web Store categories back to top

    As early as Chrome 147, admins could enhance security by automatically blocking Chrome extensions based on their Chrome Web Store categories, for example, blocking all Games extensions. This feature prevents extensions from blocked categories being installed and disables them if already present. Force-installed and allow-listed extensions remain unaffected.

    This setting is only available in the Google Admin console under Apps & Extensions > Settings, within the new Advanced extension blocking section. The setting name is Block by category. It can also be configured using the Chrome Management APIs. This setting is not available for locally-managed devices.

    Chrome 147 allows a Trusted Tester preview, with the feature gradually rolling out in Chrome 148.

    • Chrome 147 on Linux, macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester.
    • Chrome 148 on Linux, macOS, Windows - Feature rolls out gradually.

   

  • New organization publishing option in the Chrome Web Store back to top

    Chrome 147 introduces a new B2B domain publishing capability within the Chrome Web Store that enables developers to directly distribute extensions to specific enterprise domains. This unlocks secure, scalable deployment for custom-built enterprise solutions and improves the admin experience managing these deployments.

    Previously, enterprise developers could only publish extensions privately to their own enterprise. With the new option, developers will be able to deploy their extensions privately to external organizations that approve them, all from within the store.
    For more information on how to get started, visit the Chrome for Developer Blog: New enterprise publishing option in the Chrome Web Store: Publish to external organizations.

    • Chrome 147 on ChromeOS, Linux, macOS, Windows.

   

  • Gen AI and SaaS app usage reporting back to top

    As early as Chrome 147, admins will have access to a new Gen AI and SaaS app usage reporting feature in the Google Admin console. This report brings visibility into their organization's use of generative AI tools and SaaS sites, allowing admins to monitor usage of their enterprise IT resources.

    This report is available for Chrome Enterprise Core (CEC) and Chrome Enterprise Premium (CEP) customers only.

    This new report tracks usage for 60 predefined sites (including X Gen AI sites), providing metrics on visits, unique managed profiles, unique managed browsers, and access to sensitive content transfer events. With these insights, admins can assess risk and restrict usage by making informed licensing decisions or creating usage restrictions, such as Data Loss Prevention (DLP) rules.
    Chrome 147 allows a Trusted Tester preview, with the feature gradually rolling out in Chrome 149.

    • Chrome 147 on Linux, macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester.
    • Chrome 149 on Linux, macOS, Windows - Feature rolls out gradually.

Chrome Enterprise Premium changes

Read more about the differences between Chrome Enterprise Core and Chrome Enterprise Premium.

   

  • Increased file size support for DLP scans back to top  

    Chrome Enterprise Premium will extend its Data Loss Prevention (DLP) and malware scanning capabilities to include large and encrypted files.

    Previously, files larger than 50 MB and all encrypted files were skipped during content scanning. This update closes that critical security gap.

    In Chrome 147, for policies configured to save evidence, files up to 2GB can now be sent to the Evidence Locker. This provides administrators with greater visibility and control, significantly reducing the risk of data exfiltration through large file transfers.

    Note: Because larger files are now being stored, customers may see an increase in Google Cloud Storage charges associated with their Evidence Locker bucket.

    No new policy is required to enable this feature. It is automatically controlled by your existing DLP rule configurations in the Google Admin console. If admins have rules that apply to file uploads, downloads, or printing, they will now also apply to large and encrypted files. For more information, see What are ChromeOS data controls?.

    • Chrome 147 on Linux, macOS, Windows: This stage enables the collection of large (>50 MB) and encrypted files for the Evidence Locker, closing a key Data Loss Prevention security gap.

   

  • New templates for Data Loss Prevention rules back to top  

    Deploying industry-leading data protection in Chrome is now faster and more intuitive. Chrome Enterprise Premium (CEP) introduces ready-to-use Data Loss Prevention (DLP) rule templates to help customers implement robust data protection policies and realize the value of CEP’s security suite with minimal setup.

    With these templates, customers can quickly and easily implement essential DLP controls without starting from scratch. These templates provide a basis for common DLP use cases, such as:

    • Protecting sensitive data like credit card numbers and social security numbers from being leaked accidentally or maliciously.
    • Audit, block pasting or fully block categories of sites, such as Generative AI sites.
    • Disable screen capture or watermark sites with sensitive information.

    The new data protection templates can be found in the Google Admin console using the Rules > Templates option from the left navigation menu.

    Chrome 147 allows a Trusted Tester preview, with the feature gradually rolling out in Chrome 148.

    • Chrome 147 on Android, iOS, ChromeOS, Linux, macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester: Trusted tester access will begin as early as April 2026.
    • Chrome 148 on ChromeOS, Linux, macOS, Windows - Feature rolls out gradually.

   

  • Streamlined Chrome Enterprise to Google SecOps integration back to top  

    The new Chrome Enterprise Connector for Google Security Operations (Google SecOps) is now generally available.

    The connector provides a new integration experience that can optionally configure recommended Chrome Enterprise settings to forward Chrome data to Google SecOps. The connector now allows administrators to keep previously configured settings. Data from Chrome Enterprise Premium includes additional security context from Safe Browsing. Admins can choose to select an instance connected to their organization or use a one-time token (keyless) to send data to an external instance. This connector routes Chrome data to Google SecOps through Google Cloud.

    For additional details, see Configure Chrome Enterprise Connectors for Google Security Operations.

    • Chrome 142 on iOS, ChromeOS, Linux, macOS, Windows.
    • Chrome 147 on ChromeOS, Linux, macOS, Windows - Feature rolls out gradually: Chrome Enterprise Connector for Google Security Operations becomes generally available.

   

  • Support for allowlist and blocklist for Developer Tools back to top  

    Chrome will introduce two new policies, DeveloperToolsAvailabilityAllowlist and DeveloperToolsAvailabilityBlocklist, which provide granular control over the availability of Developer Tools based on URL patterns.

    Previously, administrators could only allow or disallow Developer Tools globally. With these new policies, admins can now enforce a general block on Developer Tools to secure sensitive corporate data, while explicitly permitting access on specific internal URLs for development or troubleshooting purposes.

    These controls are available on Windows, Mac, Linux, and ChromeOS. If these new policies are not configured, the behavior of the existing DeveloperToolsAvailability policy remains unchanged.

    • Chrome 147 on ChromeOS, Linux, macOS, Windows - Feature rolls out gradually: Introduces the DeveloperToolsAvailabilityAllowlist and DeveloperToolsAvailabilityBlocklist policies on Desktop platforms.

   

  • Support for allowlist and blocklist for Incognito mode back to top  

    Chrome will introduce two new policies, IncognitoModeUrlBlocklist and IncognitoModeUrlAllowlist, to provide administrators with more precise control over Incognito mode usage.

    As part of this change, Chrome is also updating the default behavior of wildcard patterns in the existing URLBlocklist policy and in the new IncognitoModeUrlAllowlist to permit navigation to internal chrome:// pages. If an administrator wants to block internal chrome:// pages, they must explicitly block those and cannot depend on the wildcard. Note that access to internal chrome:// pages is necessary for the proper functioning of several Chrome features, like search, the new tab page and printing.

    These new policies function similarly to the existing URLBlocklist and URLAllowlist policies but are specifically designated for Incognito sessions. This allows organizations to restrict access to specific URLs in Incognito mode to protect sensitive information while permitting legitimate usage on other sites. Previously, administrators could only completely enable or disable Incognito mode via the IncognitoModeAvailability policy.

    • Chrome 147 on Android, iOS, ChromeOS, Linux, macOS, Windows - Feature rolls out gradually: Introduces the IncognitoModeUrlBlocklist and IncognitoModeUrlAllowlist policies.

↑ back to top  

Coming soon

Note: The items listed below are experimental or planned updates. They might change, be delayed, or canceled before launching to the Stable channel.

 

Upcoming Chrome browser changes

   

  • Chrome Profile Bootstrapping via Custom URI back to top

    This feature introduces a new custom URI scheme (google-chrome://) that allows external applications and web portals to launch Chrome directly into a specific managed profile. If the specified profile does not exist, the user will be guided through a streamlined profile creation flow pre-populated with their work email. This enables a seamless transition for users jumping from arbitrary browsers or built-in app catalogs into a secure, managed Chrome environment. Admins can control this behavior using the ChromeURILaunchEnabled policy.

    • Chrome 148 on macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester.  

   

  • Enhanced autofill back to top

    From Chrome 137 onwards, some users can turn on Enhanced autofill, a feature that helps users fill out online forms more easily. On relevant forms, Chrome can use AI to better understand the form and offer users to automatically fill in previously saved info. Admins can control the feature using the existing GenAiDefaultSettings policy and a new AutofillPredictionSettings policy.

    • Chrome 137 on ChromeOS, Linux, macOS, Windows - Feature rolls out gradually.
    • Chrome 140 on ChromeOS, Linux, macOS, Windows: The existing "Autofill with AI" feature will be renamed to "Enhanced autofill", allow users to save and fill additional types of info, and become available in more countries and languages.
    • Chrome 148 on Android, iOS: Enhanced autofill will be made available to users of Chrome on Android and Chrome on iOS.

   

  • Extended lifetime shared workers back to top

    This update adds a new option, extendedLifetime: true, to the SharedWorker constructor. This requests that the shared worker be kept alive even after all current clients have unloaded. The primary use case is to allow pages to perform asynchronous work that requires JavaScript after a page unloads, without needing to rely on a service worker.

    • Chrome 148 on Windows, macOS, Linux, Android: No rollout step.

   

  • PWA origin migration back to top

    When a user installs a Progressive Web App (PWA), its identity and security context are tightly bound to its web origin, for example, app.example.com. This presents a significant challenge for developers who need to change their PWA's origin due to rebranding, domain restructuring, or technical re-architecture. Currently, such a change forces users to manually uninstall the old app and reinstall the new one, leading to a disruptive experience and potential user loss. Chrome 148 introduces a mechanism for developers to seamlessly migrate an installed PWA to a new, same-site origin, preserving user trust and permissions.

    The WebAppInstallForceList policy will block migration. Since enterprise policies around web applications are primarily based on URLs and origins, there is a risk that a migration would bypass certain policies an admin might have configured. No migration will be offered to the user when an app is force-installed by their enterprise administrator, and instead a banner will be shown explaining this to the user.

    • Chrome 148 on Windows, macOS, Linux: No rollout step.

   

  • Prompt API back to top

    The Prompt API is designed for interacting with an AI language model using text, image, and audio inputs. It supports various use cases, from generating image captions and performing visual searches to transcribing audio, classifying sound events, generating text following specific instructions, and extracting information or insights from text. It supports structured outputs which ensure that responses adhere to a predefined format, typically expressed as a JSON schema, to enhance response conformance and facilitate seamless integration with downstream applications that require standardized output formats.

    This API is also exposed in Chrome Extensions. This feature entry tracks the exposure on the web. An enterprise policy GenAILocalFoundationalModelSettings is available to disable the underlying model downloading, which would render this API unavailable.

    Language support log:

    • Chrome M139 and earlier only supported 'en'
    • Chrome M140 added support for 'es' and 'ja'
    • Chrome 148 on Windows, macOS, Linux - Feature rolls out gradually.

   

  • Chrome for ARM64 Linux devices back to top

    We’re excited to announce that Google will launch Chrome for ARM64 Linux devices in Q2 2026, following the successful expansion of Chrome to Arm-powered macOS devices in 2020 and Arm-powered Windows devices in 2024.

    Launching Chrome for ARM64 Linux devices allows more users to enjoy the seamless integration of Google’s most helpful services into their browser. This move addresses the growing demand for a browsing experience that combines the benefits of the open-source Chromium project with the Google ecosystem of apps and features.

    To read more, see this Chromium blog post.

    • Chrome 149 on Linux - Feature rolls out gradually. 

   

  • Update to No HTTPS warning back to top

    The warning displayed when a user opts-in to the Always Use Secure Connections on chrome://settings/security is changing from an interstitial to a dialog. Full page load remains blocked, and the functionality remains the same. The URL content security indicator on the warning is changing from the indicator to the broken lock. Some users may see this warning automatically when visiting HTTP sites. Users can opt in to the warning on chrome://settings/security.


    • Chrome 141 on ChromeOS, Linux, macOS, Windows: New warning design on desktop platforms.
    • Chrome 149 on Android: Similar updated warning design on Android, using a warning bubble instead of a full interstitial.

   

  • Always Use Secure Connections by default back to top

    Chrome 150 will enable the Always Use Secure Connections setting in the "public sites only" mode by default. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS. Public sites are defined as sites that have a globally unique name, and excludes direct navigation to RFC 1918 addresses (192.168.0.1, 10.0.0.0/8, etc), as well as shortnames such as go/.

    Prior to enabling it by default for all users, Chrome will enable Always Use Secure Connections for the users who have opted in to Enhanced Safe Browsing protections in Chrome.

    If you are a website developer or IT professional, and you have users who may be impacted by this feature, we very strongly recommend enabling the "Always Use Secure Connections" setting today to help identify sites that you may need to work to migrate. Admins can use the HttpAllowlist and HttpsOnlyMode policies to override this behavior.

    For more information, see our adoption guide and announcement blog post.

    • Chrome 150 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Enable "Always Use Secure Connections" for users who have opted in to Enhanced Safe Browsing.
    • Chrome 154 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Enable "Always Use Secure Connections" by default for all users.

   

  • Deprecation and removal of Privacy Sandbox APIs  back to top

    Chrome has recently announced that the current approach to third-party cookies is to be maintained, following which, we plan to deprecate and remove the following APIs.

    • Topics
    • Protected Audience
    • Shared Storage
    • Attribution Reporting
    • Private Aggregation
    • Related Web Sites
    • requestStorageAccessFor

    The following are the enterprise policies associated with the above APIs.

    Deprecation began with Chrome 144, and removal is planned for Chrome 150. After deprecation, the APIs will continue to exist, and most users will see no disruptions. However, some users who rely on server-side integrations (such as k-anonymity server, or coordinators) will see a break in the services. We have proactively reached out to users of the APIs with our deprecation plans. At the time of removal, Chrome 150, all the policies associated with these APIs will also be removed.

    None of the APIs are enabled by default to enterprise users. Enterprise teams may want to review the status for any managed profile in their Admin console.

    • Chrome 144 on Android, ChromeOS, Linux, macOS, Windows: Deprecation launch.
    • Chrome 150 on Android, ChromeOS, Linux, macOS, Windows: APIs and the associated Policies removal.

   

  • Isolated Web Apps back to top

    Isolated Web Apps (IWAs) are an extension of existing work on PWA installation and Web Packaging that provide stronger protections against server compromise and other tampering that is necessary for developers of security-sensitive applications. Rather than being hosted on live web servers and fetched over HTTPS, these applications are packaged into Web Bundles, signed by their developer, and distributed to end-users through one or more of the potential methods described in the explainer. 

    As early as Chrome 150, IWAs will only be installable through an admin policy on enterprise-managed ChromeOS devices.

    • Chrome 150 on Windows This rollout adds support for Isolated Web Apps in enterprise-managed browser configurations on Windows.

   

  • SafeBrowsing API v4 to v5 migration back to top

    Chrome calls into the SafeBrowsing v4 API will be migrated to call into the v5 API instead. The method names are also different between v4 and v5. If admins have any v4-specific URL allowlisting to allow network requests to https://safebrowsing.googleapis.com/v4*, these should be modified to allow network requests to the whole domain instead: safebrowsing.googleapis.com. Otherwise, rejected network requests to the v5 API will cause security regressions for users. For more details, see Migration From V4 - Safe Browsing. 

    • Chrome 150 on Android, iOS, ChromeOS, Linux, macOS, Windows: Feature would gradually roll out.

   

  • Chrome will remove support for macOS 12 back to top

    Chrome 150 will be the last release to support macOS 12; Chrome 151+ will no longer support macOS 12, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

    On Macs running macOS 12, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome updated, they need to update their computer to a support version of macOS. 

    For new installations of Chrome 151+, macOS 13+ will be required.

    • Chrome 151 on Windows, MacOS, Linux

   

  • Deprecate and remove XSLT back to top

    XSLT v1.0, 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+React.

    Chromium uses the libxslt library to process these transformations, and libxslt was unmaintained 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 article on Chrome for Developers.

    • Chrome 143 on Android, ChromeOS, Linux, MacOS, Windows: Deprecation (but not removal) of the APIs.
    • Chrome 152 on Android, ChromeOS, Linux, MacOS, Windows: Origin Trial (OT) and Enterprise Policy go live for testing. These allow sites and enterprises to continue using features past the removal date.
    • Chrome 160 on Android, ChromeOS, Linux, MacOS, Windows: XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.
    • Chrome 176 on Android, ChromeOS, Linux, MacOS, Windows: Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.

   

  • PostQuantum cryptography for DTLS in WebRTC back to top

    This feature will enable the use of PostQuantum Cryptography (PQC) with WebRTC connections. The motivation for PQC is to get WebRTC media traffic up to date with the latest cryptography protocols and prevent Harvest Now to Crack Later scenarios. 

    Admins will be able to control this feature using an enterprise policy WebRtcPostQuantumKeyAgreement, to allow enterprise users to opt out of PQC. The policy is temporary and is planned to be removed by Chrome 152.

    • Chrome 142 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Feature rolls out
    • Chrome 152 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Remove enterprise policy

   

  • Moving to a 2-week release cycle back to top

    From September 2026 (Chrome 153) Chrome will move to a 2-week release cycle, from the current four-week cycle. The web platform is constantly advancing, and our goal at Chrome is to ensure developers and users have immediate access to the latest capabilities, fixes, and performance improvements. Building on our history of adapting our release process to match the demands of a modern web, we are announcing this significant step to further increase our development velocity and Chrome Stable is moving to a 2-week release cycle. You can find more details in the Chrome for Developers blog post.

    Extended Stable is available for customers who might have concerns about the maintenance costs. For more information about Extended Stable, see this Help Center article. The 2-week Stable option remains the most secure choice and should be used if security is a larger concern than maintenance costs.

    • Chrome 153 on Android, iOS, Linux, macOS, Windows: Moving 2-week release cycle

   

  • Disallow spaces in non-file:// URL hosts back to top

    According to the URL Standard specification URL hosts cannot contain the space character, but currently URL parsing in Chromium allows spaces in the host. This causes Chromium to fail several tests included in the Interop2024 HTTPS URLs for WebSocket and URL focus areas. To bring Chromium into spec compliance, we would like to remove spaces from URL hosts altogether, but a difficulty with this is that they are used in the host part in Windows file:// URLs. For more details, see this Github discussion.

    • Chrome 157 on Android, ChromeOS, LaCrOS, Linux, MacOS, Windows, Fuchsia

 

Upcoming Chrome Enterprise Core updates

   

  • Chrome client certificate support on iOS back to top

    Built-in client certificate support in Chrome for iOS enables managed users to securely authenticate to corporate resources using mutual TLS (mTLS). Historically, iOS isolated certificates within the system store accessible only to built-in Apple apps, but this launch allows Chrome to provision and manage its own hardware-backed certificates independently. By integrating with the iOS Secure Enclave for non-exportable private key storage, Chrome provides a high-assurance identity signal specifically for Zero Trust environments using Microsoft Entra ID and Conditional Access. These credentials are provisioned within the work-managed Chrome profile and are inaccessible to other applications or personal profiles on the device.

    To implement this feature, admins must enable the Apply supported user settings to Chrome on iOS toggle in the Google Admin console and configure the ProvisionManagedClientCertificateForBrowser and ProvisionManagedClientCertificateForUser policies to initiate issuance and rotation. Finally, the AutoSelectCertificateForUrls policy should be used to automate certificate selection for designated corporate domains to ensure a seamless authentication flow.

    • Chrome 148 on iOS - Feature rolls out gradually.

   

  • Managed profile reporting support back to top

    Chrome Enterprise Core is launching cloud profile reporting support for the Apps & extension usage report and the Versions report in the Google Admin console.

    On the Apps & extension usage report, admins will be able to see a new total install count for managed profiles (work profiles). They will be able to see which extensions have the most installs across all managed profiles.

    On the Versions report, admins will be able to see the total number of managed profiles running each version of Chrome. For example, they will be able to see if managed profiles are using older versions of Chrome.

    To enable cloud profile reporting for both of these reports, admins have to enable the existing CloudProfileReportingEnabled policy. If you have already turned on Managed profile reporting, the reports will automatically start reporting the data.

    How to find these reports? In the Admin console, navigate to Chrome browser > Reports > Apps & extensions usage or Chrome browser > Reports > Versions.

    • Chrome 148 on Android, iOS, ChromeOS, Linux, macOS, Windows: The profile reporting on the Versions report will be available to Chrome Enterprise Trusted Testers.

 

Upcoming Chrome Enterprise Premium updates

    

  • Chrome Enterprise Connectors API back to top

    Chrome Enterprise will soon expand programmatic management for Chrome Enterprise Connectors. This update will introduce resources to define and assign connector configurations, complementing the existing connector policies to allow administrators to manage the full life-cycle of these integrations at scale.

    Previously, configuring Service Providers was a manual process in the Google Admin console. This update enables automation, which helps reduce manual errors and improve the efficiency of managing integrations with third-party security solutions.

    Administrators can now use the Chrome Management API to manage ConnectorConfiguration resources (defining the provider). Connector Selection is managed via the Chrome Policy API, enabling the assignment of these configurations to Organizational Units or Groups. This works in tandem with existing Policy API settings for event reporting and content analysis, including policies such as OnSecurityEventEnterpriseConnector, OnFileAttachedEnterpriseConnector, OnFileDownloadedEnterpriseConnector, OnBulkDataEntryEnterpriseConnector, OnPrintEnterpriseConnector, and EnterpriseRealTimeUrlCheckMode. For technical details, developers should refer to the Chrome Management API and Chrome Policy API documentation.

    • Chrome 143 on Android, iOS, Linux, macOS, Windows: This rollout adds support for programmatic management of Chrome Enterprise Connectors via a new API
    • Chrome 148 on Android, iOS, Linux, macOS, Windows: This rollout introduces the ConnectorConfiguration and ConnectorSelection resources, enabling the creation of service provider instances and their assignment to organizational units.

    

  • Drag support for data controls back to top

    Chrome will enhance the Data Controls framework by extending security enforcement to drag-and-drop operations across Windows, Mac, Linux, ChromeOS, and Android to ensure consistency with existing clipboard policies. Admins will be able to manage this behavior through the DataControlsRules policy, though any WARN verdict will automatically escalate to a BLOCK to prevent a warning dialog from interrupting the interactive drag loop.

    When an action is restricted, users will see the new ClipboardDragBlock dialog or an Android blocking modal stating that dragging content is not allowed on the site. This update will close a critical data exfiltration gap using local evaluation to maintain performance and privacy. Organizations should test these rules using the DataControlsDragEnforcement feature flag and the chrome://policy/test page.

    • Chrome 148 on Android, ChromeOS, Linux, macOS, Windows - Feature rolls out gradually

    

  • Enterprise extension DOM activity telemetry back to top

    This enterprise-only feature provides security auditing for Chrome Extensions by creating a high-fidelity pipeline that monitors risky behavior. It specifically focuses on identifying Code Injection (execution risks) and Data Access (theft risks) occurring between web pages and extensions. Verified signals are filtered to ensure browser performance is not impacted, and they are ultimately transmitted using the Chrome real-time reporting pipeline for Security Information and Event Management (SIEM) system analysis.

    • Chrome 148 on ChromeOS, Linux, macOS, Windows - Early preview available to Chrome Enterprise Trusted Tester.

    

  • New policy setting for DataControlRules back to top

    Chrome is enhancing the existing DataControlsRules policy by introducing a new setting labeled Pasting restrictions across management boundaries. This update provides admins with a context-based mechanism to block against sensitive web content being pasted into or from managed Chrome profiles without requiring specific source or destination URLs.

    As of Chrome 148, admins could use a simple checkboxes in the Google Admin Console to establish data boundaries for Incognito mode, other Chrome profiles, and applications other than Chrome. This enhancement is designed to strengthen data loss prevention for Chrome Enterprise Premium customers by preventing corporate data exfiltration into unmanaged environments. Users will receive immediate on-browser notifications if a paste action is restricted, ensuring real-time awareness of organizational security policies.

    • Chrome 148 on Android, iOS, ChromeOS, macOS, Windows - Feature rolls out gradually.

    

  • Hardening against local policy tampering back to top

    Local settings on bring-your-own-device (BYOD) devices can sometimes conflict with corporate policy settings. To address this potential security gap, policy conflict signals in Chrome now detect and report whenever corporate policies are being overridden by local policy. Chrome 145 integrates these new policy conflict signals from the managed Chrome profile into existing security reports, controlled by the UserSecuritySignalsReporting policy.

    For more information on device reporting, see View ChromeOS device list and details - Chrome Enterprise and Education Help.

    • Chrome 144 on Linux, macOS, Windows: Detection and reporting of policy conflict metadata begins.
    • Chrome 145 on Linux, macOS, Windows: Visibility into Chrome policy hardening signals via the Devices API becomes available.
    • Chrome 150 on Linux, macOS, Windows: Admin console UI is updated to display conflict signals and policy values begin reporting.

↑ back to top  

 Sign up for emails about future releases

Previous release notes 

Chrome version & targeted Stable channel release date
Chrome 146: February 25, 2026
Chrome 145: January 28, 2026
Chrome 144: January 7, 2026
Chrome 143: December 10, 2025
Previous release notes  →

Additional resources

Still need help?

Google and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.

Was this helpful?

How can we improve it?

Need more help?

Try these next steps:

Post to the help community Get answers from community members
true
Search
Clear search
Close search
Main menu
16481180028022223657
true
Search Help Center
false
true
true
true
true
true
410864
false
false
false
false