How WSL2's Virtual Disk Actually Grows (and Why It Won't Shrink on Its Own)
Each WSL2 distro's filesystem lives inside a dynamically-expanding .vhdx file on your Windows drive. It grows automatically as you use it — but deleting files inside WSL doesn't shrink it back down, and that's expected, not a bug.
Every WSL2 distro’s entire Linux filesystem lives inside a single .vhdx (Virtual Hard Disk) file on your Windows drive — understanding how that file actually grows, and specifically why it doesn’t shrink automatically, explains a genuinely common source of “where did my disk space go” confusion.
What a .vhdx file actually is here
VHDX is a Microsoft virtual disk image format, the same general technology Hyper-V uses for full virtual machines — for WSL2, each installed distro gets its own .vhdx file (typically under %LocalAppData%\Packages\...) that Linux, running inside the WSL2 VM, sees and formats as a normal ext4 filesystem.
Why it starts small and grows automatically
WSL2’s .vhdx files use dynamic expansion — the file starts small and grows on disk as you actually write data inside the Linux filesystem, rather than pre-allocating its maximum possible size upfront. This means a fresh distro install consumes relatively little actual disk space on the Windows side, growing only as you genuinely use it.
The part that surprises people: it doesn’t shrink back automatically
Deleting a large file, or an entire directory, from inside your WSL distro frees that space within the ext4 filesystem inside the virtual disk — but the underlying .vhdx file on the Windows side generally does not automatically shrink back down to reflect that freed space. The virtual disk’s on-disk file size reflects its historical peak usage, not its current actual content size.
Why this isn’t a bug, just how dynamic VHD expansion works
Dynamically expanding virtual disk formats generally grow readily but require an explicit, deliberate compaction step to reclaim space after deletions — this is standard behavior for this class of virtual disk technology generally, not a WSL-specific oversight, and the same general behavior shows up in other VHD/VHDX-based virtualization contexts too.
What compaction actually requires
Reclaiming that unused space requires an explicit compaction operation using Windows’s own diskpart utility (or newer, more convenient WSL-specific tooling), specifically telling the underlying virtual disk format to shrink its physical file size down to match its actual current content — the exact steps for this are covered in this blog’s dedicated how-to guide.
Why this matters especially for large, transient data
Workflows that temporarily generate a large amount of data inside a WSL distro — building large projects, working with sizable datasets, container images pulled and later removed — can leave the .vhdx file substantially larger than the distro’s actual current content for a long time afterward, unless compaction is performed deliberately.
Why understanding this prevents a common, confusing troubleshooting dead-end
Without understanding this dynamic-expansion-without-auto-shrink behavior, “my C: drive is nearly full, but WSL’s actual files don’t add up to that much space” looks like a mystery — once you know the .vhdx file’s on-disk size reflects historical peak usage rather than current content, the actual fix (compaction, not searching Linux-side for phantom files) becomes obvious.