Fixing a WSL2 Virtual Disk That Won't Shrink After Deleting Files

Deleting large files or directories from inside a WSL2 distro, then finding your Windows drive’s free space hasn’t increased at all, is expected dynamic-VHD behavior rather than a bug — the fix is a specific, direct compaction step.

Step 1: confirm the files are actually deleted inside the distro

df -h

Confirm the WSL-side filesystem itself shows the expected freed space from Linux’s own perspective — if it doesn’t, the deletion itself didn’t fully complete (check for a process still holding an open file handle to something you thought was deleted).

Step 2: locate the actual .vhdx file on the Windows side

Typically under:
%LocalAppData%\Packages\<DistroPackageName>\LocalState\ext4.vhdx

Each distro has its own separate .vhdx file — confirm you’re looking at the correct one for the specific distro where you freed up space.

Step 3: shut down WSL completely before attempting compaction

wsl --shutdown

The virtual disk file can’t be compacted while it’s actively mounted and in use by a running WSL2 VM — a full shutdown is a mandatory prerequisite, not an optional step.

Step 4: use diskpart to compact the virtual disk

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

This is the actual, direct fix — diskpart’s compact vdisk command specifically shrinks a dynamically-expanding virtual disk file’s physical size down to match its actual current content, reclaiming the space that simple file deletion inside WSL didn’t return.

Step 5: verify the file size actually decreased

Check the .vhdx file's properties in File Explorer,
  or its size via PowerShell, before and after compaction

Confirming the actual file size decreased verifies the compaction genuinely worked, rather than just assuming it did based on the command completing without an error message.

Step 6: restart your distro normally afterward

wsl -d <DistroName>

Launching your distro again after compaction confirms everything still works correctly — compaction shouldn’t affect the filesystem’s actual content, only the underlying virtual disk file’s physical size on the Windows side.

Step 7: consider making this a periodic maintenance step, not a one-time fix

For workflows that regularly generate and later delete large amounts of temporary data inside WSL (large builds, container images, sizable datasets), periodically repeating this compaction process — rather than only doing it once when you notice a space problem — keeps the .vhdx file’s size closer to actual current usage on an ongoing basis.

Step 8: consider a lower .wslconfig memory or disk-related setting only as a separate, unrelated concern

Note that .wslconfig’s memory setting controls RAM usage specifically and has no effect on this disk-space behavior at all — don’t confuse the separate memory-ceiling fix with this disk-compaction fix; they address entirely different resources.

Why this manual step is necessary rather than automatic

Dynamically-expanding virtual disk formats are specifically designed to grow readily but require an explicit compaction step to reclaim freed space — this is standard, expected behavior for this class of virtual disk technology, and understanding it prevents the confusing experience of file deletion inside WSL appearing to have no effect on your actual Windows drive space at all.