You can switch to Linux without losing your Windows workflow using WSL. However, one issue with WSL I've found is that its virtual disk does not automatically free up unused space, which is also why your WSL distro is probably using far more Windows storage than you think.

The good news is you can reclaim that wasted space by manually compacting WSL virtual hard disks using DiskPart, a built-in Windows tool. And if you'd rather not do the manual work every time, a PowerShell script can automate the entire process so you never have to think about it again.

Why your WSL virtual disk never shrinks on its own

WSL only knows how to grow, not how to give space back

file manager window displaying ed4 vhdx and ubuntu shortcut files

Every WSL 2 distro you install gets its own virtual hard disk, stored on your Windows drive as an ext4.vhdx file. These are dynamically expanding disks: they grow as you add files, but that growth only goes one way. When you delete a file inside your Linux distro, WSL frees up the space inside the virtual disk, but Windows never gets told to shrink the .vhdx file to match. The blocks that file used to occupy are marked as empty and left sitting there, still counted against your Windows drive.

The tricky part is that everything looks fine from inside WSL. Run df -h in your distro, and you'll see plenty of free space, because Linux considers the deleted files gone. The problem only shows up on the Windows side, where ext4.vhdx keeps taking up however much room it ever grew to. If you're a heavy WSL user pulling Docker images, installing and removing packages, or cloning and deleting repos, the gap between "space used inside Linux" and "space reserved on Windows" can add up to many gigabytes over time.

Windows gives no warning or tells you that a specific distro's virtual disk has ballooned. The only way to know is to go looking for the file yourself.

How to find out how much space your distro is really using

Confirm your WSL version, then track down the virtual disk file

Before you can reclaim any space, you need two things: confirmation that you're running WSL 2 (compaction only applies there), and the file path to your distro's virtual disk. Open PowerShell or Command Prompt as Administrator and run:

wsl --status

This tells you the WSL client version and whether your default distro is on WSL 2. If you have more than one distro installed, run wsl.exe --list --verbose to see every distro and which WSL version each one is using. Anything showing Version 2 is a candidate for compaction.

Next, find where Windows stores the virtual disk. Each distro's files live in a registry key, and you can pull the path with this PowerShell snippet:

(Get-ChildItem `
-Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss `
| Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu' } `
| Get-ItemProperty `
| Select-Object -First 1).BasePath + "\ext4.vhdx"

Replace Ubuntu with the exact name from the --list --verbose output. This builds the full path to the virtual disk file, usually something like C:\Users\\AppData\Local\Packages\...\ext4.vhdx. Once you have it, check the file's size in File Explorer or with Get-Item to see how bloated it has gotten. You'll need this path in the next step.

How to reclaim that space with DiskPart

Shut down WSL, attach the disk read-only, and compact it

windows powershell diskpart utility compacting virtual disk file

Once you have the path to your distro's ext4.vhdx file, the process comes down to five commands. First, shut down WSL completely since DiskPart can't touch the virtual disk while it's in use:

wsl.exe --shutdown

Then launch DiskPart from the same admin window and point it at your virtual disk:

diskpart
select vdisk file="C:\Users\username\AppData\path\to\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

A couple of things worth knowing here. Attaching the disk in read-only mode matters because compaction only needs to scan which blocks are empty, not write anything to the Linux filesystem. Read-only guarantees DiskPart can't alter your distro's files while it works. And don't skip the detach vdisk step, even though compaction is already done at that point. Skipping it leaves the file locked, which will block WSL from accessing it again until you reboot.

The compact vdisk step can take a few minutes depending on how bloated the file has gotten, so wait for the "DiskPart successfully compacted the virtual disk file" message before moving on. Once it's done, relaunch your distro with wsl -d YOURDISTRONAME and run df -h to confirm everything still works. On the Windows side, you should see the .vhdx file is noticeably smaller.

Automate it so you never have to think about it again

A PowerShell script handles the whole process for you

wsl vhdx optimizer github repository main page

Doing the DiskPart cleanup by hand every time your .vhdx file balloons can be tedious. WSL-VHDX-Optimizer is a PowerShell script built around this exact problem. Start by cloning or downloading the repo, then run a read-only check first to see how much space is recoverable:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Optimize-WslDisk.ps1 -Inventory

This gives you a size report across your installed distros without touching anything. When you're ready to reclaim space, run the script from an elevated prompt:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Optimize-WslDisk.ps1

Under the hood, the script finds your distros via the registry, runs fstrim inside each one to mark freed blocks, shuts down WSL, and compacts each virtual disk using either Hyper-V or DiskPart as the backend. It then reports the real space recovered based on actual file allocation, not just the logical size Windows reports.

A few useful parameters: -Distro targets specific distros instead of all of them, -Engine Auto|HyperV|DiskPart controls which compaction method it uses, and -WhatIf previews what would happen without making changes.

One thing worth noting: the tool's documentation recommends against blind, scheduled runs. It suggests triggering it after events that leave a lot of freed space behind, like pruning Docker containers or doing a big package cleanup, rather than running it on autopilot. That's because compaction can occasionally increase a disk's size instead of shrinking it, so it's not risk-free to fire unattended.

Reclaiming your storage space from WSL virtual disks

In my case, compacting brought my Ubuntu distro's .vhdx file down from around 100 GB to roughly 15 GB. That's a significant amount of space to silently lose on a drive, especially if you're working with a smaller SSD where every gigabyte counts. Your results will depend on how much cruft has built up, but if you've been running WSL for any length of time, the difference is likely to be more than you expect.

Just to be safe, I'd recommend backing up your distro before running the compaction for the first time. But in my experience, the process hasn't caused any data issues. If you're regularly cleaning up unnecessary Windows files and folders to free disk space, adding WSL compaction to your routine is worth the effort, especially since Windows will never do it for you.