ungoogled-chromium-windows: building and installing ungoogled Chromium on Windows

What the Windows packaging repo actually contains

ungoogled-chromium-windows is not the browser. It is the Windows-specific wrapper around the ungoogled-chromium project, and the top-level layout shows the split: build.py and package.py drive the build and the packaging, flags.windows.gn holds the GN flags for this platform, downloads.ini and pruning.list describe what to fetch and what to strip, and the ungoogled-chromium directory is a submodule pointing at the shared scripts and patches. The README is explicit that the default configuration builds 64-bit binaries for maximum security, and that this can be changed to 32-bit by setting target_cpu to "x86" in flags.windows.gn or by passing --x86 to build.py. That is the whole scope: turn the upstream fork into a Windows artifact. If you want to know what ungoogling removes at the source level, this repository is the wrong place to read about it. It is for people who need a Windows binary they built themselves, or who need to carry their own patches on top of the fork, and for packagers who feed the Contributor Binaries site and the winget package.

How the build pipeline moves from downloads.ini to an installer

The mechanism is a two-stage Python pipeline. build.py retrieves and unpacks the Chromium source plus the ungoogled-chromium patches, applies those patches, and then runs the compilation. package.py takes the compiled output and produces a zip archive and an installer under build. The README's developer section exposes the intermediate steps that build.py automates, which is the clearest view of the data flow: downloads.py retrieve -i downloads.ini -c build\download_cache fills a download cache from the manifest, clone.py -o build\src materialises the source tree, update_lists.py regenerates the pruning list against that tree, downloads.py unpack expands the cached archives into build\src, and patches.py apply applies the ungoogled-chromium patch set to it. Windows-specific patches are then maintained separately through quilt, which is why the developer setup installs quilt, python3, vim, tar and dos2unix via pacman in an MSYS2 shell. One design decision worth naming: the README says not to install Chromium's depot_tools, because the custom process deliberately avoids Google's pre-built binaries. That is a real constraint on your environment, not a suggestion.

Installing ungoogled Chromium on Windows without compiling it

Most people searching for ungoogled chromium windows install do not need this repository at all. The README points at two ready-made routes. The first is the Contributor Binaries website, which hosts downloadable binaries. The second is winget, with the package id eloston.ungoogled-chromium, which is the closest thing to a normal Windows install flow here. Run this from a terminal where winget is available and you should end up with the browser registered as an installed application rather than a folder you manage by hand.

winget install --id=eloston.ungoogled-chromium -e

For a portable-style setup the README says the zip archive produced by package.py is the artifact to look for, and the Contributor Binaries site is the download location it names. Note what the README does not say: it gives no uninstall command, no per-user versus system-wide install distinction, and no update procedure beyond the release tags, so treat updating as replacing the binary rather than as a managed upgrade path.

Building ungoogled-chromium-windows from source on Windows 10

This is the path the repository exists for. The README says the instructions are tested on Windows 10 Pro x64 and that Google only supports Windows 10 x64 or newer, so a Windows 7 build is not something these instructions cover. Set up Visual Studio following the official Chromium Windows instructions, and if it lives outside the default directory, set vs2019_install, WINDOWSSDKDIR and GYP_MSVS_VERSION so the toolchain can be found. Then install 7-Zip, Python 3.11 or above, and httplib2 pinned at 0.22.0, and lift the MAX_PATH limit, which the README states is required for the Python build scripts. The build itself runs in an administrator Developer Command Prompt for VS.

git clone --recurse-submodules https://github.com/ungoogled-software/ungoogled-chromium-windows.git
cd ungoogled-chromium-windows
# Replace TAG_OR_BRANCH_HERE with a tag or branch name
git checkout --recurse-submodules TAG_OR_BRANCH_HERE
python3 build.py
python3 package.py

The README recommends checking out a tag rather than master, which it describes as development and possibly unstable. When the commands finish, a zip archive and an installer appear under build. If the build fails, the recovery rule is specific: a failure while downloading Chromium source during build.py is fixed by deleting build\download_cache and re-running, while a failure anywhere else in build.py means deleting everything under build except build\download_cache. The README suggests Remove-Item PATH -Recurse -Force for large deletions and warns that files removed that way are permanently lost.

Where the packaging approach breaks down

The first limitation is environmental. The README requires Visual Studio, an administrator command prompt, Python 3.11 or above, httplib2==0.22.0, 7-Zip, Git with command-line integration, and a lifted MAX_PATH limit, and it warns against installing depot_tools. That is a narrow corridor. A machine with an older Python, a 32-bit Windows install, or a locked-down filesystem policy is outside it. The second is failure recovery: the README documents two distinct cleanup procedures and nothing finer, so a partial build leaves you deciding between clearing the download cache and clearing almost the entire build directory. The third is the artifact's lifecycle. Releases carry version strings like 154.0.8037.57-1.1, and following Chromium upstream means rebuilding on that cadence; there is no incremental update channel described in the README. Finally, this is the wrong repository if your goal is to audit what ungoogling changes. The patches live in the ungoogled-chromium submodule and the shared project, and this repo is the Windows assembly line for them.

ungoogled-chromium-windows against Chromium's own build instructions

The obvious alternative is building Chromium itself using Google's official Windows build instructions, the same document this README links to for the Visual Studio setup. The difference in approach is deliberate: Google's flow centres on depot_tools, gclient sync and Google's pre-built binaries, while this repository runs a custom Python process that the README says avoids those pre-built binaries and instead drives downloads.ini, clone.py, patches.py and package.py directly. Choosing Google's path gets you a standard Chromium build with the tooling Google supports and no patch maintenance. Choosing this path gets you the ungoogled patch set applied and a Windows installer produced from it, at the cost of maintaining quilt-managed Windows patches and re-running the pipeline as upstream moves. If you want a browser rather than a build process, neither is the right answer; the Contributor Binaries site and winget are.

Maintenance cadence, licensing and the cost of keeping up

The last push to this repository was on 2026-09-25, and releases have followed each other closely, with 154.0.8037.57-1.1 published on 2026-09-27 and two 153.x builds in the week before. That cadence is the upgrade cost in practice: each Chromium version bump means the patches have to apply cleanly against a new source tree, which is what the quilt workflow in devutils is for. The README's developer section documents set_quilt_vars.sh, editing inside build/src, and regenerating the pruning list with update_lists.py, so patch maintenance is a supported activity rather than an accident. On licensing, the repository is BSD-3-Clause and the LICENSE file sits at the top level, but that covers this packaging code and not the Chromium source it pulls in, which carries its own terms. Redistributing a build you produce is a question for whoever owns the combined work, not something the BSD-3-Clause header settles; read the upstream licensing before you ship binaries.

Editorial conclusion

Adopt this repository if you want a Windows build of ungoogled Chromium you compiled yourself, or if you maintain patches on top of it; the README targets Windows 10 Pro x64 and Visual Studio, so a Linux or macOS machine cannot follow it. Skip it if you only want a browser binary, since the Contributor Binaries site and winget install path already cover that, and skip it if you need 32-bit output without editing flags.windows.gn or passing --x86. Before committing, verify three things: that your Python is 3.11 or above with httplib2==0.22.0 and the MAX_PATH limit lifted, that your Visual Studio install path matches the vs2019_install, WINDOWSSDKDIR and GYP_MSVS_VERSION variables if it is non-default, and that you have a tag checked out rather than master, which the README calls development and possibly unstable.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. ungoogled-software/ungoogled-chromium-windows on GitHub