This guide is for anyone who made a backup, or inherited one, and now needs to put it back onto a card. It covers checking the backup file, choosing a suitable destination card, writing it correctly, and testing the result before you rely on it. It assumes you have a Windows computer, the backup file, and a destination card at least as large as the original card the backup came from.

The central warning of this guide cannot be overstated: restoring overwrites the ENTIRE destination drive. Everything on that card will be lost, including partitions you cannot see. Double-check the drive letter every time, and never restore over a card that holds data you have not backed up elsewhere, even if you are in a hurry.

Before you start

• Restoring wipes the ENTIRE destination card. If the destination card holds anything you need, copy it elsewhere first, or use a different card.
• The destination card must be at least as large as the original card. Cards sold as the same size can differ by a few megabytes, so a restore to a slightly smaller card can fail near the end.
• If the backup is compressed as a .7z or .zip file, decompress it to a plain .img file first. Win32 Disk Imager cannot write directly from a compressed archive.
• Keep the backup file safe during the restore. Do not restore from the only copy on a drive you are about to format, and do not delete the backup until the restored card has been tested.

Before you restore, confirm what the backup actually contains. Check the file name, date, and any notes you made when you created it, and confirm the file size is plausible for the original card. A backup file that is far smaller than the card it came from may be a compressed archive you forgot to decompress, or an allocated-partitions image, which is still valid but restores differently in terms of layout. Knowing which kind you have avoids confusion when the restore behaves unexpectedly.

Step by step

1. Locate and prepare the backup file

Find the .img file, and if it is compressed, decompress it with 7-Zip to a plain .img file on a drive with enough free space. Check the decompressed size against your notes or against the original card’s capacity. If the backup is on cloud storage, download it completely before you start, because a partial download that writes successfully will not boot.

2. Insert the destination card and note its letter

Insert the destination card, wait for Windows to recognise it, and note its drive letter in File Explorer. If Windows offers to format the card, choose Cancel. You are about to overwrite the card completely, so formatting first is unnecessary. If the letter you expect is missing, reseat the card or try another reader.

3. Open Win32 Disk Imager as administrator

Run Win32 Disk Imager as administrator, click the folder icon, and select your .img backup file. Confirm the Device drop-down shows the destination card’s letter, not the letter of another drive, a USB stick with data on it, or an external hard drive. This check is the most important step in the whole restore.

4. Write the backup and eject safely

Click Write, read the confirmation dialog, and confirm only if the drive letter is correct. Wait for the success message without removing the card or letting the computer sleep. When it finishes, use Safely Remove Hardware before removing the card, because Windows may still be flushing the final writes.

5. Test the restored card before relying on it

Put the restored card into its target device and boot it. Check that the system starts, the main application runs, and recent data you expect is present. If the device is a Pi, give first boot a few minutes, and check that the filesystem has the expected size. Only after this test should you consider the restore complete and the old card disposable.

6. Make a fresh backup of the restored system

Once the restored card is working, make a new Read backup of it, especially if you changed anything during recovery, such as passwords, network settings, or software versions. That fresh backup becomes your new baseline, so the next failure does not send you back to an older state. Label it with the restore date and a note that it came from a restore.

Where to keep the backup

A backup only helps if it survives the card it came from, so copy the finished .img file off the computer you flashed from. A dedicated backup drive (Sponsored) works well for large images, and you can also keep a second copy in cloud storage such as pCloud if you want an off-site copy. Label every file with the device, date, and contents before you upload it.

Frequently asked questions

Does restoring delete everything on the destination card?

Yes. Write overwrites the entire destination drive, including all partitions and files. Move anything you need off the card first, or use a different card.

Can I restore to a smaller card than the original?

No, not reliably. The destination must be at least as large as the original card, and cards sold as the same size can differ by a few megabytes, so use the same size or larger.

Do I need to decompress a .7z backup before restoring?

Yes. Decompress it back to a plain .img file with 7-Zip first, then write that file with Win32 Disk Imager, which cannot write directly from a compressed archive.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: how to back up sd card to img, compress img file 7zip, clone one sd card to many — each one covers one job in the same plain style as this guide.

This guide is for anyone who has a folder full of large .img files, or who is about to make a backup and wants a storage plan that will last. It covers installing 7-Zip, choosing a format, compressing correctly, verifying the archive, and decompressing before a restore.

One rule governs the whole guide: never delete the original .img file until you have verified the compressed archive and, ideally, tested a restore from it. Compression is reliable, but a backup you have never decompressed is a promise, not a proven copy. Keep the original until the compressed copy has earned your trust.

Before you start

• Check free disk space before compressing. You need room for both the original .img file and the archive until you verify the archive and delete the original.
• Do not compress an image while Win32 Disk Imager is still writing or reading it. Wait for the operation to finish completely.
• Use a clear archive name that matches the image name, with the date and device, so you can find the right backup months later.
• Remember that a compressed archive must be decompressed back to a plain .img file before Win32 Disk Imager can write it. Win32 Disk Imager does not write directly from a .7z or .zip archive.

Why do .img files compress so well, when they are already exact copies? Because empty sectors are highly repetitive: long runs of zeros compress to almost nothing. An image of a system that uses 4 GB on a 64 GB card is mostly empty space, so it compresses dramatically. An image of a card filled with photos, videos, or encrypted data compresses poorly, because that data is already dense or random. Both outcomes are normal, and the compression ratio tells you about the contents, not about whether you did something wrong.

Step by step

1. Install 7-Zip

Download 7-Zip from its official site, install the version matching your Windows system, and confirm it appears in the File Explorer right-click menu. You do not need any other compression tool for this guide, and you should avoid obscure tools that promise extreme ratios, because a backup format you cannot open in five years is worse than a slightly larger archive you can open anywhere.

2. Right-click the .img file and choose Add to archive

In File Explorer, right-click the .img file, choose 7-Zip, then Add to archive. This opens the compression settings dialog, where you choose the format and level. Do not simply choose Add to .zip from the quick menu if you want the best compression, because the dialog gives you control over format and level that the quick option does not.

3. Choose .7z format and a sensible level

Set Archive format to 7z and Compression level to Normal or Maximum. Normal is faster and already captures most of the saving on a sparse image; Maximum squeezes a little more at the cost of much longer compression time. For a one-off backup, Normal is the practical choice. Leave the other settings at their defaults unless you have a specific reason to change them, such as splitting the archive for storage on smaller media.

4. Compress and wait without interrupting

Click OK and wait for compression to finish. For a 64 GB image, this can take many minutes, even on a fast computer, because the tool must read the whole file. Do not put the computer to sleep, and avoid heavy disk work at the same time. When it finishes, note the archive size and compare it with the original, so you know how much you saved and whether the ratio looks plausible for the image’s contents.

5. Verify the archive before deleting the original

In 7-Zip, use Test archive on the new .7z file, or open it and confirm the .img file inside has the expected size. Only after that test passes should you consider deleting the original .img file to reclaim space. If you have room, keeping both for a while is even safer, and for irreplaceable backups, keeping the original on a separate drive is worth the space.

6. Decompress before you restore

When you need the backup, decompress the archive back to a plain .img file first, then write that file with Win32 Disk Imager as usual. Do not try to point Win32 Disk Imager at the .7z file, because it expects a raw image. After decompressing, check the file size against your notes, write it to a spare card for testing if the original is still working, and only then restore over a failed card.

Where to keep the backup

A backup only helps if it survives the card it came from, so copy the finished .img file off the computer you flashed from. A dedicated backup drive (Sponsored) works well for large images, and you can also keep a second copy in cloud storage such as pCloud if you want an off-site copy. Label every file with the device, date, and contents before you upload it.

Frequently asked questions

Can Win32 Disk Imager write a .7z file directly?

No. Decompress the archive back to a plain .img file first, then write that file with Win32 Disk Imager. The program expects a raw image, not a compressed archive.

Why did my image barely shrink when compressed?

Because the card was nearly full of dense data, such as photos, video, or encrypted files, which compress poorly. Sparse system images shrink dramatically, while full data cards do not.

Should I delete the original .img after compressing?

Only after you test the archive with 7-Zip Test archive and confirm the file inside has the expected size. For irreplaceable backups, keep the original on a separate drive as well.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: how to back up sd card to img, restore img backup to sd card, win32 disk imager allocated only read — each one covers one job in the same plain style as this guide.

Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) does not ask for confirmation per file, does not write only to a partition, and does not keep the old contents anywhere. It writes the image to the raw device. If the image is, for example, 4 GB and the wrong drive is 500 GB, the first 4 GB of that drive are overwritten with image data, and the remaining space may still contain old data that recovery tools could in principle retrieve. If the image is as large as or larger than the wrong drive, effectively the whole drive is overwritten and there is nothing left to recover from that drive itself. Either way, the overwritten sectors are gone — that is a property of magnetic and flash storage, not a limitation of a particular recovery program.

What to do immediately

• Stop using the drive now. Do not boot from it, do not save files to it, do not run a disk check that writes, and do not install recovery software onto it. Install any recovery tool on a different drive and work from there.
• Do not write anything else to it, including a new image. Every additional write overwrites more surviving sectors.
• Make a sector-level copy if you can, and recover from the copy. If the drive is still readable, image the whole drive to a different, larger drive first, then run recovery against the copy. That way a failed recovery attempt does not destroy the original further.
• Check your backups before paying for recovery. Cloud backups, an earlier Win32 Disk Imager Read image, or a copy on another drive may already hold what you need. See how to back up an SD card to an image for the backup habit that prevents this situation.

What can and cannot be recovered — honestly

• Cannot be recovered: any file, or part of a file, that lay in sectors overwritten by the image. No consumer or professional tool can read data that has been physically overwritten. Claims to the contrary are false.
• May be recoverable: files that lay entirely beyond the image’s size on a larger drive, and whose directory entries or file signatures recovery software can still find in the surviving area. Success here is partial and uncertain, not guaranteed.
• May be recoverable from elsewhere: copies in backups, email attachments, cloud storage, or other devices. These are often the real recovery path, and they are worth checking exhaustively before spending money.
• Professional recovery: a lab cannot recover overwritten sectors either. It can help with physically failing drives or complex filesystem damage in the surviving area, but it cannot reverse an overwrite. Do not pay a lab that promises otherwise.

How to prevent this next time

• Verify the drive letter and size every single time. Before clicking Write, compare the letter and the size shown in Win32 Disk Imager with the card you intend to write. If the size does not match your card, stop.
• Disconnect drives you do not intend to write. Unplug external drives and remove other cards before flashing, so the wrong drive is not even listed.
• Label your cards and readers. A card that looks identical to another is an easy mistake. Physical labels and a consistent slot reduce the risk.
• Back up before you flash anything else. A full-device Read image taken before a risky operation is the only safety net that actually works after an overwrite. See verify only and Error 5 for related safe-workflow habits.

If you need a fresh copy of the tool, use the download page, and the troubleshooting hub collects the other guides in this series. The lesson of this post is not a trick: it is a workflow change. Check letter and size, disconnect what you do not mean to write, and back up first — because after a wrong-drive write, there is no undo button, only damage limitation.

When to stop and switch tools

Stop running recovery scans if multiple tools, working from a sector copy, find nothing in the surviving area, or if the image was as large as the drive. At that point further scanning will not create data that was overwritten, and continuing to power a failing drive can do more harm. The honest stopping point is when you have checked backups, scanned the surviving area from a copy, and confirmed that the overwritten portion is unrecoverable. Switch your effort from recovery to rebuilding: reinstall, restore from backup, and change the workflow so the next flash cannot repeat the mistake.

FAQ

I just wrote to the wrong drive. Can recovery software get my files back?

For sectors that were overwritten by the image, no. Win32 Disk Imager writes the whole destination, and overwritten sectors cannot be recovered by recovery tools. Files in areas beyond the image size may still be recoverable, but anything under the image is gone.

Should I keep using the drive while I decide?

No. Stop using it immediately. Every new write risks overwriting surviving areas that recovery might still have retrieved.

Does this mean all my data is lost?

Not necessarily all of it, but you must assume the overwritten portion is lost. What survives depends on how large the image was compared with the drive, and on whether you stop writing at once.

This guide is for users who have made a full Read backup, been surprised by its size, and wondered whether this option is the answer. It explains the option in plain terms, shows when it produces a smaller file and when it produces the same size, and warns about the cases where a smaller image is not a faithful backup for your purpose.

The option is part of Win32 Disk Imager v1.0.0, released 2017-03-08, the current Windows-only GPLv2 release. It does not change how Write works, and it does not compress anything. It changes which sectors Read copies, and that distinction determines everything else in this guide.

Before you start

• This option affects Read only. It does not make Write faster, and it does not shrink an existing .img file you already made.
• Always keep a full backup of anything irreplaceable before you experiment with a smaller backup method. Test the smaller image by restoring it to a spare card before you rely on it.
• Understand your partition layout before you enable the option. If the card’s partitions already fill most of the card, the saving will be small, and the extra complexity may not be worth it.

To see why the option sometimes helps a lot and sometimes helps not at all, picture a 64 GB card with a 4 GB system on it and 60 GB of unallocated space. A normal Read copies all 64 GB. With Read Only Allocated Partitions, Read copies roughly the allocated partitions, so the image may be closer to 4 GB plus partition overhead. That is a large saving, and it is the case the option was designed for.

Step by step

1. Inspect the card’s partitions first

On the Pi or in a partition tool, look at how the card is divided. Note the size of each partition and how much unallocated space exists at the end of the card. If unallocated space is a large share of the card, this option is likely to help. If the partitions fill the card, expect only a small saving, and consider compression with 7-Zip instead, which shrinks empty space inside partitions as well.

2. Enable the option before you press Read

In Win32 Disk Imager, tick Read Only Allocated Partitions before starting the Read operation. The option must be set before Read begins; enabling it afterwards does not change an image you already made. Confirm the drive letter and the output file name as usual, because the rest of the Read process is unchanged.

3. Run Read and compare the output size

Click Read and wait for completion, then compare the output file size with the card’s full capacity. A much smaller file, when unallocated space was large, is the expected result. A file close to full size, when partitions fill the card, is also expected, and it does not mean the option malfunctioned. Record the size so you can compare future backups.

4. Test the smaller image by restoring it

Restore the smaller image to a spare card with Write, and boot that card in its target device. Confirm the system works and the data you care about is present. This test is essential, because a smaller image that restores correctly is a valid backup, while a smaller image you have never restored is only a hope. Never test by restoring over your only working original.

5. Decide whether to use it routinely

If the test passes and the saving is significant, you can use the option for routine backups of that card layout. If the saving is small, or if you need a bit-exact copy of the whole device for forensic or diagnostic reasons, stick with a full Read. The right choice depends on your layout and your reason for backing up, not on a general rule.

Frequently asked questions

Does Read Only Allocated Partitions compress the backup?

No. It skips unallocated space outside partitions, which makes the image smaller, but it does not compress anything. Use 7-Zip afterwards if you want further compression.

Why did my image stay large with this option enabled?

Because the card’s partitions already fill most of the card. The option skips unallocated space, not empty space inside a partition, so a full card layout gives little saving.

Is a smaller image safe to restore?

Yes, if you test it by restoring to a spare card and booting it. For normal system restores it is valid, but for forensic copies where unallocated data matters, use a full Read instead.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: how to back up sd card to img, compress img file 7zip, restore img backup to sd card — each one covers one job in the same plain style as this guide.

Win32 Disk Imager makes fake cards especially painful, because a Write overwrites the entire destination and a Read copies the whole device sector by sector. A fake card may appear to accept a full-device write, then fail to boot or lose data when the device tries to read back sectors that were never really stored. If you have had a write succeed and then a boot fail, or a backup that restores with corruption, test the card before blaming the image — see write succeeded but won’t boot and slow write speed, both of which share fake cards as a common cause.

How to test with h2testw on Windows

• Back up anything on the card first, if it is still readable. The test overwrites the whole card, so anything on it will be destroyed. Copy what you can before testing.
• Download h2testw from a reputable source and run it as administrator. Select the card’s drive letter carefully — writing test data to the wrong drive destroys that drive’s contents, just as a Win32 Disk Imager write would.
• Choose Write + Verify and test the full capacity, not a small sample. A partial test can miss a fake card whose real capacity is larger than the sample but smaller than printed. Only a full test is conclusive.
• Wait for the result. A genuine card completes with no errors and reports the full tested capacity. A fake card reports data loss, verification errors, or a real capacity far below printed — for example, a card sold as 128 GB that only holds 16 GB.
• Do not trust a card that fails, even partially. If the test shows any significant shortfall, the card is not usable for reliable storage, even for files smaller than its real capacity, because its controller is already lying about its geometry.

F3 on Linux and macOS

F3, short for Fight Flash Fraud, provides the same idea on Linux and macOS: f3write fills the card, f3read verifies it, and the report shows real versus claimed capacity. If you work across systems, F3 is the cross-platform counterpart to h2testw. The principle is identical — write everything, read everything back, believe only the verified result — and a quick format or a capacity reading in a file manager proves nothing on its own, because the fake controller reports the fake size to the operating system too.

What to do with the result

• Pass: the card is genuine as far as a full test can prove. It can still wear out or fail later, so keep backups, but capacity fraud is ruled out.
• Fail: stop using the card for anything important, return it if you can, and replace it from a reputable seller. Do not keep it as a spare for small files; its controller cannot be trusted.
• Uncertain or interrupted: if the test was interrupted by a reader disconnect, retry with a different reader and a direct port before concluding. A reader fault can mimic a card fault — see Error 121.

When you replace a failed card, buy on sustained reliability, not the cheapest price per gigabyte. A durable endurance microSD card (Sponsored) and a reliable USB card reader (Sponsored) remove the two hardware variables that most often confuse fake-card diagnosis: a slow or flaky reader can make even a genuine card look bad. A fresh copy of Win32 Disk Imager is on the download page, and the troubleshooting hub covers the symptoms that lead people to test in the first place.

When to stop and switch tools

Stop testing a card that has failed a full h2testw or F3 test on two readers. No second test, no format, and no different imaging tool will make its missing capacity appear, because the capacity was never there. Switching tools is useful only when a test was interrupted by hardware — a disconnect or a reader fault — and you need a clean rerun. Once a full, uninterrupted test has failed, the verdict is final: replace the card.

FAQ

What is h2testw and what does it do?

h2testw writes test data to the whole card and reads it back, verifying that the card really holds as much as it claims. It is a free Windows tool widely used to expose fake-capacity cards.

How long does a full test take?

It depends on card size and speed. A large card on a slow reader can take hours, because the test must write and read every sector to be conclusive. A quick partial test cannot prove a card is genuine.

Can a fake card be fixed by formatting?

No. Formatting cannot create capacity that is not physically there. A card that fails a full test should be replaced, not reformatted and trusted.

Is F3 an alternative if I also use Linux or Mac?

Yes. F3 provides similar write-and-verify testing on Linux and macOS, while h2testw is the usual Windows choice. Win32 Disk Imager itself is Windows-only, so h2testw fits the same PC workflow.

This guide is for anyone who has flashed a card that must work first time: a Pi going into a remote location, a card for a demonstration, a master image for cloning, or any card where a second trip to fix it would be costly. It explains what Verify Only checks, how to run it, how to read its result, and when it is worth the extra time it takes.

Verify Only exists in v1.0.0, the current Win32 Disk Imager release from 2017-03-08. The program is Windows-only and GPLv2 licensed, and Verify Only works the same way regardless of which image you wrote, whether it is Raspberry Pi OS, another Linux image, or a backup you made with Read. It compares data, not bootability, and that distinction matters for interpreting its result.

Before you start

• Verify Only reads the destination, so it does not erase anything. Still, do not remove the card during verification, because an interrupted verify gives no useful result.
• Keep the original .img file. Verify compares the card against that file, so if you delete or move the image, there is nothing to compare against.
• Verify takes roughly as long as a write, because it must read the whole card. Plan for that time when a card must be ready by a deadline.

Understanding what a match means will save you from overconfidence. A verify pass that succeeds means the card’s contents match the image file, sector by sector, for the area the image covers. It does not mean the image itself is correct for your device, that the card is healthy for long-term use, or that the Pi’s power supply is adequate. Those are separate questions, and a verify pass answers only the first one: did the write land correctly?

Step by step

1. Write the image normally first

Flash the card with Win32 Disk Imager as usual: select the .img file, double-check the drive letter, click Write, and wait for success. Verify Only is a separate step after writing, not a replacement for writing. If you run Verify Only on a blank or unrelated card, it will report a mismatch, which tells you nothing except that the card does not contain that image.

2. Select the same image and the same device

Leave the Image File field pointing at the same .img file you just wrote, and leave the Device drop-down on the same drive letter. Verify compares exactly those two things, so selecting a different image or a different card invalidates the comparison. If you ejected the card after writing, reinsert it and confirm the letter again, because drive letters can change when devices are reconnected.

3. Run Verify Only and wait

Click Verify Only and wait for the process to complete without removing the card or letting the computer sleep. The progress bar advances as the card is read and compared. A full verify of a large card takes minutes, and interrupting it forces you to start again. Use that time to prepare the target device, rather than starting another disk-heavy task on the same computer.

4. Read the result correctly

A success message means the card matches the image. A failure message means it does not, and you should reflash the card, preferably after trying a different reader or USB port. If the same card fails verification twice, set it aside and test a different card, because repeated verify failures are a strong sign of failing flash or a faulty reader, not of bad luck.

5. Boot-test after a successful verify

Even after a successful verify, boot the card in its target device before you rely on it, especially for a remote deployment. Verify proves the data matches; booting proves the device can use it. The two tests together give you confidence that neither the write nor the device configuration is at fault.

Frequently asked questions

Does Verify Only change or repair the card?

No. It only reads the card and compares it with the image file. It does not write, repair, or change anything on the card.

Is Verify Only the same as writing again?

No. Writing copies the image to the card; verifying reads the card back and checks it against the image. Verify is a check, not a second write.

Should I verify every card I flash?

Verify when failure would be costly, such as a remote Pi or a master image for cloning. For quick desk tests, a boot test alone is usually enough.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: how to use win32 disk imager, clone one sd card to many, how to back up sd card to img — each one covers one job in the same plain style as this guide.

This guide is for teachers, makers, and small teams who need five, twenty, or fifty identical cards. It assumes you have a Windows computer, a reliable card reader, and enough cards of the same nominal size. It also assumes you understand the one rule that governs the whole job: writing an image wipes the destination completely, so a card you clone over is gone, not merged.

Win32 Disk Imager is well suited to this job because its Read and Write operations are exact and repeatable. It has no built-in multi-card queue, so you will write cards one at a time, but the process is fast enough for small batches, and the master image can be reused indefinitely once it is verified. For very large batches, dedicated duplicator hardware is faster, but for most classroom and workshop needs, this method is sufficient.

Before you start

• Writing wipes the ENTIRE destination card. Label your master card clearly and keep it separate from blank cards, so you never accidentally overwrite the master.
• Use cards of the same nominal size, and test that the master image fits on every batch. Cards sold as the same size can differ by a few megabytes, and a slightly smaller card will fail at the end of a write.
• Work with one card at a time. Win32 Disk Imager writes to one selected device, and trying to rush by swapping cards mid-write causes failures.
• Keep a written checklist of which cards are done. It is easy to lose track after the tenth identical card, and a half-finished batch is worse than a slow one.

Start by preparing the master card properly, because every clone inherits both its strengths and its mistakes. Install the system, configure it, update it, test it in the target device, and only then make the master image. Remove personal credentials, Wi-Fi passwords you do not want on every card, and any files that belong to one user rather than to the whole batch. A master image is a snapshot, so clean it before you copy it.

Step by step

1. Prepare and test the master card

Set up one card completely in its target device: operating system, software, settings, and test data. Boot it, run the main application, and confirm everything works. Fix any problems now, because fixing them on fifty clones is fifty times the work. When the master is ready, shut the device down cleanly and remove the card.

2. Make the master image with Read

On Windows, run Win32 Disk Imager as administrator, select the master card’s drive letter, choose an output file name for the master image, and click Read. Read copies the whole card sector by sector, so the file will be as large as the full card. Wait for success, then check the file size. Do not skip this step by writing directly from card to card, because Win32 Disk Imager does not copy card to card in one step.

3. Verify the master image on a test card

Write the master image to a spare card, boot that card in the target device, and confirm it works exactly like the master. This test card is your proof that the image is good. If it fails, fix the master and repeat, before you write to the whole batch. A bad master image multiplied by fifty cards is a costly mistake.

4. Write the image to each destination card

For each blank card, insert it, confirm its drive letter in File Explorer and in Win32 Disk Imager, click the folder icon to select the master image, and click Write. Confirm the drive letter every single time, even when you are sure, because a tired operator is the most common cause of overwriting the wrong drive. Eject each card cleanly before removing it.

5. Spot-check cards from the batch

Do not assume every card is good because the first three were. Boot a sample from the start, middle, and end of the batch in a target device, and check that the system starts and the main application runs. If a card fails, reflash it once; if it fails twice, set it aside as a suspect card rather than forcing it into service.

6. Label and store the finished cards

Label each finished card with the image name and date, using a method that survives handling, such as a small sticker or a labelled case. Store the master image with a note of which device, software versions, and settings it contains. That note is what makes the batch reproducible next term, when nobody remembers exactly what was on the master.

Frequently asked questions

Can Win32 Disk Imager copy directly from one card to another?

No. First use Read to save the master card as an .img file, then use Write to copy that image to each destination card. The image file is the middle step.

Why does a clone fail on a card sold as the same size?

Cards sold as the same size can differ by a few megabytes in true capacity. If the destination is even slightly smaller than the master card, the write can fail near the end.

Should I verify every cloned card?

Boot-test a sample from across the batch, and reflash any card that fails. Testing every card is ideal for critical deployments, while sampling is reasonable for a classroom batch.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: how to back up sd card to img, how to use win32 disk imager, flash raspberry pi os win32 disk imager — each one covers one job in the same plain style as this guide.

Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) does not compress, cache, or otherwise accelerate the copy; it writes sectors in order until the device is done. That means a 64 GB card will always take substantially longer than a 16 GB card on the same hardware, and a card that is nearly worn out will write far slower than a new one of the same rating. Headline speed ratings on packaging describe ideal sequential reads, not sustained full-device writes, so a card that benchmarks well for a few seconds can still slow dramatically over a full write as it heats up or hits worn flash.

Common causes

• Slow or old reader. A USB 2.0 reader, or a cheap USB 3.0 reader with a poor controller, caps the transfer well below what the card can do.
• Hub, front port, or long cable. Hubs and poor connections can negotiate down to USB 2.0 speeds or introduce retries that look like slowness.
• Card itself is slow or worn. Low-grade cards, heavily used cards, and fake cards with slow flash all write slowly across their whole capacity.
• PC load or power saving. Another heavy disk task, antivirus scanning the removable drive, or USB power management throttling the port can all slow a write.
• Nearly full or fragmented target. This matters less for raw writes than for file copies, but a card with many bad or worn sectors will retry and slow down.

Fixes, cheapest and quickest first

• Close other disk activity and antivirus scans of the removable drive. Pause a backup, a scan, or a large copy running at the same time, then retry.
• Move to a direct USB 3.0 port. Plug the reader directly into the PC, not a hub, and try a rear port on a desktop. If Windows reports the device as USB 2.0, the port or cable is the limiter.
• Try a different reader. This is the single most revealing test. If the same card writes dramatically faster in another reader, replace the reader — it was the bottleneck.
• Test a different, known-good card. If every card is slow in every reader on that PC, suspect the PC’s USB subsystem or drivers. If only one card is slow everywhere, that card is worn, low-grade, or fake — see how to test a fake card.
• Disable USB selective suspend for the write. In Power Options, turn off USB selective suspend so the port is not throttled mid-write.
• Update USB controller drivers from the PC maker. Use the maker’s driver page and reboot before retesting.

When the reader is the bottleneck, replacing it is a genuine fix, not an upgrade for its own sake. A reliable USB 3.0 SD card reader (Sponsored) removes the most common cap, and if the card itself is the limiter, a durable endurance microSD card (Sponsored) is built for sustained writes rather than burst headline speeds. Choose on sustained-write suitability and capacity you actually need, not on the largest speed number on the box. Neighbouring timeout symptoms are covered in Error 121, and a fresh copy is on the download page; the troubleshooting hub collects the rest.

When to stop and switch tools

Stop optimising Win32 Disk Imager if a different reader, a direct USB 3.0 port, a known-good card, and updated drivers all still produce the same slow write on that PC, while the same card and reader are fast on another PC. The limiter is then the PC’s USB subsystem, and another imager copying the same sectors will hit the same limit. Conversely, if one card is slow in every reader and every PC, stop re-flashing it and replace it: a card that writes slowly everywhere is telling you its flash is worn or counterfeit, and repeated full writes will only wear it further.

FAQ

Is slow writing normal for large cards?

To a degree, yes. A full-device write copies every sector, so a large card takes a long time even on good hardware. The problem is when it is far slower than the same card and reader managed before.

Will a faster card always write faster?

Not on its own. The reader, the USB port, and the card’s sustained write performance all matter. A fast card in a slow reader is still limited by the reader.

Should I stop a very slow write part-way?

If it has truly stalled for a long time with no progress, stopping is reasonable, but expect the card to be in an incomplete state and re-flash from scratch after fixing the bottleneck.

This guide is for anyone who flashed a Raspberry Pi image, or another Linux-based image, and now sees a card that reports far less space than its label promises. It explains why the card looks small, how Raspberry Pi OS handles expansion automatically, and what to do when expansion does not happen on its own. It also explains the Windows case, where the answer is different, so you do not chase a Linux solution for a Windows problem.

A warning first: expanding a filesystem changes partition boundaries, so back up anything important on the card before you resize it. The operation is routine and usually safe, but a power loss during a resize can corrupt the filesystem. Work on a copy if the card holds irreplaceable data, and never resize a card while the device using it is running from that card unless the tool you are using is designed for online expansion.

Before you start

• Back up the card with Win32 Disk Imager Read before resizing, if the data matters. A resize is low-risk, but a backup makes it no-risk.
• Do not expand a partition into space that belongs to another partition. Check the layout first, in the Pi itself or in a partition tool, so you know what is free and what is already used.
• On Windows, do not expect to expand a Linux ext4 partition with Disk Management. Windows cannot read ext4, so it will show the partition as unknown, and that is normal, not a fault to fix in Windows.

Understanding the layout helps everything else make sense. A typical Pi image has a small FAT boot partition that Windows can see, and a larger Linux root partition that Windows cannot read. After flashing, Windows shows the boot partition’s size and hides the rest, which is why a 64 GB card can appear as a 256 MB drive. The space is not lost; it is in partitions Windows does not display, plus unallocated space the image never assigned.

Step by step

1. Check whether expansion already happened

Boot the Pi, open a terminal, and run df -h to see the size of the root filesystem. If the root partition is close to the card’s full capacity, expansion already happened and you do not need to do anything. If it is close to the original image size, for example 2 GB on a 32 GB card, then manual expansion is needed. Checking first avoids resizing a filesystem that is already correct.

2. Use raspi-config on Raspberry Pi OS

On Raspberry Pi OS, run sudo raspi-config, choose Advanced Options, then Expand Filesystem, and reboot when prompted. This is the supported method, and it handles the partition and filesystem resize together. After rebooting, run df -h again to confirm the root filesystem now fills the card. If raspi-config reports that the filesystem is already expanded, trust that result and look elsewhere for your missing space.

3. Expand manually with a partition tool if needed

For images without raspi-config, boot the Pi from a different card, or use a Linux system, and resize with a partition tool such as GParted. Select the card, resize the root partition into the free space, apply, and then check the filesystem. Do not resize the boot partition unless you have a specific reason, and do not move the start of a partition, because moving a partition start is slower and riskier than extending its end.

4. If you only use Windows, use a Linux live system

Windows Disk Management cannot expand an ext4 partition, and third-party Windows tools that claim to do so should be used cautiously and only after a backup. The reliable route is a Linux live USB, GParted, or a second Pi booted from another card. That sounds like extra work, but it is safer than a Windows tool silently mishandling a filesystem it cannot read.

5. Verify the result and test the card

After expansion, boot the Pi from the resized card and confirm with df -h that the space is available. Copy a test file, reboot, and confirm the system still boots cleanly. If the Pi fails to boot after a resize, restore your Read backup to a spare card and retry the resize, because a failed resize is easier to recover from with a backup than without one.

Frequently asked questions

Why does my 64 GB card show only a few hundred megabytes in Windows?

Windows shows only the small FAT boot partition it can read. The Linux partitions and unallocated space are hidden from File Explorer, but they are still on the card.

Does Raspberry Pi OS expand automatically?

Yes, normally on first boot it expands its root filesystem to fill the card and may reboot once. Manual expansion is only needed if that step did not happen.

Can I expand the filesystem in Windows Disk Management?

Not for a Linux ext4 partition. Windows cannot read ext4, so use raspi-config on the Pi, or GParted from a Linux system, after backing up the card.

For the full set of guides, see the Tutorials hub, and get the program from the download page. Related guides include: flash raspberry pi os win32 disk imager, raspberry pi wont boot after flashing, how to back up sd card to img — each one covers one job in the same plain style as this guide.

Normally, Win32 Disk Imager’s Read copies the whole device sector by sector, and the output size equals the full device size with no compression. That is predictable: a 32 GB card produces a 32 GB image, even if only 2 GB is used. Read Only Allocated Partitions is meant to avoid that waste by reading only allocated partition areas. In practice, users have reported that it can produce an empty or tiny image, particularly when the partition table is unusual, when partitions are not recognised as allocated in the way the program expects, or when the card’s layout includes partitions Windows does not mount. These are user-reported issues, not certified bugs, and the exact trigger varies by card — which is why verification, not assumption, is the remedy.

Why the image comes out empty or tiny

• Partition table not interpreted as expected. If the program does not recognise the partitions as allocated, it may read little or nothing.
• Linux or unusual partitions. Cards with Linux partitions, multiple small partitions, or non-standard layouts are more likely to confuse the allocated-only logic than a single FAT partition.
• Card not cleanly recognised. A card that Windows sees only partially, or a reader that drops during the read, can truncate the allocated calculation.
• Wrong device selected. Reading the wrong, smaller device — for example a RAM disk or a small partition — produces a small image that looks empty compared with expectations. Always confirm the device size before reading.

Fixes, cheapest and quickest first

• Check the image size immediately after the read. Compare it with the used space on the card. If it is orders of magnitude smaller and you expected data, do not trust it — treat it as a failed backup until proven otherwise.
• Do a full-device Read instead. Uncheck Read Only Allocated Partitions and read the whole device. The file will be large — equal to the full device size — but it is the predictable, complete copy. See allocated only read and how to back up an SD card to an image.
• Compress the full image afterwards. A full image compresses well when much of the card is empty. Use 7-Zip or a similar tool on the .img file — see compress an image with 7-Zip — rather than relying on allocated-only reading to save space.
• Test-restore before you depend on any image. Write the image to a spare card and confirm the device boots or the files are present. An untested backup is not a backup.
• Re-read with a different reader if the full read also looks wrong. A flaky reader can truncate reads, so a second reader is a cheap diagnostic before blaming the option itself.

The practical rule is simple: use allocated partitions only as an experiment, never as your sole backup for irreplaceable data, until you have test-restored an allocated image from that exact card layout and confirmed it works. For anything important, the full read plus compression route is slower and larger on disk, but it removes the uncertainty. Get a fresh copy from the download page if needed, and see the troubleshooting hub for related read problems.

When to stop and switch tools

Stop using the allocated-partitions option for that card if it repeatedly produces tiny or empty images while a full read produces a correct, restorable image. That tells you the option and that card’s layout do not get along, and retrying it will not change the layout. Switch to full reads plus compression for that card. If even a full read produces a tiny or corrupt image, stop and suspect the reader or the card itself — see Error 121 for the hardware checks — because no read option can fix a device that cannot be read reliably.

FAQ

What does Read Only Allocated Partitions actually do?

It is intended to read only the parts of the device that belong to allocated partitions, rather than the whole device, so the resulting image should be smaller than a full-device copy.

Why is my allocated-partitions image tiny or empty?

User reports describe cases where the option produces a much smaller image than expected, or one that appears empty, often linked to how the program interprets the partition table on that particular card.

Should I use allocated partitions for backups I depend on?

Only after verifying the image restores correctly. For a backup you cannot afford to lose, a full-device Read that you have test-restored is the safer choice until you have proven the smaller image works.