WinDebloat removes Windows 11 apps by name and shows the raw command for each

The tool is installed globally with dotnet and needs winget beside it

WinDebloat is distributed as a .NET global tool, and the install is one line:

dotnet tool install -g WinDebloat

Two requirements sit alongside it. The dotnet CLI is needed at version 8 or above, and WinGet is needed at version 1.5.2201 or above, with the readme pointing at the winget-cli releases page to install a specific version. Both are hard requirements rather than recommendations, because the tool drives winget for the uninstall steps. The readme is also explicit that this is a dotnet tool that removes the bloat in Windows 11, and it puts a warning at the very top: the tool makes changes to the Registry, and it suggests doing a backup before using it. That warning is the right frame for everything that follows, since the registry is where the reversals and the irreversible-looking changes both live.

Every action has an id, and the id is what you pass on the command line

The design is simple enough to describe in one sentence: every removable thing has a short id, and you select things by id. The readme lists them all, and the ids are case insensitive. Running the tool with no arguments applies the default set:

WinDebloat

Optional items are added back with the `--include` argument, for example `WinDebloat --include Paint`, or all at once with `--include-all`. Items are removed from the run with `--exclude`, and the documented example excludes two ids at once:

WinDebloat --exclude AdvertiserId Xbox

The list of items is long and specific. The readme enumerates them with anchors, and the ones visible in it include `3D Viewer`, `Advertiser Id`, `Bing Desktop Visual Search`, `Bing Wallpaper Context Menu`, `Camera`, `Chat`, `Clock`, `Clipchamp`, `Cortana`, `Copilot`, `Consumer Features`, `Customize This Folder`, `Default Browser Prompt`, `DevHome`, `dotnet`, `Developer Mode`, `Edge Auto Launch`, `Edge Background Mode`, `Edge Bing SideBar`, `Edge Default Location To Blank`, `EdgeRecommendations`, `Explorer 3D Objects`, `Explorer Classic Menu`, `Feedback Hub`, `FileExtensions`, `FilmsAndTV`, `Games`, `Game Assist`, `Get Help`, `Give Access To`, `Health Check`, `HP Vendorware`, `Internet Connection Sharing`, `Lock Screen Ads`, `Mail and Calendar`, `Maps`, `Media Player`, `Mixed Reality Portal`, `Movies and TV`, `News`, `OneNote`, `Office 365`, `OneDrive`, `Pay`, `People`, `Phone Link`, `Photos`, `Power Automate`, `PowerShell Unrestricted`, `Printer`, `Print 3D`, `Program Compatibility Assistant`, `Quick Assist`, `Recall`, `Restart Apps`, `Skype`, `Spotify`, `Startup boost`, `Start Menu Recommendations`, `Sticky Notes`, `Store Notifications`, `TaskBar Search`, `Task View`, `Teams`, `Teams Installer`, `Telemetry`, `Text and Image Generation`, `Tips`, `To Do`, `Visual Studio Telemetry`, `Voice Recorder`, `Weather`, `Web Experience Pack`, `Start Menu Store Search`, `Start Menu Web Search`, `Whiteboard`, `Widgets` and `Xbox`. The exact id for an entry is given under its heading, in the form `Id to exclude: `3DViewer``, and those ids are not always the item name with the spaces removed, which is why the readme prints them next to each entry. Items marked optional in the readme, such as `Clock`, `Copilot`, `dotnet`, `DeveloperMode`, `Recall` and `Printer`, are the ones that need `--include` to be touched.

Publishing the raw command next to each item is the real feature

The readme does something unusual for a tool like this. For each entry it lists the id to exclude, the command to apply manually, the command to revert it, and a notes section with links. For the 3D Viewer, the manual command is a winget uninstall:

winget uninstall --name "3D Viewer" --exact --all-versions

For the Advertiser Id, both directions are registry writes, and the revert is the same command with the value set to 1 instead of 0:

Set-ItemProperty -Path "Registry::HKCU\Software\Microsoft\Windows\CurrentVersion\AdvertisingInfo"`
                 -Name "Enabled"`
                 -Type "DWord"`
                 -Value "0"

The readme then shows the same pattern for the Bing Desktop Visual Search icon, with the property `ShowVisualSearchDesktopIcon` toggled between 0 and 1. This design has a practical consequence that is bigger than convenience. Because the commands are published, you can read exactly what will happen before you run anything, you can apply a single change with winget or PowerShell instead of running the tool, and you can reverse one item without reversing all of them. It also means the tool is not a black box you have to trust, which is the only sensible position for something that edits a registry.

The items fall into two kinds of removal: uninstall and registry disable

Reading a few entries together shows that WinDebloat does two different things and is honest about which is which. Store applications such as the 3D Viewer are removed through winget, with the exact flag set, and the readme links to the Microsoft Store listing for each. Registry-backed features are handled with `Set-ItemProperty` against a path under `HKCU\Software\Microsoft\Windows\CurrentVersion`, and each of those has a documented inverse. The difference matters because the two are not equally reversible. A winget uninstall can be redone by installing the app again from the store, but it may also pull a dependency or a registration the user relied on. A registry property flip is a single value, and the readme gives you the exact value to put back. Some entries also carry consequences that go beyond the property itself. The Bing Desktop Visual Search entry notes that disabling the icon prevents launching a browser with a Bing search when the desktop is clicked, which is a behaviour change rather than a cosmetic one.

A dotnet tool means the release channel and the runtime are yours to manage

The packaging choice has consequences worth understanding before you install. A dotnet global tool is a NuGet package that runs on the .NET runtime, which means your machine needs a compatible runtime and the tool is updated with the same `dotnet tool update` mechanism as any other global tool, or by uninstalling and reinstalling. The repository layout is minimal: a `src/` directory holding the tool, a `global.json` at the root that pins the SDK version the project builds against, plus the readme, the licence and the GitHub workflow directory. The build badge and the NuGet status badge sit at the top of the readme, and release notes are not in the readme itself, which instead points at the closed milestones in the repository. The release cadence visible in the tags is frequent, with 1.16.0 on 2026-09-26, 1.17.0 on 2026-09-29 and 1.18.0 on 2026-10-20, which is what you would expect from a tool whose list of targets changes whenever Windows ships a new preinstalled app.

The registry warning is the reason to read the notes before running it

The limitation of this tool is not a bug but a property of what it does, and the project states it plainly. The readme warns in a callout that the tool makes changes to the Registry and suggests a backup first, and it does not document a rollback command for the whole run, only per-item revert commands for the entries that use the registry. That asymmetry matters. If you exclude two ids and want them back, the documentation gives you the exact property values. If you run the full default set and something you relied on disappears, the per-item commands still apply, but there is no single undo. There is also no documented way to reinstall a Store app that was uninstalled in a way winget can restore, so the recovery path is manual in that case. The project is MIT licensed, and the readme notes that it targets Windows 11 specifically.

How this differs from a provisioning script or an official debloat script

There are two reasonable alternatives, and the difference in approach is instructive. The first is to treat the machine as an image problem: build a Windows install with the unwanted applications absent, and apply it with an unattended answer file or a deployment tool. That approach removes the apps before the user ever sees them and produces identical machines, at the cost of an image pipeline to own and update whenever Microsoft changes the preinstalled set. The second is a larger community script that edits the registry directly and covers far more surface than WinDebloat does, including policy keys, scheduled tasks and service configurations, which gives a cleaner machine but makes each change harder to attribute and to reverse. WinDebloat sits between the two. Its scope is the preinstalled application set, its unit of work is a named id, and its distinguishing property is the published inverse for each action. The value of that is highest on a machine you own personally and have to live with, and lowest in a fleet where consistency comes from the build pipeline rather than from a per-machine script.

Editorial conclusion

WinDebloat earns its place on a fresh Windows 11 install where the preinstalled app set is unwanted, because it works by id rather than by guesswork, and because every action it performs is published next to the command that performs it and the command that undoes it. It is a poor fit for a managed corporate image, where application removal belongs to a policy or an image build rather than to a script run against the registry, and a poor fit if you want a clean slate, since it removes named applications rather than resetting the installation. Before running it, read the warning in the readme and back up the registry, since the tool makes registry changes and the project says so, and note that the last push to the repository was on 2026-10-20 with release 1.18.0 published the same day, so a fresh Windows 11 build may need a newer winget than the version 1.5.2201 minimum stated in the requirements.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SimonCropp/WinDebloat on GitHub