You run Win32 Disk Imager Read on your Raspberry Pi SD card. The card has maybe 6 GB of actual data on it (Pi OS + configs + Docker images + some logs). You expect a 6 GB backup file. Win32 Disk Imager produces a 32 GB IMG. What gives? Why is the backup 5x bigger than the data?
This confuses a lot of people and wastes a lot of disk space. The answer is that Win32 Disk Imager does byte-for-byte copying, including empty space. It doesn’t understand filesystems, partitions, or which blocks are “used.” It just copies every sector of the source drive to the IMG file. Most SD cards are 32+ GB these days, so backup IMGs default to 32+ GB regardless of how much data is on them. This article explains why, when it matters, and how to get compact backups when you need them.
TL;DR: Full-read IMG = source drive size exactly. Use “Read Only Allocated Partitions” checkbox to reduce to the largest-allocated-partition size (~30% savings). Use PiShrink after Read for filesystem-aware shrink (60-80% savings). Compress with xz/7-Zip for another 2-4x reduction for archival.
Why Win32 Disk Imager Behaves This Way
Win32 Disk Imager’s design is intentionally filesystem-agnostic. It doesn’t look inside the IMG to understand what’s data and what’s empty. It just copies raw sectors from one place to another.
Why design it this way? Three reasons:
1. Universality. Works with any filesystem (ext4, NTFS, FAT32, exFAT, HFS+, Btrfs, custom embedded formats, or no filesystem at all). A filesystem-aware tool would need to understand each format.
2. Byte-perfect preservation. Includes boot sectors, partition tables, hidden sectors, GPT metadata, everything. A filesystem-aware tool might skip “unused” metadata that’s actually critical for booting.
3. Simplicity. Raw copy is a few hundred lines of C++ code. Filesystem-aware cloning is tens of thousands.
Tradeoff: backup files are bigger than they need to be. That’s the cost of being universal and byte-perfect.
The Numbers
Real-world backup sizes for a typical Pi setup:
| Source | Actual data | Full IMG size | With “Read Only Allocated” | After PiShrink | After PiShrink + xz |
|---|---|---|---|---|---|
| 32 GB SD, Pi OS Lite fresh | 2 GB | 32 GB | ~8 GB | ~2.5 GB | ~700 MB |
| 32 GB SD, Pi OS with Home Assistant | 6 GB | 32 GB | ~28 GB (partition spans most of card) | ~7 GB | ~2 GB |
| 64 GB SD, OctoPrint + ROMs | 15 GB | 64 GB | ~60 GB | ~16 GB | ~5 GB |
| 16 GB USB stick, fresh Ubuntu | 5 GB | 16 GB | ~15 GB | N/A (not ext4) | ~3 GB |
Patterns: default Full Read is huge. “Read Only Allocated” helps if there’s unused space beyond the last partition. PiShrink is the biggest single reduction (Pi-specific). xz compression stacks on top.
“Read Only Allocated Partitions” Explained
The checkbox in Win32 Disk Imager’s main UI (next to the progress bar). When ticked, Read stops copying at the end of the last partition, not the end of the drive.
For a 32 GB card with partitions totaling 8 GB: IMG is 8 GB instead of 32 GB. Saves 24 GB.
For a 32 GB card with a 30 GB partition: IMG is 30 GB instead of 32 GB. Saves only 2 GB.
Limitation: doesn’t shrink the partition itself. If the 30 GB partition has only 6 GB of data inside, the IMG is still 30 GB because that’s the partition’s allocated size.
Use always: no downside to ticking it (unless you have a very specific reason to want empty sectors in the backup).
The PiShrink Solution
The real solution for big backups: PiShrink. Runs on Linux (or WSL). Shrinks the partition inside the IMG to the minimum that fits the actual data.
Workflow: Win32 Disk Imager Read (even with Allocated Partitions off), then run PiShrink on the IMG. Result: IMG shrinks to ~data-size + 5-10% overhead.
The 32 GB → 7 GB reduction is typical. On a 12-month archive, that’s 300 GB saved on NAS storage.
Limitation: PiShrink only works on Pi OS images (ext4 root partition). Won’t shrink NTFS, FAT32, or non-Pi images. For non-Pi workflows, compression (7-Zip, xz) is the only reduction option.
See our PiShrink guide for the full setup and workflow.
Compression Options
After (or instead of) PiShrink, compress the IMG:
xz (LZMA2): best ratio. 8 GB IMG → ~2 GB .xz. Slow decompression (~1-2 min). Standard for Pi OS distribution.
7z (7-Zip’s native): similar ratio to xz. Faster decompression. Windows-friendly.
gzip: faster compression + decompression, worse ratio. 8 GB IMG → ~3.5 GB .gz.
zstandard (zstd): modern alternative. Fast compression, decent ratio. 8 GB → ~2.5 GB. Requires newer tools.
Pick by use case: xz for long-term archival (size matters), 7z for Windows-interoperability, zstd for speed.
Why the Default Is “Full Read”
Philosophical question: why doesn’t Win32 Disk Imager default to “Read Only Allocated Partitions”?
Historical: the checkbox was added in 0.9.5 (2012). Before that, full-read was the only option. Changing the default would have broken expectations.
Technical: there are rare cases where “Read Only Allocated” produces an incomplete backup. Some Pi distributions have data or metadata in the “empty” space past the last formal partition. Rare, but exists.
Practical: most backup workflows benefit from the checkbox being ticked, and it’s 2 clicks to enable. Not worth the compatibility risk of changing the default.
Why Modern Pi OS Uses Full Partition
The Pi OS auto-expand script (runs on first boot) grows the root partition to fill the SD card. This means:
- Fresh 32 GB card: after first boot, root partition is ~29.8 GB.
- “Read Only Allocated Partitions” on this card produces a ~30 GB IMG.
- The 6 GB of actual files sit inside this 29.8 GB partition, with the rest being empty filesystem space.
If you boot a Pi without auto-expand (some Lite images), root stays small (~2-3 GB partition on a 32 GB card). Then Allocated Partitions gives a much smaller IMG.
Can you prevent auto-expand? Yes, delete the resize flag from /etc before first boot. But practically, you want Pi OS to use the full card for storage growth. Accept the large IMGs and use PiShrink for archival.
The Virtual vs Physical Size Gotcha
One confusion: “SD card is 32 GB” but Win32 Disk Imager produces a 29.8 GB IMG. Why not exactly 32 GB?
Manufacturer GB vs operating system GiB. Covered in our Not Enough Space guide. A “32 GB” card is 32 decimal billion bytes ≈ 29.8 binary GiB. Win32DI reports the latter.
The IMG is the card’s actual physical byte count, not the marketing capacity. Normal and expected.
Data vs Partition vs Drive Size
Three size concepts that confuse people:
Data size: the actual bytes of files you’ve saved. Pi OS installation + your configs + Docker images = maybe 6 GB of real data.
Partition size: how big the filesystem container is. Pi OS auto-expands the root partition to fill the SD card, so it’s often the full card size (~29.8 GiB on a 32 GB card). This is what “Read Only Allocated Partitions” measures.
Drive size: physical capacity of the SD card (32 GB marketing = 29.8 GiB OS-reported). This is what “Full Read” copies.
Relationship: Data ≤ Partition ≤ Drive. Typical Pi: 6 GB data in a 29.8 GB partition on a 32 GB drive.
Backup tools address each layer:
- Win32DI Full Read copies the entire drive (29.8 GiB IMG).
- Allocated Partitions stops at end-of-last-partition (usually same ~29.8 GiB if auto-expanded).
- PiShrink shrinks partition to fit data (IMG becomes ~7 GB).
- Compression further reduces (IMG.xz becomes ~2 GB).
Understanding these three layers explains everything about IMG sizes.
Sparse Files: A Missed Opportunity
Some filesystems support “sparse” files: a file that’s logically 32 GB but physically stores only the non-zero bytes. NTFS, ext4, and APFS support sparse files.
In theory, Win32 Disk Imager could write IMGs as sparse files, allocating only for the non-zero (non-empty) bytes. A 32 GB IMG with 6 GB of actual data would take only 6 GB of disk space.
In practice, Win32 Disk Imager doesn’t do this. The IMG is written as a dense (full-size) file. When you copy it to another disk, the full size gets transferred.
Workaround: use Linux dd with conv=sparse to produce sparse output: dd if=/dev/sdX of=pi.img conv=sparse bs=4M. The IMG is sparse on ext4 filesystems. Copy to non-sparse destinations (FAT32, some NAS setups) converts to dense.
Minor win, complicates archival. Most users skip the sparse trick.
Workflow Recommendations By Use Case
Daily Pi backup to NAS (storage-conscious): Win32 Disk Imager Read with Allocated Partitions → PiShrink → xz compression. Maximum space efficiency.
Quick one-off backup before a risky change: Win32 Disk Imager Read with Allocated Partitions. Skip PiShrink to save time. Acceptable temporary size.
Distributing a pre-configured image: Win32DI Read → PiShrink → xz. Users download smaller archive, flash, Pi auto-expands.
Forensic backup (byte-perfect required): Full read (uncheck Allocated Partitions). Preserves empty-sector data which may be forensically relevant.
Archiving old projects (rarely accessed): Full workflow (Read → PiShrink → xz) for minimum storage footprint.
Emergency restore work (speed matters): Pre-PiShrunk IMGs on fast SSD storage. Skip the compression step for fastest restore times.
Backup Size Math Quiz
Quick reality check. Given:
- 32 GB SD card (Pi OS + Docker, 12 GB actual data).
- Full Read: 29.8 GB IMG.
- Read with Allocated Partitions: depends on partition sizes. If root partition is 30 GB, IMG is ~30 GB. If root is 14 GB, IMG is ~14 GB.
- PiShrink applied to the Allocated-Partitions-read IMG: reduces to ~13 GB (12 GB data + minor overhead).
- xz compression on the shrunk IMG: ~3.5 GB.
- Long-term archive: 3.5 GB per backup. Vs 29.8 GB for naive full-Read. 8.5x smaller.
Over 24 months of monthly backups: ~85 GB vs ~720 GB. The compression work pays off.
Compression Tradeoffs
Compressing IMGs has costs:
Time to compress: xz -9 takes 3-10 min on a modern CPU for a 10 GB IMG. 7z similar. gzip faster (1-2 min) but worse ratio.
Time to decompress for restore: xz decompress is fast (1-2 min). Slower on old hardware.
Can’t flash directly: Pi Imager and balenaEtcher can decompress-on-fly (.img.xz support), but Win32 Disk Imager needs raw .img. Extra step if restoring with Win32DI.
Corruption propagation: if the .xz file bit-rots, decompression may fail entirely (small corruption breaks the whole file). Raw .img can survive minor corruption with only localized data loss.
For long-term archive: compress. For quick-restore scenarios: keep uncompressed IMGs on fast storage.
Why Not Just Use a Smaller SD Card?
Reasonable question. If your Pi OS uses 6 GB, why not use a 8 GB card?
Reasons cards are bigger than needed:
- 8 GB cards are expensive per-GB. Often priced similarly to 32 GB cards. Not worth saving 2 GB.
- Log growth. Home Assistant logs, Pi OS journalctl, OctoPrint’s G-code history grow over time. Your 6 GB used today becomes 12 GB in six months.
- Flexibility. 32 GB lets you install extra tools, keep browser caches, save camera footage without worrying.
- Slower small cards. 8 GB and smaller cards tend to be older (Class 4 or 6), not A1-rated. Your Pi runs slower.
So people use 32 GB cards with 6 GB of actual use. And then wonder why backups are 32 GB. The card size choice is separate from the backup-size question.
How Other Tools Handle This
Quick comparison of backup size across imaging tools:
- Win32 Disk Imager: Full read or Allocated Partitions only. No filesystem awareness.
- balenaEtcher (Clone drive): Always full disk. Even bigger than Win32DI with Allocated Partitions.
- Clonezilla: Smart clone (filesystem-aware) skips unused blocks. Most efficient by default.
- Linux dd: Full disk, same as Win32DI without Allocated Partitions.
- Macrium Reflect / EaseUS Todo: Filesystem-aware. Skip unused blocks.
Clonezilla wins for raw backup efficiency. Win32 Disk Imager + PiShrink matches it with the extra post-processing step.
Storage Cost Analysis
Real-world cost of different backup strategies, 3 Pis backed up monthly for a year:
| Strategy | Per backup | 36 backups/year | Drive cost (budget HDD) |
|---|---|---|---|
| Full Read (naive) | 32 GB | 1152 GB | $30 (2 TB drive) |
| Allocated Partitions | ~28 GB | 1008 GB | $30 (2 TB drive) |
| PiShrink only | ~7 GB | 252 GB | $5 (shared with other data) |
| PiShrink + xz | ~2 GB | 72 GB | Fits on existing NAS |
Compression saves meaningful money. Especially for users with multiple Pis or long archive history.
Cloud Backup Math
If you upload backups to cloud (Backblaze B2, Wasabi, S3), compressed backups save real money:
Backblaze B2: ~$0.006/GB/month. Storing a 32 GB uncompressed IMG costs ~$0.20/month forever. 12 monthly backups × 3 Pis × $0.20 = $7/month ($84/year).
Same backups compressed to 2 GB each: $0.012/month per backup. 36 backups × $0.012 = $0.45/month ($5.40/year).
$80/year savings. Pays for the time to set up PiShrink in the first session.
FAQ
Can I set “Read Only Allocated Partitions” permanently?
Yes. Win32 Disk Imager saves the checkbox state in the registry (or config file). Once you tick it, it stays ticked on subsequent launches.
Does compression slow down the restore process?
Slightly. Decompression takes 1-2 min on modern CPUs for 10 GB IMGs. Flashing itself takes 3-5 min. Total restore: decompression + flashing + verify = maybe 10-15 min vs 7-10 min uncompressed.
Is compressed IMG the same as compressed file?
.img.xz is a .img file compressed with xz. Decompress to get .img. Compression is lossless, no data is lost.
Can Win32 Disk Imager read compressed .img.xz directly?
No. Decompress first with 7-Zip or xz. Pi Imager and balenaEtcher can read compressed images directly.
How do I know my “Read Only Allocated Partitions” backup is complete?
Write it back to a fresh SD card and boot. If it boots with full functionality, the backup was complete. Or verify with h2testw on the IMG’s contents.
Does xz compression work well on already-compressed data?
Poorly. If your IMG contains compressed files (JPEGs, MP4s, zipped archives), xz adds little beyond the internal compression. Best results are when IMG has mostly plain-text or lightly-compressed data (configs, logs, databases).
Are there tools that shrink non-Pi images?
Few. Most partition shrinkers (GParted, Windows Disk Management) operate on live disks, not IMG files. For non-Pi IMG shrinking, mount the IMG as a loop device in Linux, then use filesystem-specific resize tools (resize2fs for ext4, ntfsresize for NTFS).
Why does my 14 GB IMG compress to 13 GB? I expected more reduction.
Likely your IMG has a lot of already-compressed data (images, videos, games). Check: file sample.img on Linux often reveals contents. Or the filesystem may have already compressed content (NTFS compression, btrfs compression).
Is there a way to skip empty space during Write (not just Read)?
No. Write fills the destination with the IMG’s full content. If the IMG has empty space, empty space gets written. PiShrink the IMG before writing to reduce this overhead.
Can I encrypt a backup IMG?
Yes. 7-Zip with AES-256 encryption produces .7z.enc. Or VeraCrypt containers. Or individual-file encryption via NTFS EFS. Decrypt before flashing.
Should I back up the same Pi to multiple IMGs at different times?
Yes, rolling backups. Keep the current + previous 2-3 IMGs. Recent IMG for quick restore, older IMGs as fallback in case of silent corruption. Total storage: ~4x a single backup. Worth it.
Do sparse IMGs work with Win32 Disk Imager for writing?
Win32DI writes what’s in the IMG. Sparse IMGs have “holes” (unallocated regions) that write as zeros on the destination. Same end result as dense IMGs but faster transfer if the filesystem sending the file handles sparsity.
Wrapping Up
“Why is my backup so big?” is a universal Win32 Disk Imager question. Answer: because byte-for-byte copying doesn’t know what’s “empty.” Tick “Read Only Allocated Partitions” for free space savings, run PiShrink for deeper compression of Pi images, and xz-compress for archival. 32 GB → 3.5 GB reduction across the full workflow. For more, see PiShrink guide, SD backup guide, and what IMG files are.
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.
- How to Shrink an IMG File After Backup with PiShrink (2026) — Shrink Pi backup IMGs by 30-70% with PiShrink + WSL — auto-expand on first boot, real 14x storage savings example, automation script.
- How to Back Up an SD Card to an IMG File on Windows — Back up a Raspberry Pi SD card to an IMG file on Windows — full Read walkthrough, PiShrink compression, and a backup-schedule template.
- What Is an IMG File? (And Why Win32 Disk Imager Uses It) — Byte-for-byte disk image files explained — vs ISO/BIN/VHD, how to mount and modify, compression formats, history of the format.
- Win32 Disk Imager: Not Enough Space on Disk — Causes + Fixes — Why your 32 GB IMG won’t fit on your 32 GB SD card — PiShrink, SD card size variance, counterfeit detection, and the Read destination-space trick.