Ask three cleaners how much you can free. You will get three answers.
The gap is usually not a rounding error. It comes from the difference between what a tool can remove directly, what macOS already counts as available, and what the tool could not read. DDCC's number is often smaller, and it comes with the reasons attached.
- the plus means at least
- 10 folders could not be read
- 2 sizes are partial
- 67 apps listed
- 2.24 GB retained, not offered
- 10 dead artifacts found
- 27 items · 14.4s
- Trash only, no permanent delete
- you review every row
The total is a sum of files. It is never a question put to the disk.
This is the whole method, and everything else on this page follows from it. DDCC does not ask macOS how much room is free, compare that figure before and after, or estimate anything. It walks paths, sizes files it can name, and adds them up. Search the source for the system calls that report free space and you will not find them, because a number arrived at that way cannot be broken back down into the things it is made of.
Every byte has an address
If a byte is in the total, there is a row you can select, a path you can copy, and a folder you can open in Finder. Nothing is counted that cannot be pointed at.
The number is auditable
A total assembled from named files can be checked file by file, by you, with tools you already have. A total derived from free space can only be believed.
It reads smaller
Whole categories that inflate other totals are unreachable this way. That is a deliberate trade, and set against tools with every incentive to impress you with a number, it is often the least impressive one you will see.
A cleaner that measures free space can claim anything the disk happens to do next. A cleaner that adds up files can only claim the files.
Purgeable space is already available to macOS.
macOS keeps files it can delete under pressure and calls that storage purgeable. The system reclaims it when another app needs room. Counting purgeable space alongside removable files is one reason two tools can report very different totals; it is also a category DDCC cannot count even by accident, because purgeable space is a property of the volume and DDCC only ever adds up files.
| What gets counted | Is it really yours to reclaim? | DDCC |
|---|---|---|
| Purgeable space | Already available to macOS | Not counted |
| Local Time Machine snapshots | Managed by macOS, thinned automatically | Not counted |
| Cloud placeholder files | Not on your disk in the first place | Not counted |
| Content a hard link keeps alive elsewhere | No: deleting here frees nothing | Withheld, and stated |
| Folders it could not read | Unknown size | Disclosed, not guessed |
| Caches from a known pattern | Yes | Counted |
| App leftovers with evidence | Yes | Counted |
The plus sign means the measured total is a floor. Some folders could not be read, so the honest answer is sometimes "at least this much."
Six ways to make a number bigger.
None of these requires anyone to lie. Each is a defensible choice about what to count, and every one of them makes the headline figure grow. They are worth knowing by name, because once you can name them you can ask any tool, including this one, which it does.
Count storage the system already manages
Space the OS reclaims on its own when something needs it is not space a cleaner recovered. Counting it is the single largest source of disagreement between two totals on the same Mac.
Count the same bytes once per name
One file can have many names. Adding up directory entries instead of content is the easiest way to report a folder as several times its real size, and developer machines are full of folders built exactly that way.
Count the same bytes once per claimant
When several apps share one folder, charging its full size to each of them turns one payment into three promises. Only the last one to leave can actually collect.
Count what returns before you notice
A cache deleted at nine is often back by five past. The bytes were real and the recovery was real; the space was not kept. A total that does not distinguish these is measuring your patience, not your disk.
Count things nobody would agree to delete
Reach is cheap. Anything reachable can be added to a total on the assumption you will approve it in bulk, and a tool that never expects to be read closely has no reason to be selective.
Count problems instead of bytes
An issue count is the cheapest number on this list, because nothing has to be measured to produce one. It is not a size, it does not become free space, and it can be made as alarming as required.
DDCC has no feature that claims to make your Mac faster. It removes files you chose and reports how many bytes that freed. That is the entire claim, and it is deliberately a small one.
It tells you when it could not look.
Without Full Disk Access, parts of your disk are simply invisible to any app. Most cleaners quietly report a smaller number. DDCC says so on screen, marks every affected size with a plus, and offers to take you to the setting.
A byte counts only if this is the last name holding it.
A hard link is a second name for the same content. Delete one name and the bytes stay, because another name still holds them. This is not exotic on a developer's machine: package managers and toolchains build whole directory trees out of links into a shared store, precisely so the content is stored once.
So DDCC asks a narrower question than "how much is in here". It asks how much removing this would free. Content the measured folder holds every link to is counted once, however many names point at it. Content with a name living outside is counted as zero, because deleting here leaves it exactly where it was. The amount left out is printed on the row, so a folder that looks large in Finder and small here explains the difference itself.
Counted once
Three names, one file, one payment. Every link is yours, so removing the folder really does release the blocks — exactly once.
Counted zero
A name outside survives the delete and keeps the content alive. Those bytes are not this folder's to promise, so they are not in its number.
Last claimant wins
The uninstaller already held shared folders back until the last app using them was gone. The size measurement now answers to that same rule instead of contradicting it.
Every row names what made it.
A total is only as good as its rows, and a row is only as good as its reason for existing. DDCC will not attribute a folder to an app because the names look similar. It attributes when something on your Mac declares the relationship: a package's own uninstall manifest, an installer receipt, a signed entitlement. When nothing declares it, the folder is reported as unattributed rather than guessed at.
| Source of evidence | What it is | Where it comes from |
|---|---|---|
| Package uninstall manifests | 4,639 of 7,695 packages declare the paths they leave behind; 2,993 name an Application Support path | A 20 MB file already on your disk |
| Installer receipts | What an installer recorded that it wrote, path by path | /var/db/receipts |
| Signed entitlements | The app groups and containers an app is actually entitled to | Read in-process from the signature |
| Name resemblance | A folder whose name looks like an app's name | Not evidence; never used |
Two things follow from reading declarations rather than guessing, and both cost DDCC something. Declared paths are a wish list, not an inventory: a package can name folders it never created, so a path being declared is not proof it exists. And no declaration reaches everything: on the machine these figures were measured, sweeping without evidence left 312 leftover-looking entries totalling 220 MB, every one of them merely unattributed and not one of them proven dead.
Four places where totals need context.
Shared bytes are counted once
Three sibling apps sharing 1.84 GB do not become 5.5 GB of promises. The shared portion is held back until the last claimant is gone.
Running apps get no number at all
A live app keeps rewriting the files being measured. DDCC reports that instead of publishing a figure it knows is unstable.
Refusals stay visible
Paths DDCC's safety guard declined are listed with the reason, so you can see why they were left out of the removable total.
A stopped scan says so
Cancel halfway and the results stay on screen marked incomplete.
Where this number is still approximate.
Every section above describes something DDCC gets right. This one describes what it does not, because a page arguing that totals should carry their limits is obliged to carry its own. None of these is a bug report waiting to be filed; they are known, and they are here so that a total you read is a total you can discount correctly.
Cloned files still read high
macOS can copy a file by sharing its blocks rather than duplicating them, and each copy reports its full size while the content is stored once. Nothing macOS publishes prices that sharing, so a folder full of clones reads larger than deleting it would free. Hard links are handled exactly; clones are not, and the difference is invisible from outside.
Sharing is judged one item at a time
Each item is measured on its own, so content linked between two different rows is counted by both. Selecting both and removing them frees it once. Within any single row the accounting is exact.
Not every byte on the disk is in scope
Caches reports known cache and support paths. Files reports large, long-unmodified items outside them. A folder of many small files in neither place may not appear at all; DDCC never claims to account for the whole disk, and the two views are not a partition of it.
Age means last modified
The Files view sorts by modification date, not by when you last opened something. A file you read every week can look untouched for a year. The caveat is printed beside the file, not buried here.
These are the ones that are known. A tool whose limits list is empty has not looked for them.
Do not believe any of this. Check it.
Everything above is a claim about arithmetic, and arithmetic is checkable. DDCC is built so that verifying it needs nothing but the Mac you already have and about a minute.
Take a row to Finder
Every row carries its full path. Open it, Get Info, and compare. Where the two disagree, this page has already told you which of the reasons applies.
Undo the whole thing
Removals go to the Trash by default, so the check survives being wrong. Put it back, and free space returns to exactly where it started.
Read the code that counted
The rules on this page are a few hundred lines you can read in an afternoon, including the one that decides a hard link belongs to somebody else.