Chrome has an internal configuration page, accessible via the address bar, that brings together experimental features called flags. These settings, developed by Google’s teams, allow users to test browser behaviors before their potential public deployment. They can be activated from chrome://flags, an interface that lists several hundred options categorized, each accompanied by a description in English and a dropdown menu (Default, Enabled, Disabled).
Embedded AI model in Chrome: a flag that impacts storage
Articles discussing Chrome flags focus on visual comfort or speed settings. A recent flag deserves special attention for a different reason: its direct impact on disk space.
Chrome downloads a local artificial intelligence model intended to power certain suggestions and predictive features of the browser. This model weighs about 4 GB, a size that poses a concrete problem on machines equipped with low-capacity SSDs, particularly Chromebooks.
The relevant flag is called optimization-guide-on-device-model. By setting it to Disabled, the browser stops downloading this model. To reclaim the space already occupied, the associated folder must be manually deleted from the Chrome data directory. To understand in detail the hidden options of chrome flags, the operation of this flag illustrates the general logic well: each experimental parameter controls a specific component of the browser, with measurable consequences.
This manipulation is particularly useful for users who do not utilize Chrome’s AI functions and prefer to free up space for their files or applications.
Flags and Manifest V2 extensions: a window that is closing
Flags are not only used to activate new features. Some have until now allowed the maintenance of functionalities that Google is gradually removing. The most significant case concerns the transition to Manifest V3 for Chrome extensions.
Manifest V2 is the historical format on which popular extensions like the classic version of uBlock Origin rely. Google has been enforcing the transition to Manifest V3 for several months, a new standard that fundamentally changes how extensions interact with the browser, particularly by limiting certain network filtering capabilities.
Internal flags allowed bypassing this transition and continuing to use MV2 extensions. This possibility is gradually disappearing:
- Starting with Chromium 150, the flag kExtensionManifestV2Disabled is removed, blocking the installation of MV2 extensions from the Chrome Web Store.
- Chromium 151 removes other internal options related to MV2 support, including those used in developer mode to manually load these extensions.
- Tutorials that still recommend activating a flag to keep the classic uBlock Origin are becoming obsolete with each browser update.
This withdrawal illustrates a point often overlooked: flags are temporary by nature. An active flag today may disappear in the next update without warning or alternative.
Network flags and the QUIC protocol: what the change implies
Among the oldest and most stable flags, those related to the QUIC network protocol deserve a technical detour. QUIC is a transport protocol developed by Google, designed to reduce the latency of web connections compared to traditional TCP.
The flag enable-quic (Experimental QUIC protocol) forces the use of QUIC on compatible sites. In practice, enabling this flag can reduce page load times on high-latency connections (mobile network, public Wi-Fi). The gain is noticeable on sites that support HTTP/3, as QUIC serves as its transport layer.
Two technical clarifications are useful here. QUIC operates over UDP and not TCP, which means that some corporate firewalls or network filters may block QUIC traffic without the user realizing it. The browser then silently switches to TCP, negating any benefits of the flag. Checking the actual behavior requires opening the developer tools (F12), going to the Network tab, and checking the Protocol column for each request.
Testing without risk: the separate data directory
Rather than modifying flags on the main Chrome profile, a more cautious approach is to launch Chrome with a separate user data directory. On Windows, this involves creating a shortcut with the command line option dedicated to the data directory. Chrome then starts with a blank profile, on which flags can be activated and tested without affecting the usual configuration.
This method avoids a common problem: the simultaneous activation of multiple flags whose effects conflict. Google explicitly warns of this risk in its developer documentation. Two flags that modify the graphical rendering behavior, for example, can cause visual artifacts or tab crashes when activated together.
Lifecycle of a Chrome flag: from experimentation to removal
A flag follows a three-step process. It first appears in the Canary or Dev versions of Chrome to gather feedback from testers. If it works correctly, the feature it controls is integrated into the standard browser settings, and the flag is removed. If the results are insufficient, the flag and the feature disappear together.
This cycle has a direct practical consequence: noting the activated flags on your browser allows you to check after each update if any of them have been removed. Chrome displays a warning banner upon restart when an active flag no longer exists, but this message is easy to overlook.
The page chrome://flags itself categorizes flags by state (Default, Enabled, Disabled) and allows everything to be reset with a click via the “Reset all” button. This reset function remains the most reliable safety net when a flag causes unexpected browser behavior.
Chrome flags are not standard customization settings. They are technical levers whose lifespan depends on the decisions of the Chromium team. Using them methodically, on a separate profile and keeping track of changes, remains the only approach that avoids unpleasant surprises after an update.