IMG File Documentation

Summary

An .img file is most often a raw disk or disc image: a sector-by-sector copy of a CD/DVD, floppy, USB stick or partition, very often identical to an ISO. Its MIME type is application/octet-stream. On Windows 8+ many .img files mount with right-click → Mount; write one to a USB stick with Rufus or balenaEtcher, or extract files with 7-Zip. The extension is reused by Apple DiskCopy, Android system images, Garmin maps and GEM bitmaps, so check the source.

Technical details

Feature	Value
Full name	Raw Disk/Disc Image (generic); also Apple DiskCopy 4.2
File extension	`.img`
MIME type	`application/octet-stream`
Format type	Raw sector-by-sector image of a disk or disc
Developer	No single owner (generic); DiskCopy 4.2 by Apple
Introduced	Predates standardization (floppy / optical era)
Open standard	Partial (raw images are vendor-neutral)
Magic number	None universal; raw ISO-style shows `CD001` at `0x8001`
FAT floppy marker	`55 AA` at offset `510` (boot-sector signature)
DiskCopy 4.2 magic	`01 00` at offset `0x52`, data from `0x54`
Byte order	Embedded filesystem’s own; DiskCopy 4.2 header big-endian
Contains	An embedded filesystem (ISO 9660/UDF, FAT, ext4, NTFS, HFS)
Often equivalent to	ISO (for optical-disc images)
Mount (Windows)	Right-click → Mount (Windows 8+, ISO-style images)
Flash to USB/SD	Rufus, balenaEtcher, `dd`
Extract files	7-Zip (browse without mounting)
Also used by	Android system/boot image, Garmin map, GEM raster bitmap
Related extensions	`.iso`, `.bin`, `.cue`, `.nrg`, `.mdf`, `.dmg`, `.vhd`
Reference	IMG (file format) overview

Structure at a glance

A raw .img has no header of its own and no universal magic number; it is the medium copied straight through, so you identify it by the filesystem embedded inside. A raw optical image carries the ISO 9660 marker CD001 (hex 43 44 30 30 31) at offset 0x8001, exactly like an ISO. A raw FAT floppy or USB image shows the boot-sector signature 55 AA at offset 510, often with MSDOS or FAT12/16/32 text in the boot sector. The Apple DiskCopy 4.2 variant is the exception that does have a header: the magic 01 00 sits at offset 0x52 and sector data begins at 0x54.

What is an .img file?

An .img file is, in the great majority of cases, a raw disk or disc image: a byte-for-byte copy of a storage medium, whether an optical disc, a floppy, a USB drive or a hard-disk partition. “Raw” means there is no compression and no wrapper; the file is simply the medium’s sectors written out in order. A raw optical-disc .img is frequently identical in content to an ISO file, holding the same ISO 9660 or UDF filesystem, which is why many tools treat .img and .iso as interchangeable and “convert” one to the other with little more than a rewrite.

The extension is genuinely overloaded, so the honest first question is always “where did this .img come from?” A file from a Raspberry Pi download, a Linux distribution or a disc backup is a raw disk image; but the same three letters are also used by Apple’s DiskCopy 4.2 floppy format, by Android firmware partitions, by Garmin GPS maps and by an old GEM bitmap format, none of which are related. This article covers the dominant raw-image meaning in byte-level detail, then addresses the specific formats that reuse the extension.

Raw sectors and the filesystem inside

A raw image has no structure of its own to describe, because it is the disk. Its layout is whatever the copied medium’s filesystem put there. That is why a raw .img has no universal magic number: you identify it not by a header at offset 0 but by the filesystem signatures embedded at their fixed positions.

raw optical / ISO 9660 image:
  offset 0x8000  Primary Volume Descriptor begins
  offset 0x8001  the ASCII identifier "CD001"   (43 44 30 30 31)

raw FAT floppy / USB image:
  offset 0x000   boot sector (jump instruction, OEM name, BPB)
  offset 0x1FE   the boot signature 55 AA        (offset 510)
  often "MSDOS", "FAT12", "FAT16" or "FAT32" text in the boot sector

An ISO 9660 volume reserves the first 32 KiB (16 sectors of 2048 bytes) as a system area, then places its Primary Volume Descriptor at sector 16, i.e. offset 0x8000, whose second byte onward spells CD001. A FAT-formatted floppy or USB image instead begins with a boot sector whose final two bytes, at offset 510, are 0x55 0xAA, the boot signature the BIOS checks. An ext4 or NTFS image exposes those filesystems’ own superblock or boot markers. The practical consequence is that any tool which can read the embedded filesystem can read the .img: 7-Zip opens it as an archive and lists the files, and the OS can mount it as a virtual drive.

Mounting a raw image as a virtual drive

Mounting presents the image to the OS as if it were a real inserted disk, without writing anything. On Windows 8 and later, right-clicking many .img files gives a Mount command that attaches the image as a new drive letter; this path handles ISO-style optical images and fails on raw floppy/HDD images with other filesystems, which is a common source of the “Windows can’t mount this .img” complaint. On macOS, double-clicking an ISO-style .img mounts it through DiskImageMounter. On Linux the kernel’s loop device does it: sudo mount -o loop file.img /mnt maps the file to a block device and mounts the filesystem inside.

When native mounting refuses a raw image, the fallback is to read it without mounting. 7-Zip opens a raw .img as an archive and extracts individual files straight out of the embedded filesystem, and tools like OSFMount or ImDisk on Windows can force-mount filesystems Explorer will not touch. None of these modify the image.

Flashing an image to a USB stick or SD card

The other main use of a raw .img is the reverse of imaging: writing it back onto physical media to recreate a bootable drive. This is how Raspberry Pi OS and most single-board-computer and Linux images are deployed. Because the image is a raw sector copy, flashing is a literal block-for-block write to the target device, which is what makes it bootable and what makes it dangerous.

Linux / macOS, raw write with dd:
  sudo dd if=raspios.img of=/dev/sdX bs=4M status=progress
        └ input file          └ TARGET DEVICE (whole disk, not a partition)

The critical detail is that of=/dev/sdX names an entire device and dd overwrites it from sector 0, destroying whatever was there, partition table included. Naming the wrong device wipes the wrong disk with no confirmation and no undo, which is why the GUI tools balenaEtcher (cross-platform) and Rufus (Windows) exist: they let you pick the image and the drive, show which drive you selected, and refuse to target the system disk. The write erases the target completely either way, so the correct-device check is the whole safety story here.

The Apple DiskCopy 4.2 image: the real “Macintosh disk image”

One .img variant genuinely is a Macintosh format and, unlike a raw image, has a defined header. Apple’s DiskCopy 4.2 stored 400K/800K classic-Mac floppies as an uncompressed sector image preceded by an 84-byte header, and those files usually carry the .img extension.

offset  size  field
0x00     64   disk name         Pascal string: 1 length byte + up to 63 chars
0x40      4   data size         big-endian, bytes of sector data
0x44      4   tag size          big-endian, bytes of tag data
0x48      4   data checksum     big-endian
0x4C      4   tag checksum      big-endian
0x50      1   disk encoding     00=400K GCR 01=800K GCR 02=720K MFM 03=1440K MFM
0x51      1   format byte
0x52      2   magic number      01 00  (identifies a DiskCopy 4.2 file)
0x54    ...   sector data       (tag data follows at 0x54 + data size)

All the header integers are big-endian, matching the 68k Macs the format came from and the opposite of the little-endian order in most PC images. The two-byte magic 01 00 at offset 0x52 is the reliable identifier, and sector data starts at 0x54. On the original Mac these files also carried a resource fork and the HFS type/creator codes dImg/dCpy, but the fork only duplicates the checksums and can be ignored; a copy that lost its fork still works. This is the format the site’s “Macintosh disk image” label refers to, though it is a small fraction of real-world .img files today.

.img versus .iso, and converting between them

For optical discs, the difference between .img and .iso is often nothing at all: both are raw images of the same ISO 9660/UDF content, so “converting” is frequently a rewrite or even a rename. .iso specifically denotes an ISO 9660/UDF optical image, while .img is the more generic raw label that can equally mean a floppy, USB, HDD or DiskCopy image. When a genuine rewrite is needed (for example to strip or add a header, or to switch between an image and a BIN/CUE pair), 7-Zip can open and re-save, and AnyBurn, PowerISO or dd convert between the family of raw and near-raw disc formats. Many proprietary disc-image formats in the same family — NRG, MDF, BIN/CUE, DAA, CDI — convert to and from .img and .iso through the same tools. Apple’s .dmg is a related image format; conversion is possible with macOS hdiutil convert but is mostly relevant on the Mac and can be lossy for boot and filesystem specifics.

Other formats that reuse the extension

Three unrelated formats also use .img, and they are told apart by their source rather than by mounting. An Android system image is a firmware partition such as system.img or boot.img, flashed to a device with fastboot; it is a partition image, not a disc, and mounting it in a desktop OS generally does nothing useful. A Garmin map image (for example gmapsupp.img) holds GPS map data loaded onto Garmin devices or through BaseCamp, and is meaningless to a disk-image tool. A GEM raster bitmap is a legacy planar picture format from Digital Research’s GEM environment (Atari ST, old DTP), which is why some conversion lists pair .img with PNG/JPG/TIFF — those apply only to the GEM-bitmap meaning and are handled by image viewers like XnView, not by disk tools. If an .img did not come from a disk, USB or OS-image workflow, one of these is the likely explanation, and the fix is to open it with the right application for that source.

Mount and download risk

A disk image is passive data, but mounting one is a known malware-delivery technique. Like an ISO, a mounted .img appears to the OS as an inserted drive, and an executable placed inside can sidestep some “mark of the web” download warnings that would otherwise flag a bare downloaded program, because the file the user launches came off a “drive” rather than directly from the internet. The defence is provenance: download OS and recovery images only from the official vendor, and verify the published SHA-256 checksum of the file before mounting or flashing it. Combined with the device-overwrite caution when flashing, that covers the two real hazards of working with .img files.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents