Chrome 154 Is Here With 108 Security Fixes and New Web APIs

Chrome 154 reached the stable channel on September 22, 2026, bringing 108 security fixes alongside changes that matter directly to software developers. The release adds new WebSocket and Web Crypto capabilities, tightens Background Fetch security, and makes HTTPS-only browsing the default, giving developers several changes to test rather than treating the update as just another browser patch.

Chrome 154 changes both browser security and web development

Google is rolling Chrome 154 to Windows, macOS, and Linux as version 154.0.8037.57/.58, while Android is receiving version 154.0.8037.57. Google says the desktop release contains 108 security fixes, including several critical memory-safety issues involving components such as ANGLE, the graphics translation layer used by Chromium. Android receives the corresponding desktop security fixes unless otherwise specified, so developers testing mobile web applications should not treat the Android release as a separate security track.

The release is also significant because Chrome is now shipping stable versions every two weeks instead of every four weeks. Chrome 153 began that schedule on September 8, making Chrome 154 the second stable release under the faster cadence. For developers, the shorter cycle means smaller batches of changes but also less time between stable releases, so testing against Chrome Beta becomes more useful when a site depends on browser-specific behavior.

HTTPS becomes the default expectation for public websites

One of the biggest behavioral changes in Chrome 154 is the default use of Always use secure connections. When Chrome encounters a public website without HTTPS, it can ask for permission before making the connection rather than silently proceeding with an unencrypted HTTP request. HTTPS encrypts the connection between the browser and website, protecting data from being read or modified while it travels across the network.

This matters most for developers maintaining older websites, internal tools, documentation systems, test environments, or links that still begin with HTTP. Chrome's policy applies to public sites and does not treat private network addresses such as common local-network ranges in the same way. Enterprise administrators can also control the behavior through Chrome policies, so managed environments may behave differently from consumer installations.

For a developer, the useful response is not simply to wait for users to report warnings. Check redirects, embedded resources, API endpoints, authentication pages, and third-party integrations for HTTP dependencies. A page that loads over HTTPS but still relies on an HTTP service can have a very different failure mode from a completely HTTP site, so testing the complete application matters more than checking the homepage alone.

WebSocket gets a cleaner way to pass connection options

Chrome 154 adds an options object to the WebSocket constructor. WebSocket is the browser API used to maintain a two-way connection between a web page and a server, which makes it useful for chat applications, dashboards, multiplayer software, live notifications, and other applications that need data to move continuously.

Previously, developers could provide the WebSocket URL followed by a protocol value. Chrome 154 allows an options dictionary to be supplied as the second argument instead, with protocols initially supported as the option. The change is small in everyday code, but the object-based design also provides a place for additional connection options to be introduced later without repeatedly changing the constructor's argument structure.

That means existing WebSocket applications do not need to be rewritten simply because Chrome 154 is installed. The new form is an additional capability rather than a replacement that invalidates the older syntax. Developers building new abstractions around WebSocket may find the options-based form easier to extend as the specification develops.

Web Crypto gains post-quantum algorithms

Chrome 154 also expands the Web Cryptography API with post-quantum cryptographic algorithms and a symmetric authenticated-encryption algorithm. Web Crypto is the browser's built-in interface for cryptographic operations such as generating keys, creating signatures, encrypting data, and verifying authentication.

Post-quantum cryptography refers to algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. The practical value of exposing these algorithms through Web Crypto is that web applications can experiment with standardized browser-provided implementations rather than having to bundle their own cryptographic code. That does not mean ordinary websites suddenly need to replace every existing encryption mechanism, but it gives developers a standards-based path for testing future-resistant cryptographic designs.

The important limitation is that browser support alone does not make an application post-quantum secure. The server, protocol, key-management system, libraries, and data formats all need to understand the cryptographic scheme being used. Developers should therefore treat the new Web Crypto capabilities as building blocks rather than as a one-line security upgrade.

Background Fetch now faces stricter cross-origin checks

Chrome 154 changes how the Background Fetch API handles cross-origin requests. Background Fetch lets a website continue requesting larger resources through a service worker even when the page is no longer actively being viewed, which can be useful for downloads and other long-running transfers.

The new release applies Cross-Origin Resource Sharing, or CORS, rules to Background Fetch. CORS is the browser's mechanism for controlling whether a web page is allowed to request resources from another origin, where an origin is defined by the combination of scheme, host, and port. Chrome is also applying Local Network Access requirements when Background Fetch attempts to contact local or loopback servers.

The change closes a route through which a site could potentially use Background Fetch to avoid security checks that would apply to an ordinary Fetch request. Developers using Background Fetch should therefore test cross-origin downloads and local-development workflows after upgrading. A request that previously appeared to work because the browser did not enforce the same checks may now fail until the server and application permissions are configured correctly.

Developers get more precise performance controls in DevTools

The Chrome 154 generation also brings several useful changes to Chrome DevTools, Google's browser development and debugging environment. The Performance panel now supports end-to-end analysis of soft navigations, which are page transitions that change the visible application without performing a traditional full document navigation. This is particularly useful for single-page applications where URL changes and screen transitions can happen without reloading the page.

DevTools can also override CPU performance tiers through the Chrome DevTools Protocol. That allows developers to reproduce performance tests against calibrated hardware levels rather than relying only on the physical computer sitting on their desk. A developer testing a web application can therefore compare behavior under different simulated CPU conditions and investigate whether a slow interaction is caused by application work that becomes expensive on weaker hardware.

The update also improves memory investigation. Heap snapshots can be filtered and sorted by retained size, and developers can query objects directly by properties or memory thresholds. A heap snapshot records objects held by the browser's JavaScript engine, so these additions make it easier to find objects that remain in memory longer than expected when investigating a memory leak.

Chrome 154 also tightens tools used by coding agents

The DevTools changes extend beyond traditional browser debugging. Chrome's DevTools tooling for coding agents now includes controls for JavaScript execution, source-map loading, filesystem paths, heap snapshots, and Progressive Web App automation. Coding agents can use browser tools to inspect and interact with web applications, so controlling what those tools are allowed to execute or access becomes part of the development workflow.

One example is the ability to disable JavaScript evaluation while inspecting a page. That gives an agent a way to examine page structure without automatically executing scripts during the inspection process. Chrome DevTools also adds configurable filesystem roots and path permissions, which matters when an automated development tool is allowed to work with local project files.

These additions are not a reason to hand unrestricted browser access to an automated coding system. They are better understood as controls for making browser automation more observable and bounded. Teams using agents to test applications should pay attention to which filesystem paths, scripts, network requests, and debugging operations the agent can actually access.

The release is small for users but significant for developers

Most people will experience Chrome 154 as an ordinary browser update, but developers have several concrete reasons to test their applications against it. HTTPS-only behavior can expose insecure links, Background Fetch changes can break assumptions about cross-origin requests, and new Web Crypto capabilities introduce another option for future cryptographic work. At the same time, DevTools becomes more useful for diagnosing performance, memory, and automated-browser workflows.

The timing makes this more important than it might have been under Chrome's old release schedule. With stable releases now arriving every two weeks, developers have less time to absorb a large collection of changes after each milestone. The practical approach is to test Chrome Beta continuously, pay particular attention to security-policy changes such as HTTPS and CORS, and verify that automated development tools still operate within the permissions your projects actually require.