How much space does iCloud Drive use on your Mac?
An iCloud Drive file can keep its full file size while its contents are not downloaded to your Mac. To understand local disk use, I separate three numbers: the file’s logical size, the bytes macOS reports as allocated on this Mac, and the storage the file uses in your iCloud account.
Finder tells you whether a file is downloaded. A disk-space scan can report local allocation for the files it can access. Neither number promises how much space you get back by deleting an item.
Why the local number changes
With Optimize Mac Storage turned on, Apple says your Mac can store older documents in iCloud when it needs more space. If space is not needed, the full contents of iCloud Drive stay on your Mac. See Apple’s Store files in iCloud Drive guide.
So the local footprint of iCloud Drive depends on what is downloaded right now. The same folder can use a lot of disk space on one day and very little on another, while its files keep the same sizes.
Check whether a file is downloaded
Open iCloud Drive in Finder and choose View → as List. Then choose View → Show View Options and select iCloud Status. Apple’s status guide explains the icons: In iCloud means the item is only in iCloud, and Downloaded means you can view or edit it with or without an internet connection.
To remove a local download and keep the file in iCloud Drive, Control-click it and choose Remove Download. To keep an item on the Mac even when space is needed, choose Keep Downloaded. Both actions are in Apple’s iCloud Drive file guide.
Remove Download is not the same as moving a file out of iCloud Drive or deleting it. Apple notes that dragging an item from iCloud Drive to another folder removes it from iCloud Drive on all your devices set up for iCloud.
What I measured in SimplyDiskSweeper
On 20 October 2026, I tested SimplyDiskSweeper 0.20.0 (build 19) on one Mac running macOS 27.0 (26A428), with one iCloud account. The test folder in iCloud Drive held three generated files of 8, 2 and 1 MiB, a 20-byte .gitignore, and three folders.
After the files uploaded, I used Finder’s Remove Download on the three .bin files. The .gitignore was meant to stay downloaded, but it was also not downloaded when I checked before the scan. I don’t know which action caused that.
Before scanning, metadata checks taken 47.6 seconds apart, with no scan in between, showed no change in sizes, allocation or download state. I then scanned only the test folder and checked the same four files again. All sizes in the table are bytes, and allocated means allocated locally on this Mac.
| File | Logical bytes | Allocated before scan | Allocated after scan | After scan |
|---|---|---|---|---|
| a-8m.bin | 8,388,608 | 0 | 0 | Not downloaded |
| Sub/b-2m.bin | 2,097,152 | 0 | 0 | Not downloaded |
| Repo/c-1m.bin | 1,048,576 | 0 | 0 | Not downloaded |
| Repo/.gitignore | 20 | 0 | 4,096 | Downloaded |
The scan reported 7 items and a 4 KB total. The three larger files showed as Zero KB in Largest Files, while their logical sizes stayed at 8, 2 and 1 MiB. Zero allocated bytes did not mean the files were empty or deleted. Their contents were not stored on this Mac at the time.
The .gitignore shows the opposite effect. Once downloaded, a 20-byte file used 4,096 bytes on disk, because the filesystem allocates space in blocks.
Why the .gitignore was downloaded
The .gitignore became downloaded between the pre-scan check and the post-scan check. SimplyDiskSweeper reads repository ignore files, so the scan reading it is the likely explanation. The test did not rule out Finder, background sync or indexing, so I can’t attribute that download to the scan alone.
What the test does not establish
This was four small files in one test folder on one Mac. It does not describe all iCloud Drive behavior or every macOS version.
The test folders stayed downloaded in every check. Finder offered Download Now and Keep Downloaded for the test folder, but not Remove Download, so I could not test scanning a folder whose own contents list was not on the Mac. The before-and-after checks also cannot rule out a file downloading and being removed again between them.
Apple’s technote on dataless files lists enumerating a directory’s contents as an action that may trigger materialization, which is the system downloading content again. It also says stat and getattrlist materialize any dataless intermediate folders in a file’s path. A scan that only reads sizes still cannot promise that nothing downloads.
Use a scan for a folder you choose
I build SimplyDiskSweeper. It ranks accessible files and folders inside a folder you choose by allocated size. The app is sandboxed, so it scans only the folders you choose and can access. It does not measure your iCloud account.
The public 0.21.0 release adds a dashed cloud for files that macOS reported as not downloaded when the folder was scanned. That marker describes the scan, not a live status, so a later download or Remove Download shows up after a rescan. My measurements above come from the earlier 0.20.0 test. I did not repeat them with the public 0.21.0 build.
A folder scan also doesn’t tell you how much space deleting something gives back. For a file’s download status, start with Finder. For finding large files more generally, see how I find large files on a Mac.
SimplyDiskSweeper 0.21.0 costs US$14.99 upfront and requires macOS 15 or later.