Winapp2.ini is a hand-maintained map of what is safe to delete

Thousands of contributions, one INI file

Winapp2.ini is described as a massive, community-driven database of declarative cleaning routines for Microsoft Windows. It provides a comprehensive mapping of individual applications and system components to their transient data, which the documentation lists as temporary files, caches, logs and recently used lists among others.

The scale is the point. The README says the database has thousands of contributions spanning over a decade and a half, and that it is likely the most extensive dataset of its kind available on the internet.

The data model is a file of rules. The repository root holds `Winapp2.ini` itself, there is a `Non-CCleaner/` directory with the variants for other applications, a `Winapp3/` directory, an `Assembler/` directory, the `winapp2ool/` directory with the companion tool, a `diff.txt` with the change log, and `License.md`.

The audience is a user of a supported cleaner application who wants better rules than the ones shipped with it, and the README lists the compatibility set as CCleaner, BleachBit, System Ninja, Avira System Speedup, R-Wipe&Clean, HDCleaner and FluentCleaner. The project description is that it is a database for Windows PC maintenance software, and the primary language of the repository is Visual Basic .NET, which is the `winapp2ool` tool rather than the data.

The licence is CC-BY-SA-4.0, and the releases are dated snapshots, with v260915 published on 2026-09-15 and the last push on 2026-10-14.

Exhaustive rules are the safety mechanism

The why section is the most interesting part of the README, because it explains a design decision that looks inefficient until you understand the risk it avoids.

Winapp2.ini avoids the risks of overreach common in generic cleaning tools by adopting an exhaustive, declarative approach. Where many tools rely on sweeping file-type patterns applied across entire drives, Winapp2.ini demands explicitly defined target paths and a conceptual linkage between those targets and their parent applications. The stated priority is clarity, specificity and control over generalisation, and the result is described as an inspectable system that can be audited and safely customised to suit individual needs.

That is a lot of work for a cleaning rules file. A generic cleaner can say delete everything matching this wildcard anywhere on drive C, and it takes one sentence. Winapp2 requires someone to write down the exact path for each application's cache directory and to attach it to the application it belongs to, and that is thousands of entries maintained by volunteers over fifteen years.

The payoff is that a rule can be wrong without being catastrophic. A wildcard rule that catches a document directory removes the document. An explicit path that is wrong removes a cache. The whole dataset is built to make that class of mistake less likely, and to make the remaining mistakes visible to a reader who looks.

The second property follows from the first. Winapp2.ini functions as an extension of the applications it is compatible with, enabling it to be updated independently of them, and the README says that decoupling grants users greater freedom to move between tools and versions without sacrificing functionality.

The project says it will not make your computer faster

There is a section titled Will this help make my computer faster, and the answer begins with Probably not.

The reasoning is that on modern systems there is little performance incentive for this kind of system hygiene, and the README goes further, noting that over-cleaning caches can potentially reduce performance by forcing applications to rebuild data they could have reused. That is a more interesting claim than the usual one, because it inverts the premise the tool exists under. A cache is a cache because something reads it back, and deleting it moves work from the read path to the write path.

The reasons the README does give are more practical. Troubleshooting application issues, since a corrupt cache is a classic cause of an application misbehaving and clearing it is a diagnostic step. Reclaiming disk space. Minimising the size of system backups, since a machine with two hundred gigabytes of stale cache makes every backup larger for no benefit. Enhancing privacy. And, listed last, simply because tidying up feels good sometimes.

That last one is worth crediting. A cleaning tool that is presented as a performance utility generates disappointment, and a cleaning tool that is presented as housekeeping does not.

The disclaimer that follows is the other half of the honesty. Winapp2.ini is provided as-is and without warranty, and the documentation is explicit that its intent is to enable deleting files, folders and registry keys off your system in a way that is programmatic and potentially irreversible. Readers are told to exercise caution and take appropriate backups where relevant, and to use winapp2ool to manage the local copy, because it can provide bespoke changelogs which should be read carefully to fully understand the scope of changes between versions.

Flavors exist because the cleaners do not agree

A flavor is the result of specific sets of modifications applied to each Winapp2.ini update to produce variants which cater more closely to the features supported by particular applications.

The important detail is that this is an automated process carried out when Winapp2.ini is built for each update, so the flavors are always up to date with the latest version of Winapp2.ini even if the copy shipped with the application is not. They are intended to function as drop-in replacements for the Winapp2.ini that ships with each application.

The variants are described individually in the files of interest table, and the differences are not cosmetic.

The base Winapp2.ini, in the `Non-CCleaner/` directory, has no content removed or changed, and it includes rules which may overlap or conflict with the rules that ship with CCleaner or BleachBit. The CCleaner flavor is designed to reduce overlap with CCleaner's own rules and to integrate better with its interface. The CCleaner 7 flavor is converted to the entry format that CCleaner 7 requires, and it is not installed by hand, since winapp2ool downloads it and patches it into `ccleaner.ini`. The BleachBit flavor removes unsupported rules and passes the sanity checker. The System Ninja flavor replaces unsupported rules with ones that System Ninja can use. And the Tron flavor captures the downstream changes that Tron makes to the CCleaner flavor.

Each flavor has its own change log in the repository, in a `diff.txt` next to the corresponding directory, and the files of interest table links to each one separately.

So the practical shape of this project is one dataset with a family of views, and the file you need depends entirely on which cleaner you run.

winapp2ool is the part you actually run

The quick start is three steps and the first one is a download.

You download `winapp2ool.exe` from the repository, and if necessary open the winapp2ool settings and select your preferred flavor, with the default being the CCleaner flavor. Then you follow the installation guide for your cleaner application, and then you use winapp2ool to keep your copy updated and trimmed for optimal performance.

The tool is described as a robust tool that allows you to manage Winapp2.ini for your system, including automatic downloading and trimming, and it has its own README in the `winapp2ool` directory. The trimming is the part that is not obvious from the name. The base file contains rules that overlap or conflict with what your cleaner already knows about, so a copy that is not trimmed asks the cleaner to do the same work twice, and the tool removes what is redundant for the application you are using.

The installation section of the README is broken down per application, with subsections for CCleaner Classic, CCleaner 7, BleachBit, System Ninja, Avira System Speedup, Tron, R-Wipe & Clean, HDCleaner and FluentCleaner. The CCleaner 7 case is the one with a specific mechanism, since that file is not installed by hand but downloaded by winapp2ool and patched into `ccleaner.ini`.

The README also has a Contributing section and a Custom Content section, and the repository carries a `CONTRIBUTING.md`, an `Assembler/` directory and a `Winapp3/` directory. The releases are dated, v260915, v260730 and v260728.2, and each flavor's change log is the record of what moved between them.

Where a cleaning database is the wrong answer

The limits of this project are the limits of what it can be, and they are worth stating before anyone points a cleaner at a machine.

The first is that it is a database of deletions, and every entry in it is a decision somebody else made about a directory they thought was transient. The disclaimer says it plainly, that the intent is to delete files, folders and registry keys in a way that is programmatic and potentially irreversible. On a machine you own, with a backup, that is an acceptable risk. On a machine that belongs to somebody else, or on one where the application in question holds state you did not know was transient, it is not.

The second is the age of the entries. Fifteen years of contributions means the database contains rules for applications that no longer exist and for versions of applications that have since changed what they store. The project handles this with the per-flavor changelogs and the request to read them, which is a mitigation rather than a solution, because the rules for a current version of an application are indistinguishable from the rules for a version from 2013 unless you go and check.

The third is the premise, which the README itself undercuts. If the goal is speed, this does not deliver it and can make things slower. If the goal is disk space on a modern laptop with a large SSD, the benefit is modest and the effort is a judgement call. If the goal is privacy, then this is one tool among several and it is only as good as the paths somebody remembered to add.

The alternative approach, and the difference in approach is real, is to use the cleaner's own rules and treat the winapp2 database as a supplement for the handful of applications the cleaner does not know about. That inverts the relationship, and it is the right way round for most people. The full database earns its keep for someone with a large, ageing install and a long list of applications whose caches and logs are accumulating, who has read the change log for their flavor, and who is prepared to keep a backup.

Editorial conclusion

Winapp2.ini suits someone with a cluttered Windows install who wants cleaning rules they can read, audit and edit, and who uses one of the supported cleaner applications. It is the wrong tool for anyone expecting a performance fix, for anyone who wants to clean a machine they do not own, and for anyone who would rather not reason about which registry keys are about to be deleted. Check first the flavor you need against the cleaner you actually run, since the flavors differ precisely in the rules each application supports, and read the changelog for your flavor between versions, because the project asks you to treat the change set as the documentation.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. MoscaDotTo/Winapp2 on GitHub
4. README
5. Releases