August 18, 2026

Windows cleanup guide: reclaim disk space on every version from 7 to 11

Nobody installs anything anymore, and the C: drive keeps filling up anyway. That is not paranoia — it is an accurate observation. Windows grows from the inside: every cumulative update stages gigabytes of payload, every version upgrade parks a complete copy of the previous OS under C:\Windows.old, every crash writes a dump, every update to every Store app leaves the old package behind, and the WinSxS folder silently expands as component versions accumulate. Add a developer’s daily life on top — npm installing half the internet, Docker pulling image layers, gradle caching every dependency it has ever seen — and a 256 GB drive that felt enormous in year one is showing a red bar in year two.

A red bar is not just ugly. Windows needs free space to function: updates stage and swap through it, the pagefile grows into it, restore points and TRIM on SSDs behave better with headroom. The practical floor is roughly 10–15% free on an SSD. Below that, updates start failing in confusing ways.

The good news: an enormous fraction of what occupies your disk is disposable by design — caches, staged payloads, superseded components. The cleanup is safe when you use the mechanisms Windows ships for exactly this purpose, and dangerous only when you go around them with a file explorer and a sense of certainty. This guide is organized by Windows version, from 11 down to 7, then covers the command-line layer that works everywhere, the developer caches that generic advice never mentions, and the short list of things you must never delete.

Windows 11 and Windows 10: Storage Sense first, always#

Windows 10 (1709 and later) and Windows 11 share the same storage housekeeping engine, and the Settings app is now the primary interface for it. Open Settings → System → Storage and the first thing Windows does is run a categorization pass showing where the bytes went — apps, temporary files, documents, System & reserved. This page is worth sixty seconds of reading before you delete anything: it replaces the guesswork that made “cleanup” a ritual in older versions.

The differences between the two are cosmetic and incremental. Windows 11 moves Storage Sense into System → Storage → Storage Sense with slightly clearer wording and per-policy toggles, adds Cleanup recommendations (a page that surfaces large unused files, unused apps, and sync-provider leftovers), and ships smart app control leftovers under the same roof. Windows 10 in its later releases (21H2) has essentially all of the underlying machinery; if you learned one version, you know the other.

Storage Sense: automatic cleanup, configured once#

Storage Sense is the closest thing Windows has to a garbage collector. When enabled, it runs during periods of low activity — or immediately, via the “Run Storage Sense now” button — and clears:

Files that have been in the Recycle Bin for longer than your chosen threshold (1/14/30/60 days, or never).
Files in the Downloads folder older than a separate threshold (off by default — deliberately, see below).
Temporary files that applications created and left behind.
Delivery Optimization cache files (Windows 10 1803+).
Older versions of Windows Update artifacts and, when you explicitly request it, previous Windows installations.

The one setting to think hard about is Downloads. Every developer has a Downloads folder that is half archive, half landfill — installers you might re-run, datasets, that one zip a colleague sent three months ago. Storage Sense’s default of not touching Downloads is correct for most people; if you enable the 30-day rule, adopt the habit of moving anything you care about out of Downloads within the month. Otherwise you will someday lose a file and spend an hour remembering that you automated this.

A sane baseline configuration: Recycle Bin at 30 days, Downloads off, temporary files on. That is enough to keep ordinary drift under control without ever surprising you.

Temporary files: the one-click cleanup#

Settings → System → Storage → Temporary files opens the checklist view. It enumerates what is actually reclaimable and shows a live total as you tick boxes: Setup log files, Temporary files, Thumbnails, Delivery Optimization files, Recycle Bin, Downloads (shown here too, with the same caution), Windows upgrade logs, and — after a feature update — “Previous Windows installation(s)”.

Two principles govern this page. First, anything Windows lists here is something Windows considers safe to remove in principle — but “safe” is contextual. Thumbnails will simply regenerate the next time you open a picture folder, costing a few seconds; DirectX shader caches will recompile on next launch, costing a few minutes of stutter; a previous Windows installation is gone for good. Second, the checklist pre-ticks only what is unambiguously safe. If you untick nothing and remove, you will not break your machine.

Windows.old: the rollback insurance you eventually cancel#

After a feature update — the annual “version” jump, not the monthly cumulative — Windows does not delete your old OS. It moves the entire previous C:\Windows into C:\Windows.old, alongside C:\$WINDOWS.~BT (staging for the new build) and C:\$Windows.~WS (setup working files). For roughly ten days by default, you can roll back via Settings → Windows Update → Update history → Uninstall updates (Recovery → Go back on Windows 10). This is genuine insurance: if an update breaks a driver or an app that matters to you, rollback restores the entire previous system, files and settings included, in about twenty minutes.

After the window closes, Windows deletes Windows.old automatically via Storage Sense or scheduled maintenance — eventually. In practice, “eventually” can mean weeks, during which 20–35 GB sits idle. Two safe ways to reclaim it sooner:

Temporary files checklist → tick “Previous Windows installation(s)” → Remove files. Clean, sanctioned, immediate.
Storage Sense → run now with “Previous Windows installation(s)” included in its scope.

What you should not do is delete C:\Windows.old from File Explorer. The folder’s ACLs belong to TrustedInstaller, the deletion partially fails, and you inherit a zombie directory that even administrators struggle to remove. Use the sanctioned path; it exists precisely so you never have to fight permissions.

The decision framework is simple: keep the ten-day window if the update is fresh and your machine is production-critical; reclaim immediately if you have verified everything you depend on works post-update. As a developer, “everything” includes Docker Desktop, WSL2, VPN clients, and driver-dependent tooling — the exact category of software most likely to break on a feature update.

Delivery Optimization: the peer-to-peer update cache#

Windows updates arrive faster and cheaper because every PC shares: your machine downloads pieces of updates from Microsoft’s CDN and from other PCs on your network or the internet, and serves pieces back. The cache of already-downloaded pieces lives in C:\Windows\SoftwareDistribution\DeliveryOptimization and can occupy several gigabytes.

It is a cache in the purest sense — deleting it costs nothing except re-downloading. Settings → System → Storage → Temporary files → Delivery Optimization files clears it, or Storage Sense handles it automatically. The Settings app also lets you cap the cache size and disable internet-peer sharing if you pay for bandwidth; the cache-clearing part is the one relevant to disk space.

Recycle Bin and Downloads: automated policies#

Two habits keep these two folders from becoming problems:

Recycle Bin: let Storage Sense empty it on a 30-day cadence. A file deleted 30 days ago that you have not missed is, empirically, a file you did not need. Also worth knowing: the Recycle Bin has a per-drive quota (right-click the Bin → Properties). The default is 5–10% of the drive, which on a 1 TB volume means up to 100 GB of “deleted” files quietly consuming space — shrinking it to a fixed size is a legitimate lever.
Downloads: adopt a monthly triage — anything you will need again moves to a project folder or a proper archive location; anything you will not, goes. Tools like Storage Sense can automate the deletion end of it, but the sorting is a human skill, and the fifteen minutes a month it takes is cheaper than the alternative.

Windows 8 and 8.1: Disk Cleanup with a touch overlay#

Windows 8 sits between eras: it has the modern Storage Spaces UI and a touch-first shell, but storage housekeeping is still the classic Disk Cleanup tool wearing a Metro costume. The touch-optimized path: open the Charms bar (swipe from the right, or Win+C), Settings → Change PC settings → PC and devices → Disk space, which surfaces a “See my app sizes” view and a shortcut to free space — a precursor of the Windows 10 Storage page, minus the automation.

The real work happens in cleanmgr, which on 8/8.1 is fully functional and, importantly, knows about the new-age leftovers:

cleanmgr /d C:

That opens the classic dialog. The workflow that matters on 8/8.1:

Run cleanmgr, pick C:, and you get the per-user view — temporary internet files, thumbnails, Recycle Bin.
Click Clean up system files — the button that re-launches the tool elevated and unlocks the heavyweight categories: Windows Update Cleanup (superseded updates — routinely several GB on a mature 8.1 install), Previous Windows installations, Service Pack files, and device driver packages superseded by newer ones.

Windows 8.1 additionally added an automatic maintenance slot (Control Panel → System and Security → Security and Maintenance → Maintenance) that runs Disk Cleanup’s safe subset on a schedule alongside other idle-time tasks. It is modest, but it explains why an unattended 8.1 machine does not grow quite as fast as a Windows 7 one.

One caution specific to this era: 8/8.1 reached end of support in January 2023, and Windows 8.1 machines still in service are usually running unsupported hardware or legacy software. Cleaning such a machine is fine; migrating it is the better conversation — an OS without security updates accumulates risk faster than it accumulates temp files.

Windows 7: the classic, still everywhere#

Windows 7 end-of-life passed in January 2020, yet an enormous population of 7 machines still runs — in factories, labs, behind instruments, in offices where “if it boots, don’t touch it” is policy. Their disks are small (120–500 GB spinning platters, often), their cleanup tooling is old, and the machines have had a decade to accumulate. The stakes of a wrong deletion are also higher, because recovery media and expertise are scarce.

Disk Cleanup, deep dive#

On Windows 7, cleanmgr is the center of gravity. Start → type “disk cleanup” → select C:. The initial view shows only per-user items and looks useless — a few hundred megabytes at best. The trick every Windows 7 owner should know is the Clean up system files button (labeled clean up system files in the description area of the dialog). It re-runs the tool with administrator privileges and reveals the categories that actually matter:

Windows Update Cleanup — installed updates that newer updates have superseded. On a machine that has been updating since 2011, this is frequently 3–10 GB. Removing them is safe in aggregate: you cannot uninstall the superseded updates individually afterward, but you should not need to. Caveat: this category appeared in Windows 7 SP1 via an update; a fully-patched SP1 machine has it.
Service Pack Backup Files — the rollback data for SP1 itself. Reclaiming it means SP1 can never be uninstalled, which is fine in 2026.
Previous Windows installation(s) / Temporary Windows installation files — present after an in-place upgrade, same semantics as on modern Windows.
Device driver packages — older versions of drivers Windows kept for rollback. Clearing them means no driver rollback beyond the current version.
Thumbnails, temporary files, Recycle Bin — the ordinary categories, same as ever.

Disk Cleanup’s estimate is honest but slow — it genuinely walks the directories. On a spinning disk it can take a minute or two; that is normal, not a hang.

WinSxS: the folder that scares everyone#

C:\Windows\WinSxS (Windows Side-by-Side) is the component store. Its purpose is genuinely elegant: rather than DLL hell — applications each shipping their own possibly-broken copy of msvcrt.dll — Windows keeps every version of every system component in one store, hardlinks them into place, and lets updates install new versions alongside old ones so that rollback and repair (System File Checker, for instance) can find any component version they need.

Three facts follow, and they defuse most of the folklore:

The size Explorer reports is a lie, in the safe direction. WinSxS is largely hardlinks: the same physical file counted many times because it appears both in the store and in C:\Windows\System32. The real unique footprint is substantially smaller than the folder’s “Size” line suggests.
You cannot safely delete anything in it by hand. The store is a database of relationships; deleting “old-looking” folders corrupts it, and the corruption surfaces weeks later as update failures or SFC errors that are miserable to diagnose. Every credible source says the same thing: never manually prune WinSxS.
There is a sanctioned cleaning tool, and it is excellent — the DISM component cleanup, covered in the next section. On Windows 7 SP1, the servicing stack update that enabled it was itself delivered via Windows Update.

So the Windows 7 recipe is: cleanmgr with system files enabled, then DISM component cleanup, then leave WinSxS alone forever.

Command-line techniques that work on every version#

The GUI is for one-offs; the command line is for doing this properly, repeatedly, or remotely.

cleanmgr /sageset and /sagerun: your saved preset#

Disk Cleanup supports scripted configurations. The flow is a one-time setup plus a repeatable run:

:: One-time: opens the dialog, remember your choices, click OK
cleanmgr /sageset:11

:: Every time after: runs silently with preset 11's choices
cleanmgr /sagerun:11

sageset:N opens a dialog listing every category, including system ones; tick exactly what you want automated, click OK, and the preset number N is stored in the registry. sagerun:N thereafter executes that exact selection with no dialog. The number is arbitrary — 1 through 65535 — but pick one you will remember, and note that different numbers hold different presets, so you can keep a “safe daily” preset and an “aggressive quarterly” one. This is how you put cleanup into Task Scheduler, a login script, or an RDP session on grandma’s machine.

One quirk worth knowing: /sagerun processes the settings for all volumes that had selections made, and some categories only appear in /sageset after the elevated system-files scan has run once. Configure it once interactively, verify the results, then trust it.

DISM component cleanup: shrinking WinSxS the sanctioned way#

Available on Windows 7 SP1+, 8.1, 10, and 11, this is the tool that makes WinSxS genuinely smaller:

:: Requires an elevated (Administrator) prompt

:: Analyze first — see how much is reclaimable, no changes made
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

:: Perform the cleanup — safe, online, no restart required (usually)
Dism.exe /Online /Cleanup-Image /StartComponentCleanup

:: The aggressive variant — also removes the version needed for
:: update UNINSTALL (not rollback of updates). Only run on a healthy,
:: recently-updated machine. Blocks for up to 60 minutes on first run.
Dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase

StartComponentCleanup removes superseded component versions — the ones no update or role still needs — typically reclaiming 2–10 GB on a long-lived install. It is safe: it walks the store’s own database and deletes only what has zero references. It is also slow — expect 10–30 minutes on an SSD, longer on Windows 7-era spinning disks, during which the DISM log grows and the machine may feel sluggish. Run it when you are not doing anything else.

/AnalyzeComponentStore is your friend: it reports the store’s actual size, whether cleanup is recommended (Windows itself says no when the projected savings are small), and the reclaimable estimate. Free reconnaissance before a slow operation — always take it.

/ResetBase deserves its own paragraph of caution. After running it, currently installed updates cannot be uninstalled individually — the files that make uninstallation possible are what it removes. It does not affect Windows.old or system restore (those are separate mechanisms), but it does trade future flexibility for present gigabytes. A reasonable policy: run plain StartComponentCleanup quarterly; reach for /ResetBase only on machines that are stable, fully updated, and disk-starved.

DNS cache, thumbnail cache, shader cache#

Three small caches that fix problems as often as they free space:

DNS cache rarely occupies meaningful space, but flushing it is the standard first move when name resolution misbehaves — a stale negative entry making a host appear unreachable:

ipconfig /flushdns

Instant, harmless, and fixes more “the network is broken” incidents than any other single command. Pair it with ipconfig /displaydns when you want to see what was cached before clearing it.

Thumbnail cache lives in %LOCALAPPDATA%\Microsoft\Windows\Explorer as thumbcache_*.db files. Windows locks them while Explorer runs, so the safe procedure is to stop Explorer first or use Disk Cleanup’s “Thumbnails” item, which handles the locking correctly. Deleting them frees a little space and — the usual actual reason — forces corrupted or stale icons to regenerate.

DirectX shader cache accumulates compiled GPU shaders per application (games especially). On modern Windows it is exposed in the Temporary files checklist; by path, it lives under %LOCALAPPDATA%\D3DSCache and, for individual applications, under folders like %LOCALAPPDATA%\NVIDIA or %LOCALAPPDATA%\AMD. Deleting it is safe — the cost is shader recompilation stutter on the next few launches of each game. It is the standard fix for graphical corruption after a GPU driver update, which is why it belongs in this guide: cache cleanup is maintenance and troubleshooting.

The do-not-delete list#

These files sit at C:\ root, are hidden by default, and are enormous. Every one of them has a correct way to manage, and no correct way involving Delete:

pagefile.sys — virtual memory backing. Windows moves cold memory pages here so physical RAM can serve hot ones. It is typically sized at a fraction of RAM, so on a 32 GB machine it may be 8–32 GB. Deleting it (it is locked while running anyway) just means Windows recreates it on reboot or runs without virtual memory — apps then fail with out-of-memory errors while RAM still shows free. Manage it properly instead: System → Advanced system settings → Performance → Settings → Advanced → Virtual memory, where you can move it to another drive or set a smaller custom size.
hiberfil.sys — hibernation backing, sized at a large fraction of RAM. This one has a legitimate, reversible off switch, and it is worth understanding the trade. Sleep keeps RAM powered and the machine in a low-draw state: fast to enter and wake, but loses state if power is cut. Hibernation writes RAM to disk and powers off completely: zero draw, survives power loss, wake takes a few seconds longer — and it needs hiberfil.sys to exist. On a laptop, hibernation is the battery-safe suspend and should stay. On a desktop that you shut down anyway, disabling it reclaims RAM-sized gigabytes:
```
:: Run as Administrator — disables hibernation, removes hiberfil.sys
powercfg /h off

:: Re-enable later if you want hibernate or Fast Startup back
powercfg /h on
```
One non-obvious side effect: Windows’ Fast Startup (the hybrid shutdown that makes boot feel instant) also uses hibernation machinery. powercfg /h off disables Fast Startup too — the honest trade is disk space versus boot speed, and only you can price those.
swapfile.sys — the small sibling of pagefile used by Store apps. Leave it alone; it is measured in megabytes.
WinSxS — covered above. Never prune by hand; DISM only.
System Volume Information — System Restore and shadow copies. Windows 7 era machines can have tens of GB here from a decade of restore points. Manage it via vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GB (elevated) or the System Protection dialog — not by deleting the folder, which is ACL-locked precisely to prevent that.

Developer caches: where the disk actually went#

The generic advice cleans the OS and finds 4 GB. Your actual problem is 60 GB of package managers. Every tool below maintains a cache that is safe to clear by design — they all re-download on demand — and all of them grow without limit if left alone.

npm#

# Verify before/after — npm reports cache size
npm cache verify

# Clear it entirely (npm 5+: safe, self-healing)
npm cache clean --force

npm’s cache lives at %LOCALAPPDATA%\npm-cache and routinely reaches 2–5 GB on an active JavaScript project. Corruption in it produces the famously cryptic ENOENT or integrity errors; clearing the cache is the canonical fix and costs only re-downloads. On machines with slow networks, weigh that: cache exists to make npm install fast on the second project that shares dependencies.

pip#

pip cache purge        # remove everything
pip cache info         # see location and size first
pip cache remove numpy # remove just one package's wheels

pip caches built wheels in %LOCALAPPDATA%\pip\cache. Because pip builds packages from source when no wheel matches your Python version, this cache prevents recompiling — clearing it on a Windows machine without build tools installed can turn a reinstall into a genuinely long afternoon. Prefer pip cache remove <pkg> for targeted cleanup.

NuGet#

:: All local caches (http, packages-cache, global-packages, temp)
nuget locals all -clear

:: Or just the global packages folder — the big one
nuget locals global-packages -clear

The global-packages folder (%USERPROFILE%\.nuget\packages) is the one that matters: every package every solution ever restored, kept forever, commonly 5–20 GB on a .NET developer’s machine. Clearing is safe — restore re-fetches on next build — but the smarter long-term answer is targeted: delete package directories for projects you have archived, and let active projects re-restore.

Gradle#

gradle --stop          # stop daemons holding file locks first

Then delete (or shrink) %USERPROFILE%\.gradle\caches. Gradle’s cache is versioned per Gradle release per dependency per variant — a machine with several projects on different Gradle versions multiplies everything. Deleting caches wholesale is safe but causes a full re-download of every dependency on next build, which on enterprise projects with private repositories can be substantial. A gentler lever: old Gradle distributions accumulate in %USERPROFILE%\.gradle\wrapper\dists — remove versions no project uses anymore.

Docker#

Docker Desktop’s disk footprint deserves its own warning label. Images, containers, and volumes live in a VM disk image — %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx under the WSL2 backend — and this file only grows. Deleting images inside Docker (docker system prune -a) frees space inside the VM, but the .vhdx on the Windows side does not shrink automatically:

# See what is consuming space inside
docker system df

# Remove stopped containers, dangling images, unused networks, build cache
docker system prune

# Also remove all unused images (aggressive — re-pull on next build)
docker system prune -a

After pruning, compact the VHDX: shut down Docker (wsl --shutdown), then use Optimize-VHD (Windows Pro with Hyper-V) or diskpart’s compact vdisk on the file. This routinely halves the file. It is the single highest-yield developer cleanup on Windows, and almost nobody knows the last step.

VS Code#

Three separate things accumulate: extension caches under %USERPROFILE%\.vscode\extensions (uninstall what you do not use — extensions are cheap to install and stack up for years), workspace storage under %APPDATA%\Code\User\workspaceStorage (one folder per workspace you have ever opened, containing caches and local history — safe to delete for deleted projects, and old workspaces’ entries are pure leftovers), and %APPDATA%\Code\Cache* (render caches, safe to clear, regenerated).

FAQ#

How often should I clean?#

Let automation carry the routine and reserve human effort for the quarterly deep pass. Concretely: Storage Sense (Windows 10/11) on a monthly cadence handles temp files and Recycle Bin forever; cleanmgr /sagerun on a Task Scheduler monthly trigger does the same for Windows 7/8; DISM component cleanup quarterly or after a feature update; Docker prune when docker system df crosses whatever threshold your disk can absorb. Cleaning weekly is a sign you are avoiding the real question, which is usually “why is this thing producing so much garbage” — and the answer is often one specific container, one specific node_modules convention, or Windows.old you never reclaimed.

Are cleanup utilities like CCleaner worth it?#

For a developer in 2026, mostly no. The case for them collapsed when Windows absorbed their feature set: Storage Sense plus Disk Cleanup plus Disk Cleanup’s system-files mode covers the registry of things CCleaner cleaned, without the risks third-party utilities carried — aggressive defaults that deleted things Windows still needed (the Windows.old mishandling era is legendary), the browser-cleaning feature that logged out of everything you were logged into, bundled offers, and the 2017 supply-chain incident that remains the industry’s canonical example of the category’s risk profile. Two genuine niches remain: uninstallers that also remove an application’s leftovers (useful for stubborn software), and on Windows 7, where built-in tooling is weakest. For everything else: the built-in path is safer, free, and already installed.

Should I wait until the C: drive is red before cleaning?#

No — red is late, not early. Several mechanisms quietly misbehave before the bar turns color: Windows Update needs staging space and fails when denied it; System Restore stops creating restore points below ~10% free; the pagefile cannot grow when needed; SSDs lose effective performance and endurance margin when nearly full. Treat 20% free as “comfortable”, 15% as “act soon”, 10% as “act now”. The entire point of Storage Sense and scheduled /sagerun is that cleanup happens on a schedule instead of in a crisis — crisis cleanup is exactly when people make bad decisions, including the deletions this guide spends a section warning against.

Does cleaning actually make Windows faster?#

Honestly: mostly no, and where yes, modestly. Deleting temp files does not speed up a healthy system — that belief is residue from the Windows XP era, when a bloated prefetch or a fragmented disk really did hurt. The modern performance cases are: an SSD above ~90% full (freeing space genuinely helps), a full system drive blocking updates (which then perform worse), and clearing a corrupted cache as a troubleshooting step (shader cache, DNS, npm). Clean up for space and for repair, not for speed — the speed folklore mostly sells utilities.

What about the Registry — should I “clean” it?#

No. Registry cleaners are a solution looking for a problem on any Windows after XP. The Registry is a few hundred megabytes at worst, so the space argument is nil, and the performance argument is folklore — Windows does not slow down because orphaned keys exist. Meanwhile the risk is real: a cleaner that deletes a key some installer still expects produces failures that are arbitrarily hard to trace back to the cause. Leave the Registry alone; the disk-space conversation does not need it.

Closing thoughts#

The durable mental model is that Windows disks fill for reasons that are mostly by design: caches exist because re-downloading is expensive, Windows.old exists because rollback is valuable, WinSxS exists because DLL hell was worse. Cleanup is not war against these mechanisms — it is working with their expiry conditions: let Storage Sense enforce the temp-file lifecycle, let cleanmgr presets automate the routine, let DISM do the WinSxS surgery it was built for, and never hand-delete the files that belong to the system (pagefile, hiberfil, WinSxS, System Volume Information) when each has a sanctioned lever.

And when you have done all of it and the disk is still tight: the honest answer for a developer is usually not in C:\Windows at all. It is in %USERPROFILE%\.nuget, %USERPROFILE%\.gradle, %LOCALAPPDATA%\Docker, and the fifteen node_modules folders across your projects. The OS cleans up after itself reasonably well these days. Our toolchains do not — that part is on us.

← All guides