A disk image is a file that contains everything a storage device would contain, arranged the way the device would arrange it. Software that reads the file can pretend it is reading a device. The formats differ in what kind of device they are imitating and how much structure they add on top.
ISO
An ISO file is a sector-by-sector copy of an optical disc, carrying the ISO 9660 file system or its successors. It is the default distribution format for operating systems for one straightforward reason: it was the format you burned to a CD, and the world kept the format after the discs went away.
Bootable ISOs carry a boot catalogue describing what firmware should start. Modern ones are usually hybrids, arranged so they work both when written raw to a USB drive and when read as an optical image — which is why "write this ISO to a stick" became reliable advice.
WIM
WIM is a file-based image rather than a sector-based one. Instead of copying a disk's layout, it stores the files themselves, deduplicated across the image and compressed. Several system editions can share one WIM because their common files are stored once.
Because it describes files rather than sectors, a WIM is not something firmware can boot on its own. It is deployed: a loader starts a small preinstallation environment, which then expands the WIM onto the target disk. You meet WIM files inside Windows installation media and in recovery workflows.
IMG
IMG is the least specified of the four. It generally means a raw dump: the bytes of a device, in order, with no container structure at all. Partition tables, boot sectors and file systems are all present exactly as they were on the original device.
Its rawness is the point. Single-board computer images, embedded firmware images and forensic captures are usually IMG files, because nothing has been interpreted or reorganised on the way in. The cost is size — a raw image of a 32 GB card is 32 GB, mostly zeroes, unless it is compressed separately.
VHD and VHDX
These are virtual hard disk formats, built for virtual machines. They describe a whole disk including its partition table, and they add features a plain dump cannot offer: dynamic sizing that grows as data is written, snapshots, and in the VHDX case a log that protects metadata against power loss.
Their relevance to physical media is a Windows feature called native boot, in which the firmware and loader start an installation living inside a VHD file on an ordinary partition. Multiboot loaders extend the same idea to other systems.
Comparison
| Format | Models | Structure | Common source |
|---|---|---|---|
| ISO | An optical disc | Sector copy | OS installers, live systems |
| WIM | A set of files | Deduplicated archive | Windows deployment |
| IMG | A whole device | Raw dump | SBC cards, embedded systems |
| VHD / VHDX | A virtual disk | Container with metadata | Virtual machines, native boot |
How a loader presents them
A multiboot loader's job is to make one of these files look like a device to the system inside it. For sector-based formats this is comparatively direct: map the file's extents, present them as a block device, hand over control. For container formats it means understanding the container's own layout first. And for file-based images like WIM, the loader is not booting the image at all — it starts a preinstallation environment which then does the real work.
The mapping only works if the system inside the image looks for its own media in a way the loader can satisfy. Installers that hunt for a specific volume label or device path may not find themselves. This is why loader projects publish lists of images they have tested, and why checking one before a job in the field is time well spent.
Verifying what you have
- Take the checksum published by the project alongside the image — usually SHA-256.
- Compute the hash locally:
certutil -hashfile file.iso SHA256on Windows,shasum -a 256 file.isoon macOS and Linux. - Compare the two strings. Any difference at all means the file is not the one that was published.
- Where the project also publishes a signed checksum file, verify that signature too — it confirms the checksum itself has not been altered.
Doing this at download time is far cheaper than diagnosing an odd failure three machines later.