The WAD is one of the most consequential file formats in PC gaming, and one of the simplest. Understanding its structure explains a surprising amount about why the modding culture around it developed the way it did.
The name is usually expanded as Where’s All the Data. That expansion appears in the original technical documentation, so it is at least contemporaneous rather than a later joke, though the format’s design suggests the acronym came second.
Three parts and nothing else
A WAD file has a twelve-byte header, a body of raw data, and a directory. That is the entire format.
The header records an identification string, the number of entries, and the byte offset where the directory begins. The identification string is either IWAD or PWAD. An IWAD is a base game file, self-sufficient and containing everything needed to run. A PWAD is a patch file, containing only entries that should replace their equivalents in the loaded IWAD.
That distinction is the foundation of the entire modding scene. The engine loads the base file, then loads any patch files over it, and later entries with the same name win. No installer, no file replacement, no risk to the original. Users could try a modification and remove it by not loading it next time.
The directory is a flat list
Each directory entry is sixteen bytes: a four-byte offset, a four-byte size, and an eight-byte name padded with nulls. There is no type field, no timestamp, no folder structure and no compression.
Two consequences follow immediately. Names are limited to eight characters, which is why entries carry terse names like E1M1 or PLAYPAL rather than anything descriptive. And because there are no directories, organisation had to be expressed through naming conventions instead.
The convention that emerged used marker entries: zero-length entries whose only purpose was to bracket a range. Everything between the sprite start and sprite end markers is a sprite. Everything between the flat markers is a floor or ceiling texture. The engine determines type by position relative to markers, not by anything recorded in the entry itself.
Why a level is many entries rather than one
A level is not stored as a single blob. It is a marker entry naming the level, followed by a fixed sequence of entries in a required order, each holding one aspect of the level’s geometry and contents.
- THINGS lists every object placement: monsters, items, player starts.
- LINEDEFS and SIDEDEFS describe walls, their textures and their behaviours.
- VERTEXES holds the raw coordinates those lines connect.
- SECTORS defines floor and ceiling heights, lighting and special behaviour.
- SEGS, SSECTORS and NODES hold the precomputed spatial subdivision the renderer walks.
The last group matters more than it looks. Those entries are generated by a separate tool from the level geometry, and the engine relies on them being correct for rendering and collision. An editor that changed geometry without regenerating them produced a level that looked right in the editor and behaved incorrectly in play.
This is why the node builder was a distinct, named piece of software in the toolchain rather than a hidden implementation detail, and why the quality of a node builder was something modders held opinions about.
What the format got right
The design was not obviously destined to spawn decades of modification, but three properties made it happen.
Replacement by name meant a modification only needed to include what it changed. A file altering one texture could be a few kilobytes. Distribution over a modem was practical.
The absence of compression meant the format was trivially inspectable. Anyone who could read a hex dump could work out the structure without documentation, and people did, quickly, before any official specification was published.
And the separation of patch from base meant the base file was never modified. The barrier to experimenting was near zero, because nothing could be broken permanently.
Reading one today
The format is simple enough to parse in a short script: read twelve bytes, seek to the directory offset, read sixteen bytes per entry. Modern tooling exists and is better than writing your own, but the exercise is genuinely instructive, because the structure is small enough to hold in your head entirely.
Very few formats from the period are that approachable. Most of what came later was compressed, packed and versioned in ways that require documentation to make sense of. The WAD can be understood by staring at it, and a great deal of what followed in PC modding came from that fact.