Interchange File Format (IFF)

From ModdingWiki
Jump to: navigation, search

The Interchange File Format (IFF) was created by Electronic Arts in 1985 to help introduce some standards to the multitude of custom file formats that were in use at the time. As it was developed on the Amiga and related platforms, all the length fields are stored in big-endian format, so in 1991 Microsoft introduced the Resource Interchange File Format (RIFF) which is largely based on this standard, except that it uses little-endian numbers better suited to the Intel platforms used by Microsoft software.


The file format is arranged as a series of chunks. Certain chunks can be nested inside other chunks, and beyond the initial "root" level object, the nesting is entirely user-defined depending on the file format.


The FOURCC data type is used to identify each chunk type. It must conform to the following rules:

  • Each character must be in the ASCII range 32 to 126 inclusive. This includes alphanumeric characters and punctuation, but excludes control characters and extended (8-bit) ASCII. Trailing spaces are allowed, but embedded spaces are not.
  • FORM, CAT and PROP type IDs may be used as filename extensions, so lowercase letters and punctuation are forbidden. Only uppercase letters and numeric digits may be used for these, and trailing spaces are permitted if the length is less than four characters.


A chunk is defined as follows:

Type Name Description
FOURCC chunkID Chunk name
UINT32BE lenChunk Length of chunk data, in bytes. Does not include the pad byte.
BYTE[lenChunk] content Actual data of the chunk
BYTE pad Optional padding byte, only present if lenChunk is not a multiple of 2.

Standard chunks

Most of the chunk types and their content are specific to the data being stored, however there are three chunks that are well-defined for all IFF files. These standard chunks follow the same structure as above, however the content for each chunk is defined as follows:

Type Name Description
FOURCC formatID Code specifying layout of child chunks
CHUNK[] chunk One or more additional chunks

If a chunkID is FORM and the formatID is BLAH then it is written below as FORM:BLAH. These are the standard chunkIDs:

This is a self-contained data section. The FORM chunk could be copied out and stored in an object by itself, and that file would be a valid object. Composite objects can be made up of multiple FORM chunks, such as an animation which stores each frame in a FORM chunk, and when one of these chunks is saved into a separate file it becomes a valid image file with that single frame/picture in it.
CAT  (note the trailing space on this code)
This chunk is a simple untyped list of objects. The spec hints that all the objects in a CAT chunk could be concatenated without corrupting the data, and suggests that because of this, nested chunks within a CAT do not really make sense and would be better off being merged into one chunk rather than nested. If the CAT chunk's contents should not be merged, then a LIST chunk should be used instead.
Similar to a CAT, this chunk holds a list of objects. Unlike CAT, the objects are structured and the LIST can contain PROP chunks which apply properties to all objects within the LIST. The spec says that unlike CAT chunks, the contents of LIST chunks should not be merged without understanding their contents. The LIST chunk should contain one or more FORM chunks, preceded by zero or more PROP chunks, with each PROP holding common chunks that apply to the FORM ones. This way duplicate chunks are removed from each FORM and are instead listed once in the PROP.
This chunk can only appear inside a LIST chunk, and contains chunks that should apply to all other chunks within the same parent LIST. The chunk type matches the FORM type, so all the chunks inside PROP:ILBM should apply to all sibling FORM:ILBM chunks.
____ (four spaces)
These "filler" chunks contain no meaningful data and should be ignored, and can be omitted/deleted if the file is being rewritten.

FORM types

This is a list of all known FORM format IDs.

FORM FOURCC File format
FOR1 to
LIS1 to
CAT1 to
Reserved and not permitted as FORM types
8SVX 8-bit sampled sound voice
ANBM animated bitmap
FNTR raster font
FNTV vector font
FTXT formatted text
GSCR general-use musical score
ILBM interleaved raster bitmap image, see LBM Format
PDEF Deluxe Print page definition
PICS Macintosh picture
PLBM (obsolete)
USCR Uhuru Sound Software musical score
UVOX Uhuru Sound Software Macintosh voice
SMUS simple musical score
VDEO Deluxe Video Construction Set video
eXtended MIDI music, see XMI Format


In this example structure:

      • PROP:ONE 
        • INF1
      • PROP:TWO 
        • INF2
      • FORM:ONE 
        • DATA
      • FORM:ONE 
        • DATB
      • FORM:TWO 
        • DATC

There are three data files combined into the one file. Some common data chunks have been removed (INF1 and INF2) from their respective FORM files, as they were the same for each file and only needed to be listed once in the combined file. The PROP chunks indicate this shared-use with their types matching the FORM types, so the chunks within PROP:ONE  should be used with FORM:ONE  to create a valid file that could be saved separately:

    • INF1
    • DATA

External links