BleachBit: a GPL-3.0 system cleaner for Windows and Linux, run from source or a package

What BleachBit deletes, and who is meant to run it

The project describes itself in one line: "BleachBit cleans files to free disk space and to maintain privacy." That is the whole scope. It is not a registry optimizer, a driver updater or a startup manager. It finds files that applications leave behind (caches, logs, thumbnails, temporary files, session data) and removes them.

The audience is narrower than the download page suggests. BleachBit exposes two interfaces, a GUI and a command line, and the README points at both: the graphical workflow of selecting options, clicking Preview, reviewing files, and clicking Delete, and the CLI, reachable with `python3 bleachbit.py --help`. Someone who wants a cleaner they can schedule, script or inspect at the file level will find that here. Someone who wants a button that says Fix My PC will not.

The repository topics name the positioning directly: antiforensics, ccleaner-alternative, privacy, security, cross-platform, desktop-app, tui, gui. The antiforensics label is honest about the intent. Deleting a cache is a disk-space operation; deleting browser session and history artifacts is a privacy operation, and the same mechanism serves both.

Cleaner definitions: XML files, not hard-coded paths

The mechanism that matters is that the list of things to delete lives outside the Python code. The top-level repository contains a cleaners/ directory, and the README links a separate CleanerML repository, a BleachBit Miscellaneous repository and a Winapp2.ini repository. The project is built so that what gets deleted is data, and the engine that deletes it is code.

That split has consequences worth naming. Adding support for a new application does not require touching the application logic, and the project states that BleachBit itself, "including source code and cleaner definitions," is licensed under GPL-3.0 or later. A cleaner definition is therefore a reviewable artifact: you can read what paths and patterns a cleaner targets before you run it. It also means the quality of a cleaning run depends on the quality of the definition, not on the engine. A definition that matches too broadly will delete more than you intended, and no amount of care in the Python layer will catch it.

The engine side is Python. setup.py declares the package name bleachbit, the version taken from bleachbit.APP_VERSION, and classifiers including "Development Status :: 5 - Production/Stable" and "Operating System :: Microsoft :: Windows". The Windows and Linux split is visible in setup.py itself: desktop entries and icons are installed to /usr/share/applications and /usr/share/pixmaps on Linux, with separate branches for NetBSD and BSD paths.

Runtime dependencies are pinned in requirements.txt. psutil==7.2.2 is listed with the comment "avoid cleaning application that is running," which tells you the design intent: the process check exists so BleachBit does not wipe files belonging to a program that is currently open. requests is pinned with a Python-version split (2.32.5 below 3.10, 2.34.2 at 3.10 and above) and is used, per the file's own comment, to check for application updates and to download winapp2.ini. setuptools is likewise split at Python 3.9 versus 3.10 and above. PyGObject is not pinned, and the file says why: "Installation methods for PyGObject vary by system."

Installing BleachBit and running a first clean

The README gives a source-based path first. Install system dependencies, build translations, then start the application:

make install-deps       # runtime deps (auto-detects Debian/Fedora/openSUSE/Arch)
make -C po local        # build translations
python3 bleachbit.py

The Makefile comment says install-deps auto-detects Debian, Fedora, openSUSE and Arch, and forwards arguments to scripts/install-deps.sh, including a --venv option (INSTALL_DEPS_ARGS). The README notes that many Linux systems already have the basic dependencies and that you may skip the install step, though it points you back to dependency checking if anything fails.

Once the window opens, the README's own workflow is the safe one, and it is worth following literally. Review the preferences. Select some options. Click Preview. Review the files, toggle options accordingly, and then click Delete. The Preview step is not decoration; it is the only point where you see the actual file list before it is gone.

For scripted use, the CLI is the entry point:

python3 bleachbit.py --help

That prints the available command-line options. The README does not enumerate the flags, so read the help output rather than guessing at them.

If you are developing, testing or packaging rather than just running it, the extra toolchain is a separate target, and the common commands are listed explicitly:

make install-deps-dev
make tests   # run tests
make lint    # check .py and .sh files for issues
make pretty  # format .py and .xml files

For reproducible Linux builds there is a container path. The README states that docker/build.sh sets up a container, runs make tests, and builds packages for a selected distribution:

./docker/build.sh <distro> # distro is one of {debian, fedora, opensuse}

Artifacts land in ./docker-artifacts/<distro> on the host. This is the route to take if you want to see what the project produces on a distribution you do not run day to day.

Deletion is irreversible, and the Preview step is the only brake

The most important limitation is not a bug. It is the design. BleachBit removes files. There is no documented recycle bin step, no rollback command, and the README does not document undo. If a cleaner definition matches a file you still needed, the file is gone when the run finishes.

The Preview workflow exists precisely because of this, and it puts the burden on you. You are expected to read the list of files, toggle off the options that reach too far, and only then delete. A user who clicks through Preview without reading it has disabled the one safeguard the tool provides.

The psutil dependency is a second, narrower safeguard: the comment in requirements.txt says it is there to "avoid cleaning application that is running." That protects against wiping a live application's files, but it does not protect against a definition that targets the wrong directory, and it does not protect against deleting something you are not currently running.

The third constraint is definition quality. Because cleaners are data, a bad definition ships as easily as a good one, and the README does not describe a review or signing process for cleaner files. The project maintains separate cleaner repositories, which means the set of definitions you have depends on which repository you pull from and when. If you rely on winapp2.ini, note that requirements.txt lists requests partly for downloading it, so your definition set can change without the application changing.

Where BleachBit is the wrong tool: on a machine where you cannot afford a mistake and cannot restore from backup or snapshot, and on any platform the repository does not target. The topics list Windows and Linux desktops; Android is not among the supported targets.

BleachBit versus CCleaner: the difference is who writes the deletion list

The repository tags itself ccleaner-alternative, and the comparison is the one people actually search for. The meaningful difference is not the feature grid. It is where the knowledge of what to delete lives.

CCleaner is a closed product. You install it and trust that its maintainers have decided correctly which files are safe to remove. BleachBit is GPL-3.0, and the cleaner definitions are part of what the licence covers. You can open a definition, see the paths and patterns, disagree, and change them. That is a different relationship with the tool: it moves the decision from the vendor to you, and it moves the responsibility with it.

The second difference is the interface surface. BleachBit ships a GUI and a CLI, and the README documents running it from source with `python3 bleachbit.py`, which means you can run a specific version from a checkout rather than whatever a vendor pushed to your machine. The CLI makes scheduled or scripted cleaning possible without a paid tier.

The third is packaging. BleachBit is distributed through the project's own download page and through distribution packages (the debian/ directory and the Makefile's install targets are in the repository), and the source path is documented. That is more work than a single installer, and it is the trade for being able to read and rebuild what you run.

What CCleaner offers that BleachBit does not is a commercial support relationship. Nothing in the README, setup.py or Makefile describes a support contract, an SLA or a paid edition.

Licence, maintenance and the cost of upgrading

BleachBit is GPL-3.0, "or at your option, any later version," per the README, with the source code and the cleaner definitions both under that licence. The repository carries COPYING and every Python file carries an SPDX identifier, for example GPL-3.0-or-later in setup.py. One bundled component is treated separately: markovify is MIT-licensed, and the README says so explicitly. If you redistribute BleachBit, or ship it inside a product, the GPL-3.0 terms apply to the BleachBit code and definitions, and the MIT terms apply to markovify. This is a description of what the repository states, not legal advice; check COPYING and the markovify licence text for your own case.

Maintenance signals are strong in one respect and confusing in another. The repository is not archived, and the last push was on 2026-09-21. The release list, however, needs reading carefully. It shows v6.0.4 (stable) on 2026-09-08, v6.0.3 (beta) on 2026-08-18, and v0.1.0 ("first release") on 2026-09-09. A 0.1.0 published after a 6.0.4 stable is worth understanding before you pick a version; the README does not explain it. Verify which release you are actually installing.

Upgrade cost is low for the application and potentially higher for the definitions. The application is Python with pinned dependencies, and the source path is three commands. The definitions are a moving target if you pull winapp2.ini or the cleaner repositories, so an upgrade can change what gets deleted even when the version number barely moves. If you script BleachBit, pin both the application version and the cleaner set you tested against.

Editorial conclusion

BleachBit suits engineers and privacy-conscious desktop users on Windows or Linux who want to read the cleaner definitions before running them, and who accept that deletion is irreversible. It is the wrong tool if you want a one-click tune-up with no review step, if you expect it to run on Android (the repository lists no Android target; only Windows and Linux are named), or if you need a supported commercial product with a warranty. Before you run it, verify three things: that the cleaner file for your application exists and matches the paths on your system, that you have taken a backup or snapshot, and that the release you are installing is the one you think it is, given that the repository's recent releases include both a 6.0.4 stable and a 0.1.0 first release.

Frequently asked questions

Official sources

1. bleachbit/bleachbit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases