How to Disable Chrome Developer Tools (2026)

Last updated: April 17, 2026

Disabling Chrome Developer Tools through Group Policy is a common requirement for enterprise environments, educational institutions, and organizations that need to restrict access to browser debugging capabilities. Whether you’re managing a fleet of workstations or securing kiosk systems, controlling DevTools access provides an additional layer of policy enforcement.

This guide covers the methods available for disabling Chrome Developer Tools, from Group Policy configurations to registry-based approaches, with practical examples for various deployment scenarios.

Understanding Chrome Enterprise Policies

Chrome supports enterprise policy management through Windows Group Policy Objects (GPO) and the Windows Registry. The browser checks for policy settings in a specific order: machine-level registry, user-level registry, and finally policy files deployed via Group Policy.

For disabling Developer Tools, the relevant policy is called DeveloperToolsAvailability. This policy controls whether DevTools can be opened and what features remain accessible when restrictions are applied.

Chrome’s enterprise policy framework was designed for large-scale deployments. Google publishes an ADMX template set called the Chrome ADMX templates that expose hundreds of policy knobs through the standard Group Policy interface. Installing these templates is a prerequisite for managing Chrome through GPO. without them, the Chrome-specific policy nodes do not appear in the Group Policy Editor.

To obtain the ADMX templates, download the Chrome Enterprise Bundle from Google’s enterprise download page. The bundle includes chrome.admx, google.admx, and the corresponding .adml language files. Copy them to C:\Windows\PolicyDefinitions\ (and the .adml files to C:\Windows\PolicyDefinitions\en-US\) on your domain controller or the machine where you run the Group Policy Editor. The Chrome policy nodes appear immediately after copying. no restart required.

Policy Settings Explained

The DeveloperToolsAvailability policy accepts three values:

Value	Behavior
0	Developer Tools are enabled
1	Developer Tools are disabled, but debugging port remains accessible
2	Developer Tools are fully disabled

Value 2 provides the most restrictive configuration, preventing both the keyboard shortcut (F12, Ctrl+Shift+I) and the menu access to Developer Tools.

The distinction between value 1 and value 2 matters more than it appears. Value 1 disables the in-browser UI but leaves port 9222 open for remote debugging. Any tool that speaks the Chrome DevTools Protocol (CDP) can still attach, inspect network traffic, execute JavaScript in the page context, and read DOM state. If your goal is preventing data extraction or script injection, value 1 is insufficient. value 2 is the correct choice for security-motivated deployments.

Configuring via Group Policy

Step 1: Access Group Policy Editor

Open the Local Group Policy Editor on your Windows machine:

gpedit.msc

Navigate to: Computer Configuration → Administrative Templates → Google Chrome → Developer Tools

gpedit.msc is only available on Windows Pro, Enterprise, and Education editions. Windows Home does not include the Local Group Policy Editor. For Home edition machines, use the registry-based method described in the next section.

Step 2: Configure the Policy

Double-click “Allow Developer Tools”
Select Disabled
Click OK to apply

This configuration disables Developer Tools for all users on the machine. The policy takes effect after the browser restarts.

When you set this policy to Disabled, Chrome maps it internally to DeveloperToolsAvailability = 2. The “Allow Developer Tools” naming in the GPO UI is slightly confusing. “Disabled” means you are disabling DevTools access, not disabling the policy itself.

Step 3: Force Policy Update

To apply changes immediately without waiting for Group Policy refresh:

gpupdate /force

Restart Chrome if it’s currently running to ensure the new policy takes effect.

On domain-joined machines, you can also push the refresh remotely using Invoke-GPUpdate from a management workstation:

Force policy refresh on a remote machine
Invoke-GPUpdate -Computer "WORKSTATION01" -Force -RandomDelayInMinutes 0

For bulk refreshes across an OU, combine with Get-ADComputer:

Refresh Group Policy on all computers in a specific OU
$ou = "OU=Kiosks,DC=corp,DC=example,DC=com"
Get-ADComputer -Filter * -SearchBase $ou | ForEach-Object {
 Invoke-GPUpdate -Computer $_.Name -Force -RandomDelayInMinutes 0
}

Registry-Based Deployment

For environments without Active Directory or for script-based deployments, you can modify the Windows Registry directly. This method works for both machine-level and user-level configurations.

Machine-Level Configuration

Create a registry file or use PowerShell to deploy:

PowerShell command to disable Developer Tools
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "DeveloperToolsAvailability" -Value 2 -PropertyType DWord -Force

This creates the necessary registry key if it doesn’t exist and sets the value to 2 (fully disabled).

If the parent path HKLM:\SOFTWARE\Policies\Google\Chrome does not exist yet (common on machines that have never had Chrome policies applied), create it first:

Create the registry path if it doesn't exist, then set the value
$regPath = "HKLM:\SOFTWARE\Policies\Google\Chrome"
if (-not (Test-Path $regPath)) {
 New-Item -Path $regPath -Force | Out-Null
}
New-ItemProperty -Path $regPath -Name "DeveloperToolsAvailability" -Value 2 -PropertyType DWord -Force

To deploy this as a .reg file. useful for distribution via email or shared drive. create a file with the following contents:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"DeveloperToolsAvailability"=dword:00000002

Double-clicking the .reg file on target machines merges the key. You can also deploy it silently via regedit /s policy.reg in a logon script or software deployment tool.

User-Level Configuration

For per-user policies without administrator privileges:

New-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Google\Chrome" -Name "DeveloperToolsAvailability" -Value 2 -PropertyType DWord -Force

User-level policies take precedence over machine-level settings for non-admin users.

A subtle but important behavior: when both HKLM and HKCU keys exist, Chrome uses HKCU for that specific user while other users on the same machine may have different settings. For consistent enforcement across all users on a shared machine, HKLM is the correct location.

Deploying via Intune or MDM

For organizations using Microsoft Intune or another MDM platform, registry-based Chrome policy deployment works through the Windows Registry CSP. Create a configuration profile with OMA-URI settings:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/DeveloperToolsAvailability
Data type: String
Value: <enabled/><data id="DeveloperToolsAvailability" value="2"/>

Alternatively, use the Chrome ADMX ingestion feature in Intune to import the Chrome ADMX template directly, which exposes the policy in the Configuration Profiles UI without requiring manual OMA-URI entries.

Enterprise Deployment with Active Directory

In large organizations using Active Directory, deploy the policy through Group Policy Management:

Open Group Policy Management (gpmc.msc)
Create or edit an existing GPO
Navigate to Computer Configuration → Administrative Templates → Google Chrome → Developer Tools
Enable the “Allow Developer Tools” policy and set it to Disabled
Link the GPO to the appropriate Organizational Unit (OU)

The policy propagates during the next Group Policy refresh cycle, typically every 90 minutes by default.

For kiosk deployments where immediate enforcement is critical, you can set a shorter background refresh interval by configuring the “Set Group Policy refresh interval for computers” policy under Computer Configuration → Administrative Templates → System → Group Policy. Setting this to 15 or 30 minutes reduces the window between deployment and enforcement.

GPO Scope and Targeting

By default, a GPO linked to an OU applies to all computer objects in that OU. Use security filtering to narrow the scope if needed:

Remove Authenticated Users from the GPO’s security filtering
Add the specific computer security group (or individual computers) you want to target
This ensures the policy applies only to intended machines even if other machines exist in the same OU

For WMI filtering. applying the policy only to machines running a specific version of Windows or Chrome. you can attach a WMI filter to the GPO. However, WMI filters add evaluation overhead and complexity; use them only when security group targeting is insufficient.

Verification and Testing

After deploying the policy, verify it’s working correctly:

Check Applied Policies

Open Chrome and navigate to chrome://policy. Look for the DeveloperToolsAvailability entry in the list of active policies.

The chrome://policy page shows every active Chrome policy, its source (whether it came from machine registry, user registry, or a cloud policy), and its current value. If DeveloperToolsAvailability does not appear, the registry key is either in the wrong location, the Chrome ADMX templates are not installed, or the policy has not yet replicated to the machine.

The page also shows a “Show unset policies” toggle that reveals all available policy names even if they are not currently configured. useful for confirming that a policy name is recognized by the installed version of Chrome.

Test Accessibility

Attempt to open Developer Tools using:

F12 keyboard shortcut
Ctrl+Shift+I keyboard shortcut
Right-click and select Inspect
Menu: ⋮ → More tools → Developer tools

All these methods should be blocked when the policy is correctly applied.

When DevTools is correctly disabled, Chrome typically shows a notification in the DevTools panel area indicating the feature is blocked by policy, or simply does not respond to the keyboard shortcuts. The exact behavior can vary slightly between Chrome versions.

Check Registry Directly

Verify the registry key exists
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "DeveloperToolsAvailability"

A successful configuration returns the value you set (0, 1, or 2).

To check both machine-level and user-level settings in one pass:

Check both HKLM and HKCU for the Chrome DevTools policy
$paths = @(
 "HKLM:\SOFTWARE\Policies\Google\Chrome",
 "HKCU:\SOFTWARE\Policies\Google\Chrome"
)
foreach ($path in $paths) {
 if (Test-Path $path) {
 $value = Get-ItemProperty -Path $path -Name "DeveloperToolsAvailability" -ErrorAction SilentlyContinue
 if ($value) {
 Write-Host "$path : DeveloperToolsAvailability = $($value.DeveloperToolsAvailability)"
 } else {
 Write-Host "$path : key exists but DeveloperToolsAvailability not set"
 }
 } else {
 Write-Host "$path : path does not exist"
 }
}

Limitations and Workarounds

Understanding the limitations helps set realistic expectations:

Not Foolproof

Tech-savvy users can still access debugging capabilities through:

Third-party browser extensions
External debugging tools connected via Chrome’s remote debugging port
Alternative browsers installed on the same system

Value 1 vs Value 2

Using value 1 instead of 2 leaves the debugging port (9222 by default) accessible. This allows external tools to connect:

// External connection example
const chrome = require('chrome-remote-interface');
chrome({ port: 9222 }, (client) => {
 const { Debugger } = client;
 Debugger.enable();
});

For maximum restriction, always use value 2.

Alternative Browser Access

The Group Policy approach applies only to Google Chrome. If users have Firefox, Edge, or another browser installed, they retain access to equivalent developer tools through those browsers. A comprehensive lockdown strategy must either remove alternative browsers or apply equivalent restrictions through those browsers’ own policy mechanisms.

For Edge (Chromium), the equivalent policy is also DeveloperToolsAvailability but under a different registry path:

Disable DevTools in Microsoft Edge via registry
$edgePath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
if (-not (Test-Path $edgePath)) {
 New-Item -Path $edgePath -Force | Out-Null
}
New-ItemProperty -Path $edgePath -Name "DeveloperToolsAvailability" -Value 2 -PropertyType DWord -Force

Firefox uses a different policy system (policies.json or Windows Group Policy via its own ADMX templates). If Firefox access is a concern, it requires separate policy configuration or removal from managed machines.

Extension-Based Workarounds

Browser extensions that inject scripts or provide alternative debugging UIs can partially circumvent DevTools restrictions. Pair the DevTools policy with extension management policies to close this gap:

Block all extension installation (use with care. breaks legitimate extensions too)
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome\ExtensionInstallBlocklist" -Name "1" -Value "*" -PropertyType String -Force
Allow specific extensions by ID while blocking others
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome\ExtensionInstallAllowlist" -Name "1" -Value "extension_id_here" -PropertyType String -Force

A more practical approach for most organizations is to allowlist a specific set of approved extensions rather than blocking everything, which tends to create support overhead.

Additional Security Considerations

Combine Developer Tools restrictions with other Chrome policies for defense in depth:

Disable JavaScript execution (extreme restriction)
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "JavaScriptDisabled" -Value 1 -PropertyType DWord -Force
Block extension installation
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "ExtensionInstallBlacklist" -Value @("*") -PropertyType MultiString -Force

These additional restrictions create a more locked-down browser environment suitable for kiosk displays or secure terminals.

For kiosk deployments, consider using Chrome’s built-in Kiosk Mode in addition to policy restrictions. Kiosk Mode (--kiosk flag) launches Chrome in a full-screen, single-site mode that eliminates the URL bar and standard menu entirely, reducing the attack surface beyond what policies alone provide.

A hardened kiosk configuration combining multiple policies:

$chromePath = "HKLM:\SOFTWARE\Policies\Google\Chrome"
Ensure path exists
if (-not (Test-Path $chromePath)) {
 New-Item -Path $chromePath -Force | Out-Null
}
Disable DevTools
New-ItemProperty -Path $chromePath -Name "DeveloperToolsAvailability" -Value 2 -PropertyType DWord -Force
Disable address bar editing
New-ItemProperty -Path $chromePath -Name "URLBlocklist" -Value @("*") -PropertyType MultiString -Force
Allow only specific URLs
$allowPath = "$chromePath\URLAllowlist"
if (-not (Test-Path $allowPath)) { New-Item -Path $allowPath -Force | Out-Null }
New-ItemProperty -Path $allowPath -Name "1" -Value "https://your-kiosk-app.example.com/*" -PropertyType String -Force
Disable browser history
New-ItemProperty -Path $chromePath -Name "SavingBrowserHistoryDisabled" -Value 1 -PropertyType DWord -Force
Disable password saving
New-ItemProperty -Path $chromePath -Name "PasswordManagerEnabled" -Value 0 -PropertyType DWord -Force
Block extension installs except allowlisted
$blockPath = "$chromePath\ExtensionInstallBlocklist"
if (-not (Test-Path $blockPath)) { New-Item -Path $blockPath -Force | Out-Null }
New-ItemProperty -Path $blockPath -Name "1" -Value "*" -PropertyType String -Force

This script produces a browser locked to a specific URL, with no history, no password saving, no extensions, and no DevTools access. Appropriate for public-facing terminals or staff-facing kiosk applications where browser functionality must be tightly constrained.

Summary

Disabling Chrome Developer Tools through Group Policy provides a straightforward mechanism for controlling browser debugging capabilities in enterprise environments. The key points:

Use policy value 2 for full DevTools disablement
Deploy via Group Policy Editor for AD environments or Registry for standalone machines
Verify deployment through chrome://policy and manual testing
Understand that determined users can find workarounds, use this as one layer of a broader security strategy

For most organizational use cases, combining Developer Tools restrictions with other Chrome policies creates an effective control mechanism that balances security with usability.

Try it: Paste your error into our Error Diagnostic for an instant fix.

I'm a solo developer in Vietnam. 50K Chrome extension users. $500K+ on Upwork. 5 Claude Max subscriptions running agent fleets in parallel. These are my actual CLAUDE.md templates, orchestration configs, and prompts. Not a course. Not theory. The files I copy into every project before I write a line of code. **[See what's inside →](https://zovo.one/lifetime?utm_source=ccg&utm_medium=cta-default&utm_campaign=chrome-disable-developer-tools-group-policy)** $99 once. Free forever. 47/500 founding spots left.