ungoogled-chromium-windows is two Python scripts and a MAX_PATH registry step

The whole build is two Python scripts and a directory to delete

The build runs in a Developer Command Prompt for VS, as administrator, and consists of a clone, a checkout, and two scripts:

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

build.py produces the browser, package.py wraps it, and the output is a zip archive plus an installer under build. The recovery story is stated just as concretely, and it turns on which stage failed. If the failure happened while downloading the Chromium source, deleting build\download_cache and starting over is enough, which keeps the multi-gigabyte download. At any other point in build.py, the instruction is to delete everything under build except that cache directory, which also throws away the checked out source and every generated file.

The suggested command for that is Remove-Item PATH -Recurse -Force, followed by a warning that anything it removes is permanently lost. Given that the advice is a recursive force delete over a path you typed by hand, that warning is doing real work.

The 64-bit default is justified with an unfinished note

The configuration defaults to 64-bit binaries, and the README gives one reason, followed by a placeholder where the reasoning should have been:

The default configuration will build 64-bit binaries for maximum security (TODO: Link some explanation).

So the strongest claim in the build configuration, that 64-bit is the safer choice, is asserted rather than argued, and the placeholder is still in the file. The alternative is one setting away: set target_cpu to "x86" in flags.windows.gn, which sits at the top level of the repository, or pass --x86 to build.py. Both routes end at the same place, so the GN file is the durable one and the flag is the convenient one.

The platform floor comes from Google rather than from this project: Google only supports Windows 10 x64 or newer for Chromium builds, and these instructions are tested on Windows 10 Pro x64. A 32-bit build therefore runs on hardware that the upstream build no longer supports.

The build process refuses depot_tools on purpose

The single most consequential instruction in the setup section is a prohibition. Set up only what is referenced, and do not install other Chromium compilation tooling such as depot_tools, because this project runs a custom build process that avoids using Google's pre-built binaries. Everything after that point is a deviation from the official Chromium Windows instructions, which are followed only for the Visual Studio component list.

Even that borrowed section arrives with stale sample values. When Visual Studio lives somewhere other than the default directory, three environment variables have to be pointed at the toolchain, and the README copies them from Electron's Windows build instructions:

* `vs2019_install = DRIVE:\path\to\Microsoft Visual Studio\2019\Community` (replace `2019` and `Community` with your installed versions) * `WINDOWSSDKDIR = DRIVE:\path\to\Windows Kits\10` * `GYP_MSVS_VERSION = 2019` (replace 2019 with your installed version's year)

The 2019 samples come from another project's documentation, while the newest published artifact here is built from Chromium 154. The instructions do tell you to replace them, which is the saving grace.

MAX_PATH has to be lifted before the Python scripts will run

Windows caps paths at 260 characters by default, and a Chromium checkout blows past that. The README marks this as a requirement for the Python build scripts rather than a suggestion. On Windows 10 version 1607 or newer it can be lifted with the official installer for Python 3.11 or later, because that installer offers a button at the end of setup to do it; a registry walkthrough is linked for people who install Python another way, and Issue #345 in the upstream repository collects the methods for older Windows versions.

Two smaller Windows traps come with it. The App execution aliases in Settings have to be turned off for python.exe and python3.exe, because the aliases the Microsoft Store installs are referred to as App Installer and will shadow your real interpreter. And the Python directory itself must contain a python3.exe or a symlink to it, since the build scripts are invoked as python3 throughout. The one library pin in the whole setup is httplib2 at version 0.22.0, installed with pip install httplib2==0.22.0, alongside 7-Zip, Python 3.11 or above, and Git configured with Git from the command line and also from 3rd-party software selected.

Two shells, two path conventions, and a patch binary from the source tree

Developer work needs two shells open at once, and they disagree about paths. The Developer Command Prompt for VS works in c:\path\to\repo\ungoogled-chromium-windows, while the MSYS2 MSYS shell works in /path/to/repo/ungoogled-chromium-windows, and the README offers Git Bash or manual drive letter translation as the bridge. First time setup installs a small MSYS2 package set and then fixes a missing editor:

pacman -S quilt python3 vim tar dos2unix
# By default, there doesn't seem to be a vi command for less, quilt edit, etc.
ln -s /usr/bin/vim /usr/bin/vi

The retrieval and patch steps run from the Visual Studio prompt and take their inputs from files in the repository, downloads.ini, pruning.list and the patches directory:

python3 ungoogled-chromium\devutils\update_lists.py -t build\src --domain-regex ungoogled-chromium\domain_regex.list
python3 ungoogled-chromium\utils\patches.py apply --patch-bin build\src\third_party\git\usr\bin\patch.exe build\src ungoogled-chromium\patches

Note where the patch program comes from: not from Git for Windows, but from the patch.exe inside the Chromium checkout at third_party\git\usr\bin, which is why the clone has to succeed before patching can start. Between those steps the README also asks you to check for a rust version change, with the explanation on the far side of where this file ends.

The winget identifier belongs to the upstream author

Two install routes are offered and they carry different names. Prebuilt binaries come from a Contributor Binaries website, a separate site from this repository. The package manager route is one command:

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

The identifier is eloston.ungoogled-chromium, not something under ungoogled-software, and that matches the upstream link at the top of the README, which points at Eloston's ungoogled-chromium repository. So a reader looking for this project in winget will not find it under the organization that hosts the Windows packaging. That same upstream link is written as a protocol relative URL, //github.com/Eloston/ungoogled-chromium, which renders correctly on the repository page and breaks anywhere the scheme matters.

For source work the guidance is the opposite of the usual advice: use a tag rather than the default branch, because master is described as being for development and possibly unstable. The releases follow that pattern, carrying upstream Chromium versions with a packaging revision appended, 153.0.8010.47-1.1, then 153.0.8010.52-1.1 the next day, then 154.0.8037.57-1.1.

The repository holds lists and a revision file, not Chromium code

The top level explains the division of labour. There is build.py, package.py and a devutils directory for the developer workflow, plus four data files that do most of the deciding: downloads.ini, which tells the scripts what to fetch, pruning.list, which is passed to the upstream update script, domain_substitution.list, and revision.txt, which pins the upstream revision. flags.windows.gn holds the build configuration where target_cpu is set, patches/ holds the Windows specific patch series, and the ungoogled-chromium directory at the top is the submodule that supplies the scripts the build calls, along with the pruning and patch tooling.

So a build failure in this repository is usually not a bug in Chromium. It is a mismatch between one of those lists and the upstream revision it was written against, which is why the update workflow rebuilds the pruning list with update_lists.py before patches are applied. The license is BSD-3-Clause, and the last push to the repository is dated 3 October 2026, six days after the newest published artifact.

Editorial conclusion

Treat this repository as what it is, a packaging layer over Eloston's ungoogled-chromium, and judge it by whether you want to rebuild a browser from source at all. The build path is well specified once you accept Visual Studio, MSYS2, Python 3.11 or newer and a modified MAX_PATH setting on the host, and the failure recovery rules are specific enough to be useful. Two things to check first: the 64-bit default is justified in the README with an unfinished note rather than an argument, and nothing in the README describes how to update an existing installation, since the published artifacts follow upstream Chromium version numbers and no procedure for moving between them is given. The prebuilt binaries come from a separate Contributor Binaries site, and the winget identifier belongs to the upstream author rather than to this repository.

Frequently asked questions

Official sources

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