A file can report 60 GB and occupy 12, and Explorer will not say which

A sparse file tells the file system that large parts of it are empty, and those parts occupy nothing until something is written there. It is the right design and it makes every size measurement ambiguous.

Where you meet them

• WSL distributions. ext4.vhdx grows as the guest writes and never shrinks.
• Docker Desktop. The same mechanism, the same folder shape.
• Hyper V virtual machines. Dynamically expanding disks are sparse by definition.
• Databases and download managers. Anything that preallocates a large file and fills it gradually.

Seeing the real size

fsutil sparse queryflag "C:\path\to\file.vhdx"
Get-Item "C:\path\to\file.vhdx" | Select-Object Length,
  @{n='OnDiskGB';e={[math]::Round((Get-Item $_.FullName).Length/1GB,2)}}
# Explorer's Size on disk is the honest figure for these
# compact a WSL or Hyper-V disk after shutting it down
Optimize-VHD -Path "C:\path\to\file.vhdx" -Mode Full

Optimize-VHD needs the Hyper V module and the disk detached. For WSL the supported route is wsl --shutdown followed by compaction, covered in WSL disks.

Why deleting inside does nothing outside

Free space inside the guest filesystem is still allocated to the host file. The guest knows those blocks are free; Windows does not, because nothing told it. Compaction is the step that returns them, and it only works after the guest has been shut down cleanly.

Which tools get it wrong

Anything that sums reported file lengths overstates a folder containing virtual disks, sometimes by a factor of five. Explorer's Size on disk column is correct for these, and is the one to read. That is the same distinction as size against size on disk generally, with a much larger gap.