Is this a good cleaner?
A cleaner asks for something no ordinary app does: broad permission to delete across your system, before it has proven anything. The category makes it worse, because the honest entries and the dishonest ones look identical from the outside. There is no single check that settles the question, but the risk breaks into a few distinct shapes, and each has tells. (If you are on the other side of this question, building one, see why writing a system cleaner is hard.)
Start with whether you need one at all
- For many people the better tool is a general storage analyzer, which shows what is using space without deleting anything. It answers “why is my disk full” without handing delete access to any app.
- The storage tools already built into your operating system cover more than they used to, and they carry no third-party risk at all.
Trust is a feature, and it is counterfeited easily
- A cleaner is a prime target for malicious actors. It is a user-approved tool with reach across the whole system, including the browser data where sessions and credentials live.
- It is now trivial to produce a convincing, even functional, clone of a real app with malicious code hidden in the binary. Trying it proves nothing: the fake one cleans too.
- A GitHub repository is not a trust signal. Hosting fake repos that mimic real projects is a popular attack vector.
- Neither are the softer signals. “Indie solo developer”, “built by a fellow user frustrated with the conventional cleaners”, “open source”: each of these has been specifically abused, precisely because they are the signals a person checking quickly looks for.
To be fair: most new apps are not scams. There are many new cleaners, including small GitHub projects from solo developers, that are safe and well made. The problem is not that new apps are bad. The problem is that good and bad ones are genuinely hard to tell apart before installing, because every quick signal has already been faked.
Risk is not only malice
A cleaner can hurt you several ways, and they do not all need a villain. They run from deliberate malice to plain neglect:
- A malicious publisher. The app itself is the attack, built or acquired to harvest data and open doors. This is not hypothetical: we already cataloged one. SwiftClean was promoted on Reddit as a “free and open-source MIT” cleaner for Windows and macOS, yet its repository contained no source code at all, and its sole release was a password-protected archive confirmed malicious on manual analysis.
- A predatory business model. Commercial scareware is its own category: legally registered businesses selling aggressive utility software that blurs upselling into extortion. Manufactured urgency in the scan results, “remediation” paywalled behind a purchase, and a persistent presence of background daemons, pop-ups, system tray alerts, and even artificial performance throttling all press the user to pay.
- A good app turned against itself. Attackers abuse legitimate software through code paths that were never battle-tested: the auto-updater, the definition loader, the obscure cleanup routine nobody exercised.
- Perverse incentives. The number that sells a cleaner is gigabytes freed, so even a well-behaved app is tempted to count files that are safe-looking but useful: caches, logs, and thumbnails the system will rebuild. Nothing is “lost”, but you pay in rebuild time, write cycles, and a slower machine while everything warms back up.
- An honest accident. No software is bug-free, and a cleaner’s bugs delete things. A well-meaning developer can ship a symlink bug or a bad definition with no ill intent from anyone.
- An abandoned app. Maintenance stops and the definitions go stale, but the rules keep deleting by last year’s map. An unmaintained cleaner can quietly become a wrong cleaner.
The no-villain risks grow with complexity. An all-in-one app that cleans, optimizes, uninstalls, finds duplicates, and monitors carries far more code, more of it elevated, and more corners that testing never reached. More code means more bugs, and more places for someone else to hide one.
Table stakes
Before any positive signal counts, some behavior ends the evaluation. Confirmed malware is the obvious end of that line, but disqualification starts well short of it. Google’s Unwanted Software Policy, the criteria behind Safe Browsing’s download warnings, reads like a survey of this category’s worst habits. For a cleaner, the floor looks like this:
- The ad and the app must match. Download ads must say what the software actually is, and endorsements and logos must be authorized. A “your PC is infected” ad that installs a cleaner is social engineering, whatever the app does after it lands.
- Bundled extras must be skippable, and the bundler owns them. The installer must give the user a clear way to decline each extra component, and the publisher answers for everything it ships alongside the app. A cleaner that arrives with a partner toolbar or a pre-checked “recommended” install has already disclosed its business model.
- The scan must not manufacture panic. The policy names this exact category: cleaners and optimizers may not claim the system is in a critical state or infected, and may not promise a fix the app cannot deliver. A scan that finds hundreds of “problems” on every healthy machine is manufacturing the sale.
- Free must mean free. A product advertised as free may not paywall the advertised service. A free scan that finds the problem, paired with a paid download that removes it, is the scareware funnel.
- The inventory stays on the machine. Private user data may reach a server only as the app’s function requires, disclosed and encrypted. A cleaner legitimately reads browsing history, installed apps, and file names; an undisclosed upload of that list is disqualifying on its own.
- It must not weaken the platform. No installing a root certificate authority, no intercepting encrypted connections, no suppressing the operating system’s own security warnings.
- Uninstall must be findable, complete, and quiet. The uninstaller removes every component, and it may not warn that removing the software will hurt the system. A cleaner you cannot fully remove resembles the thing it claims to protect against.
Each of these is pass or fail: age, stars, and market share cannot offset one. Clearing the whole list still proves little, because this is the floor; the signals below are what separate the apps that clear it.
Signals that reduce the risk
No single signal settles it, so read them together:
- Maturity. Years in the wild means the code paths have been exercised on many real machines, not just the developer’s.
- A large user base. More users means more casual testers, more developers reading the code, and more people who notice when something is off.
- Focus. A tool that does one thing has a smaller surface to audit and fewer ways to go wrong.
- Freshness. A recent release or commit means the definitions are keeping pace with the platform. Stale is a warning; abandoned is worse.
- Release discipline. Look for a testing cycle that runs ahead of stable releases: betas, release candidates, staged rollouts. Two “stable” releases in one day usually means the users are the testers.
- A digital signature on the release binaries: Authenticode on Windows, Apple notarization on macOS, GPG-signed packages on Linux, ideally from an identity with history.
- Source code availability. Not strictly required, but public source raises the ceiling on trust: anyone can audit instead of taking the marketing’s word for it.
- Reproducible builds. Source alone is only half of it: deterministic or reproducible builds let anyone verify the distributed binary was built from that audited source, without a tampered build pipeline in between.
None of these is a guarantee, and neither business model ticks every box by default: a paid product is not safe because it is paid, and a free, open-source app is not safe because it is open.
Silence is not safety
Bug and CVE counts are weak signals in either direction. Zero mostly measures how hard anyone has looked.
- Green flag: public security patching. A changelog that marks security fixes, a security contact or disclosure policy, an audit or a bug bounty: proof the project is examined and maintained.
- Red flag: a “zero bugs” history. Flawless code does not exist. An app that runs elevated, has plenty of users, and has never once reported a security fix is unexamined, not safe.
- Red flag: fixes shipped in secret. Security patches folded into generic “improvements and fixes” entries mean the project does not want you counting.
Transparent patching is the real feature, not a clean record.
The takeaway
No single signal settles the question, because every quick signal has already been faked. What helps is evidence that is expensive to fake: years of working code, a visible history of fixing reported problems, a small privileged surface, and a community that would notice something wrong. That is what this catalog tries to record, one entry at a time.
Last reviewed