WIM File Documentation

Summary

A .wim file is a Windows Imaging Format image, Microsoft’s file-based disk image used to deploy and back up Windows. The install.wim inside a Windows installation ISO is the classic example: it holds the whole Windows file set, sometimes several editions in one file. Because WIM stores files rather than raw disk sectors, you can browse and extract it with 7-Zip, or mount it read/write with the built-in DISM tool. Its MIME type is application/x-ms-wim.

Technical details

FeatureValue
Full nameWindows Imaging Format
File extension.wim
MIME typeapplication/x-ms-wim
Format typeFile-based disk image (single-instance-store archive + metadata)
DeveloperMicrosoft Corporation
IntroducedWindows Vista, 2006
Open standardNo — documented by Microsoft but proprietary
Byte orderLittle-endian
Magic number4D 53 57 49 4D 00 00 00 (“MSWIM\0\0\0”)
Header size208 bytes (_WIMHEADER_V1_PACKED)
CompressionXPRESS or LZX (per-resource); LZMS in ESD variant
DeduplicationSingle-instance store — identical files stored once
ContentsOne or more images (indexes) + XML manifest + file resources
IntegritySHA-1 hash per resource in the lookup (offset) table
Native toolingDISM (mount/apply/capture), built into Windows
Splitting.swm chunks for FAT32 (4 GB limit)
Compressed variant.esd (encrypted, LZMS “recovery” compression)
Related extensions.esd, .swm, .iso, .vhd, .vhdx
Specificationlearn.microsoft.com — WIM file format
File signature (magic bytes)
4D 53 57 49 4D 00 00 00

Offset 0, 8 bytes. In ASCII this is MSWIM followed by three 0x00 bytes, the ImageTag that marks the Windows Imaging Format header. It is the first field of the fixed 208-byte _WIMHEADER_V1_PACKED structure. All multi-byte integers in the header are little-endian. The related ESD variant (.esd) shares this header; wimlib’s pipable WIM uses WLPWM\0\0\0 instead.

What is a WIM file?

A .wim file holds a Windows Imaging Format image, the file-based disk-image format Microsoft introduced with Windows Vista in 2006 and has used for every Windows installer since. The two files most people have touched without realising it are boot.wim and install.wim, which sit in the sources folder of any Windows installation ISO or USB. install.wim contains the entire Windows file set to be laid down on disk.

What makes WIM different from a ISO or a raw .img is that it is file-based, not sector-based. An ISO is a byte-for-byte copy of a filesystem; a WIM stores the individual files and their metadata and reconstructs a filesystem when applied. That single design choice produces WIM’s two defining features: single-instance storage (a file that appears in many images is stored only once) and hardware-independent apply (the same image drops onto partitions of different sizes and layouts). The sections below walk the actual on-disk structure, from the 208-byte header to the resource and metadata tables.

The 208-byte header: MSWIM and the resource offsets

Every WIM opens with a fixed-size header, the structure Microsoft names _WIMHEADER_V1_PACKED, 208 bytes long, at file offset 0. All its integers are little-endian. The first field is an 8-byte ImageTag holding the ASCII bytes MSWIM and three null bytes (4D 53 57 49 4D 00 00 00), which is the signature a parser checks first.

_WIMHEADER_V1_PACKED (offset 0, 208 bytes)
  ImageTag[8]          "MSWIM\0\0\0"      signature
  cbSize      uint32   header size (208)
  dwVersion   uint32   e.g. 0x00010D00
  dwFlags     uint32   FLAG_HEADER_COMPRESSION etc.
  dwCompressionSize uint32   compression chunk size
  gWIMGuid[16]         unique WIM GUID
  usPartNumber uint16  this part number (SWM split)
  usTotalParts uint16  total parts
  dwImageCount uint32  number of images (indexes)
  rhOffsetTable  RESHDR  -> lookup / offset table
  rhXmlData      RESHDR  -> XML manifest
  rhBootMetadata RESHDR  -> boot image metadata
  dwBootIndex  uint32   which image is bootable
  rhIntegrity    RESHDR  -> optional integrity table

The dwFlags field records format-wide options; FLAG_HEADER_COMPRESSION (0x00000002) signals that resources are compressed, and companion flags say whether the codec is XPRESS or LZX. dwImageCount is how many separate images the file carries, which is why one install.wim can present Home, Pro and Education as indexes 1, 2 and 3. The three RESHDR pointers (rhOffsetTable, rhXmlData, rhBootMetadata) are each a resource header giving the offset, on-disk size and original size of a major structure, so a reader jumps straight to the lookup table, the XML, or the boot metadata without scanning the file.

Resource headers and compression

WIM stores everything — file contents, metadata, XML — as resources, and each is described by a resource header (RESHDR). The header holds a 7-byte offset, a flags byte, a 7-byte compressed size and a 7-byte original (uncompressed) size. When the flags mark a resource compressed, its data is split into fixed chunks (commonly 32 KB) and each chunk is compressed independently with XPRESS (fast, LZ77-based) or LZX (higher ratio, the same family used in Microsoft CAB). A chunk table at the start of the resource lists where each compressed chunk begins, so a reader can decompress and seek to any point without inflating the whole resource.

The ESD variant (.esd, Electronic Software Download) is the same container with a stronger codec, LZMS “recovery” compression, plus encryption, which is why Windows Update and the Media Creation Tool ship ESD rather than plain WIM: smaller download, same structure underneath.

The lookup table: single-instance storage by hash

The heart of a WIM is the lookup table (offset table), pointed to by rhOffsetTable. It is an array of entries, one per unique stored resource, and each entry pairs a resource header with a 20-byte SHA-1 hash of the file’s uncompressed contents and a reference count.

This hash is what makes single-instance storage work. Before a file is added to the image, its SHA-1 is computed; if that hash already appears in the lookup table, the file is not stored again, and the existing entry’s reference count is incremented instead. The metadata for both locations simply points at the same resource. A Windows image contains thousands of duplicated files across editions and languages, so deduplicating by content hash is why a multi-edition install.wim is far smaller than the sum of its editions. The SHA-1 doubles as an integrity check: on apply, the extracted bytes are re-hashed and compared, catching silent corruption.

Metadata resources and the XML manifest

Each image inside the WIM has its own metadata resource, a compressed resource that encodes the directory tree: for every directory and file it records the name, attributes, timestamps, security descriptor, and, crucially, the SHA-1 hash of the file’s data. That hash is the link back into the lookup table, so the metadata says “this path has these attributes and its contents are the resource with hash X,” and the lookup table says where hash X physically lives. Directory structure and file data are thus stored separately, which is exactly what lets two images share the same underlying file bytes while presenting different trees.

Pointed to by rhXmlData is the XML manifest, a UTF-16 document (with a byte-order mark) that describes each image at a human level: its index, name, description, edition, total file and directory counts, and byte sizes. This is what dism /Get-WimInfo /WimFile:install.wim reads and prints. The manifest is metadata about the images; it does not itself hold file data.

Browsing, mounting and applying a WIM

Because a WIM is an archive of files rather than a disk sector image, you do not burn it. Three access patterns cover almost every need. To pull one file or driver out, open the .wim in 7-Zip or PeaZip and extract it like any archive; the tool reads the metadata and lookup table to resolve paths to resources. To modify an image in place, DISM mounts it as a folder (dism /Mount-Wim /WimFile:install.wim /Index:1 /MountDir:C:\mount), exposing the tree so you can inject drivers or updates, then commits the changes back into the WIM. To deploy it, dism /Apply-Image writes the files onto a formatted target partition.

Two related extensions come from the same tooling. A .swm is a split WIM: DISM breaks a large .wim into numbered chunks (the usPartNumber/usTotalParts header fields track them) so an install.wim over 4 GB fits on a FAT32 USB stick, and the parts are reassembled transparently on apply. Cross-platform, wimlib (wimlib-imagex) reads, extracts, captures and converts WIM, ESD and SWM on Windows, Linux and macOS, and offers a FUSE mount on Linux.

Integrity, and what a WIM can carry

A WIM is passive data, not a program, so the container will not execute anything by being opened. The realistic caution is about contents rather than the file itself: a WIM can hold an entire Windows install — system binaries, drivers, scripts — so a tampered or unofficial image can carry altered system files. The defence is provenance and the format’s own checks. Prefer images from a genuine Microsoft ISO, and rely on the optional integrity table (pointed to by rhIntegrity), which stores SHA-1 digests over the WIM’s own data blocks so DISM can verify the file has not been altered before applying it. On apply, the per-resource SHA-1 in the lookup table is re-checked against the extracted bytes, so corruption or tampering in the file data surfaces as a hash mismatch rather than a silently broken install. Applying an image also overwrites the target partition, so the one operational risk worth naming is selecting the wrong destination drive in a DISM apply command.

References