Win32 Disk Imager Select a disk image file picker for SD card backup

Win32 Disk Imager Not Enough Space on Disk: Fixes (2026)

by

“Not enough space on the disk” is the Win32 Disk Imager error that makes people stare at their 32 GB SD card and wonder if Windows has lost its mind. Your IMG is 8 GB. Your SD card is 32 GB. It should obviously fit. But Win32 Disk Imager refuses to write, popping up “There is not enough space on the disk” or similar. The math doesn’t add up from the user’s perspective, which is why this error confuses so many people.

Here’s what’s actually happening: Win32 Disk Imager’s space check isn’t comparing the IMG file size to the SD card capacity. It’s comparing the IMG’s original partition layout (including any unused space beyond what’s actually used) against the card’s raw capacity. If your IMG was made from a 32.1 GB card but the target is a 32.0 GB card, even a 0.1 GB difference triggers the error. I’ve been debugging this error for years and there are five distinct root causes, each with a specific fix. This article walks through all five.

TL;DR: Target SD is physically smaller than source. Shrink the IMG with PiShrink (for Pi images) or manually resize the partitions inside the IMG, then retry. Or buy a larger destination SD. Or for Read operations, free up space on your Windows destination drive.

Understanding the Error

The exact error text varies:

  • “Not enough space on disk to write”
  • “There is not enough free space on the disk”
  • “Disk full”
  • “The image file is larger than the target device”

All of these boil down to: Win32 Disk Imager’s source data won’t fit in the destination. The question is which side of the transaction is actually insufficient.

For Write operations (IMG → SD card), the error means the IMG’s effective size is bigger than the SD card’s capacity. For Read operations (SD card → IMG), it means your Windows destination drive (usually C:) doesn’t have enough free space to hold the output file.

Cause 1: SD Cards Aren’t Actually the Advertised Size

The most common cause. SD card manufacturers use decimal math (1 GB = 1,000,000,000 bytes). Operating systems use binary (1 GiB = 1,073,741,824 bytes). A “32 GB” SD card has ~31.9 billion bytes, which Windows reports as ~29.7 GiB. Effective capacity ~29.7 GB in OS terms.

Worse, the effective usable space depends on the specific manufacturer and batch. Two “32 GB” cards from different manufacturers can differ by 100-500 MB. I’ve seen SanDisk 32 GB cards at 31.7 GB usable and Samsung 32 GB cards at 31.9 GB usable.

If your source IMG was made from a SanDisk 32 GB card but you’re writing to a Samsung 32 GB card, and the Samsung is 200 MB smaller, you get “not enough space” even though both are labeled “32 GB.”

Cause 2: Source IMG Is Exactly Full of Data

Related to Cause 1. If you made a full-disk IMG backup (no Read Only Allocated Partitions, just raw Read), the IMG is the full size of the source card, 32 GB exactly.

That IMG won’t fit on any card that’s not at least 32 GB raw capacity. Since SD card sizes vary (Cause 1), destination cards labeled 32 GB may be slightly smaller.

The fix: shrink the IMG so it fits on the smallest reasonable destination.

Cause 3: Destination SD Is Damaged / Reports Wrong Capacity

Counterfeit or failing SD cards often have flash-memory wear that reduces usable capacity, or (in the counterfeit case) actually have smaller physical storage than labeled. A “128 GB” counterfeit card may actually be 8 GB of real storage that wraps around when you write past 8 GB, appearing as 128 GB to File Explorer but silently dropping data.

Test your card with h2testw (free, heise.de/download/product/h2testw-50312). It writes patterns to every sector, reads them back, and reports any mismatches. Real 128 GB card: all 128 GB verifies. Counterfeit: you’ll see warnings after the first few GB.

If h2testw confirms the card is real, it’s not the cause. Move to other fixes. If counterfeit, return and buy from a reputable vendor.

Cause 4: Image Contains Extra Partitions You Didn’t Know About

Some Pi OS images have hidden recovery partitions or overflow space that pushes the total IMG size beyond the nominal data size. Image from a 32 GB card with a recovery partition reserved might be 32.5 GB, which won’t fit on ANY 32 GB card from any manufacturer.

To verify: open the .img file’s properties. File size is the exact byte count. Compare to your destination card’s exact byte count (right-click drive → Properties in File Explorer).

If IMG > card size by even 1 byte: won’t fit. Shrink or use bigger card.

Cause 5: Windows Destination Is Full (for Read Operations)

If you’re doing Read (SD → IMG), the error refers to your Windows destination drive, not the SD card. Check:

  • The drive containing your Image File output path (usually C: or D:).
  • Free space on that drive via File Explorer Properties.

If the target drive has less free space than the SD card’s full capacity, Win32 Disk Imager refuses to start. Even with “Read Only Allocated Partitions” ticked, the tool over-estimates the space needed.

Fix: free up space on C: (or wherever), or write the IMG to an external drive with more free space.

Fix 1: Shrink the IMG with PiShrink

For Raspberry Pi IMG files, the gold-standard fix. PiShrink resizes the IMG’s partitions to the minimum size that fits the data, then sets a flag to auto-expand on first boot. Requires Linux or WSL.

On WSL2 (easiest for Windows users):

wsl --install  # if not installed yet
wsl
sudo apt update
sudo apt install e2fsprogs parted
wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
chmod +x pishrink.sh
sudo ./pishrink.sh /mnt/d/backups/pi.img

Runs in 1-5 minutes depending on IMG size. Output: pi.img is now smaller, typically 30-70% of original.

Back in Windows: Win32 Disk Imager the shrunken IMG onto your destination SD. Should fit now.

On first boot, the Pi’s resize-script auto-expands the root filesystem to fill the destination card.

Fix 2: Manually Resize Partitions in the IMG

For non-Pi images or when PiShrink doesn’t work. More complicated but universally applicable.

On Linux / WSL:

# Loop-mount the IMG
sudo losetup -P /dev/loop0 pi.img

# Check current partition layout
sudo fdisk -l /dev/loop0

# Check filesystem usage
sudo e2fsck -f /dev/loop0p2
sudo resize2fs -M /dev/loop0p2  # shrink to minimum

# Resize the partition to match
sudo parted /dev/loop0 resizepart 2 8G

# Truncate the IMG file
truncate --size=8G pi.img

# Detach
sudo losetup -d /dev/loop0

Specific values depend on your actual data size. This is where PiShrink’s automation is much nicer, it handles the calculations for you.

Fix 3: Use a Bigger Destination SD Card

Simplest solution if buying a new card is acceptable. If source was 32 GB, buy 64 GB destination. The IMG fits easily, and the Pi’s first-boot auto-expand fills the remaining 32 GB with partition space.

Costs: $10-15 for a 64 GB A1-rated SD card from SanDisk or Samsung in 2026. Not bad given the time this saves you.

Actually, I recommend this for most users. Shrinking IMGs is a skill worth learning for bulk archival, but for a one-off “won’t fit” problem, just buy the bigger card.

Fix 4: Free Up Windows Destination Space (Read Operations)

If the error appears during Read (making a backup IMG), your Windows destination drive is full. Options:

  • Delete files. Empty Recycle Bin, delete Downloads you don’t need, clear Windows.old folder.
  • Move the Image File path to a drive with more space. Plug in an external SSD, set destination to F:\pi-backup.img.
  • Use Storage Sense. Settings → System → Storage → Storage Sense. Auto-clean temp files.
  • Disk Cleanup (admin). Type “Disk Cleanup” in Start, right-click → Run as administrator. Clean system files, can free 5-15 GB on a mature install.

Target: at least 2x the SD card’s capacity in free space on the Windows destination drive. 32 GB source card = ensure 64 GB free on C: (or wherever) before starting Read.

Fix 5: Try 7-Zip Compression for Storage, Then Restore

If you have the IMG but it’s too big for the destination card, and can’t easily shrink with PiShrink (non-Pi image), a partial workaround: write the IMG to a bigger temporary card, boot the Pi once, let any auto-expand/setup happen, then use SD Card Copier (on-Pi) or dd with smaller block sizes to migrate to the intended smaller card.

Workaround chain: IMG → bigger SD → boot → SD Card Copier → smaller SD. Takes longer but avoids modifying the IMG.

Alternative: if you just need to store the IMG compactly, 7-Zip it. pi.img at 8 GB compresses to ~2 GB as pi.img.7z. For long-term storage or transfer. But you’ll need to decompress before flashing.

Decision Tree

You’re seeing “Not enough space” in Win32 Disk Imager. Which fix?

  1. Is this a Write (IMG → SD) or Read (SD → IMG) operation?

If Write:

  1. Check IMG file size vs destination SD card byte count. If IMG > card, shrink IMG (Fix 1 for Pi images, Fix 2 for others) or use bigger card (Fix 3).
  2. If sizes are similar but still doesn’t fit, test SD card with h2testw for counterfeit / damage (Cause 3). Replace if fake.

If Read:

  1. Check free space on the Windows drive holding Image File output path.
  2. Free up space (Fix 4) or change path to a drive with more space.
  3. If still failing despite abundant space, try “Read Only Allocated Partitions” checkbox to reduce output size.

95% of cases resolve here. If not, the SD card or USB reader is probably failing, try different hardware.

Preventing the Error in the Future

Habits that avoid this error entirely:

  • Always use “Read Only Allocated Partitions” when making IMG backups. Produces smaller IMGs that fit more destinations.
  • PiShrink every IMG before archival. Adds 2 minutes but saves hours of troubleshooting later.
  • Buy consistent SD card brands for sets. If all your cards are SanDisk Ultra 32 GB, they’re the same size. Mixing brands introduces variance.
  • Keep 100+ GB free on C: so Read operations always have room.
  • Buy slightly bigger destination cards than source for any migration. 64 GB source to 128 GB destination is safer than 32 GB to 32 GB.

When It’s Not Actually a Space Problem

Sometimes Win32 Disk Imager says “Not enough space” but there’s plenty of space. Possible alternative causes:

  • Write-protected destination. SD card lock switch flipped. “Not enough space” is sometimes the generic error, real cause is write-protection. Check the physical lock slider.
  • Sector-size mismatch. Unusual but seen on some industrial SD cards, the card uses 4096-byte sectors instead of 512-byte. Win32 Disk Imager’s size calculation gets confused. Workaround: use a different, standard SD card.
  • Damaged partition table on destination. If the destination has weird metadata, Win32DI may compute wrong capacity. Format the destination fresh (FAT32 or NTFS) via Windows Format dialog, then retry Win32 Disk Imager.
  • Controlled Folder Access blocking the write mid-operation. Not really “not enough space” but the error sometimes surfaces that way. See our Error 5 fix guide for CFA whitelisting.

The Underlying Math (For the Curious)

Why do SD card sizes vary so much for the “same” capacity? Three layers of math:

Layer 1: Decimal vs binary. Manufacturers sell “32 GB” = 32 billion bytes. Operating systems measure in binary, 32 GiB = 34.36 billion bytes. A “32 GB” card only has 29.8 GiB of space from the OS’s perspective. This is a fixed ~7% difference.

Layer 2: Over-provisioning. NAND flash cells wear out with writes. Manufacturers reserve 1-10% of the card’s physical storage as spare pool, used to replace failing cells automatically. A “32 GB” Samsung Pro Endurance card might have 35 GB of physical flash with 3 GB reserved. A bargain 32 GB card might have 32.1 GB physical with 0.1 GB reserved. More reserve = longer card life but smaller usable space.

Layer 3: Filesystem overhead. NTFS reserves 12.5% of volume for MFT by default. FAT32 uses cluster sizes that waste some space. ext4 reserves 5% for root. These further reduce effective usable space once formatted.

Net result: a “32 GB” card’s real-world usable space is anywhere from 28.5 GB to 29.8 GB depending on brand. When your IMG was made from a 29.8 GB card and you’re trying to write it to a 28.5 GB card, “not enough space” is the accurate error.

FAQ

Why doesn’t Win32 Disk Imager just truncate the IMG to fit?

Because truncating a disk image without resizing the partition table inside it produces a broken image, the Pi wouldn’t boot, the filesystem would be corrupted. Win32 Disk Imager refuses rather than corrupt your data. Shrinking properly requires parsing the filesystem inside the IMG, which is what PiShrink does.

My IMG is 6 GB, my SD is 32 GB. Why does it say “not enough space”?

Check if the IMG’s partition table claims more space than the file’s byte count. Sometimes IMGs made by dd have been truncated but the GPT header still references the original size. The error is Win32 Disk Imager reading the partition table, not the file size. Re-read the IMG with “Read Only Allocated Partitions” to generate a properly-sized IMG.

Does this error mean my SD card is bad?

Not necessarily. It usually means size mismatch, not hardware failure. But if h2testw shows the card has less than advertised usable space, yes, it’s bad or counterfeit.

Can I ignore this error and force the write?

Win32 Disk Imager doesn’t have a force option. You could use Linux dd with conv=sync,notrunc to force a partial write, but the resulting SD card won’t boot (partition table corrupted). Don’t do this.

How do I check the exact byte size of my SD card?

File Explorer → right-click the SD card drive → Properties. The “Capacity” line shows exact bytes. Compare that to the IMG file’s size (right-click IMG → Properties → size in bytes).

Does this error happen on Rufus or balenaEtcher too?

Yes, same cause (IMG > destination), same error from different tools. The fix is identical: shrink IMG or use bigger destination. See our Rufus comparison for tool differences.

Is there a way to skip empty space in IMG when writing?

Win32 Disk Imager doesn’t do sparse-write. Writes every byte of the IMG regardless of whether it’s data or zeroes. To avoid writing empty space, shrink the IMG first with PiShrink.

My Image File is on a network drive — does that cause “not enough space”?

Shouldn’t. Win32 Disk Imager reads from anywhere accessible to Windows. But network latency can cause timeouts that look like space errors. Copy the IMG locally first, then point Win32DI at the local copy.

Does Windows’ exFAT vs NTFS affect this error?

No. Win32 Disk Imager writes raw bytes, doesn’t care about filesystems. The error is about raw capacity.

Can I use a USB SSD as destination instead of SD?

Yes, and SSDs typically have more consistent sizing across manufacturers (less variance than SD cards). Solves Cause 1 if you’re flashing for Pi 4/5 which supports USB boot.

How do I know if PiShrink worked correctly?

PiShrink outputs a summary: “Shrunk to X MB.” Compare to original size. New file size should be smaller. Also verify the shrunk IMG has resize-on-first-boot enabled: mount it in Linux, check for /etc/rc.local containing resize commands. PiShrink sets this automatically.

Will shrinking the IMG affect the data inside it?

No. PiShrink only resizes the filesystem to the minimum that fits the data; all files inside are preserved. After flashing and booting on the destination card, the filesystem auto-expands, and you have exactly the same data as before, just fitting in a smaller partition initially.

Wrapping Up

“Not enough space” is almost never about disk space and almost always about IMG-versus-destination size mismatch. Shrink the IMG, buy a bigger card, or free up space on your Windows destination, five minutes of work saves hours of confusion. For the broader Win32 Disk Imager workflows around backup and restore, our backup guide and restore guide cover the full end-to-end pipeline.

Related Guides

Pair this guide with the rest of the Win32 Disk Imager knowledge base. These cover the adjacent workflows you’ll hit when working with disk images, bootable USBs, and Windows partition management.