The IFF file (.iff, .ilbm, .lbm)

IFF, the Interchange File Format, is a general way of storing data in tagged chunks, published by Electronic Arts on 14 January 1985 as "EA IFF 85". It was written by Jerry Morrison with a committee that included EA and Commodore-Amiga staff, released to the public domain, and adopted as the Amiga's standard file format: pictures, sounds, music, animations and text could be moved between programs from different companies.

The specification's motto, borrowed from Alan Kay, was "Simple things should be simple and complex things should be possible." IFF itself defines only the containers. What goes inside is set by separate standards for each form type, and the most famous of them is ILBM, the InterLeaved BitMap, defined in January 1986 for pictures. Electronic Arts' Deluxe Paint wrote ILBM files, and so did most Amiga graphics software.

So when someone says "an IFF image", they mean an ILBM picture in an IFF container. The file extension varies:

• No extension: on the Amiga, files were recognised by their content, so original Amiga pictures often have no extension at all.
• .iff or .ilbm: the usual extensions when Amiga files are copied to other systems.
• .lbm: common on the PC, where Deluxe Paint and many DOS games of the late 1980s and early 1990s used IFF images. Some of those files use a simpler PBM form type (one byte per pixel instead of bitplanes), which has nothing to do with Netpbm's PBM format.
• .iff from Autodesk Maya: a different image format with the same extension; see below.

Every piece of an IFF file is a chunk with the same layout, so a program can read the parts it understands and skip the rest:

• ckID: 4 ASCII characters, such as BMHD or BODY.
• ckSize: a 32-bit big-endian number, the length of the data.
• data: that many bytes, then a zero pad byte if the length is odd, so every chunk starts at an even position.

Four chunk types hold other chunks:

Forms can nest: an ANIM animation, for example, is a FORM ANIM holding one FORM ILBM per frame. On the Amiga, the system's iffparse.library did the walking for programs.

ILBM stores pixels the way the Amiga's display hardware wanted them: as bitplanes. A picture with 5 planes has 32 colours, and each plane holds one bit of every pixel's colour number. In the file, each row of the image is written as one row from plane 0, then one from plane 1, and so on: the planes are interleaved row by row, hence the name.

Two Amiga display modes are recorded in the CAMG chunk and change how pixels are read:

• HAM (Hold-And-Modify): with 6 planes, the top 2 bits of each pixel say whether the other 4 are a palette colour, or a new value for just the red, green or blue of the pixel to its left. That's how the Amiga showed photos with thousands of colours. A viewer that ignores HAM shows garbage.
• Extra Half-Brite (EHB): with 6 planes, the sixth bit means "palette colour at half brightness", giving 64 colours from a 32-colour palette.

ByteRun1 is ILBM's only standard compression, a form of run-length encoding (the same scheme as Apple's PackBits). A control byte *n* from 0 to 127 means "copy the next *n* + 1 bytes"; from −1 to −127 it means "repeat the next byte −*n* + 1 times"; −128 means nothing. It works well on flat areas of colour, the typical pixel art of the time, and badly on noise.

A 3D artist's .iff file is probably a Maya IFF image: the native render and texture format of Autodesk Maya. Autodesk describes IFF as "a generic structured file access mechanism" and uses it for 8- or 16-bit RGB images with optional alpha and an optional 32-bit floating-point depth (Z-buffer) map.

Maya IFF files start with FOR4 rather than FORM, followed by a length and the form type CIMG; the UK National Archives' PRONOM registry uses this as the format's signature. Amiga ILBM viewers can't read them. To open one, use Maya itself, or a compositing or image tool with a Maya IFF reader, and convert to EXR, TIFF or PNG for sharing.

Browsers and the built-in viewers of Windows and macOS don't read ILBM. These do:

• IrfanView (Windows) and XnView open IFF pictures; check HAM and masked images, which are the parts readers most often get wrong.
• FFmpeg decodes ILBM, the PC PBM variant and several other IFF image types: ffmpeg -i picture.iff picture.png.
• Netpbm: ilbmtoppm picture.iff | pnmtopng > picture.png. ilbmtoppm handles 1 to 16 planes, HAM, Extra Half-Brite, 24-bit images and palette-only files; ppmtoilbm goes the other way.
• GIMP has an optional IFF/ILBM import plug-in, but not every build includes it; the Debian security tracker notes packages built without it.
• On an Amiga, real or emulated, the original software opens them, and so does the system's own picture support.

• The picture looks stretched or squashed. Amiga pixels weren't square: a 320 × 200 screen had pixels about 10:11 wide to tall, and interlaced or high-resolution modes differ again. The aspect ratio is in BMHD; scale the converted image if proportions matter.
• Colours are scrambled noise. The picture probably uses HAM and the viewer ignored the CAMG chunk. Try another viewer or ilbmtoppm -isham.
• Colours are slightly too dark. Old writers stored 4-bit palette values in the top half of each byte (F0 instead of FF). The 1988 revision asks writers to scale them; viewers can't always tell.
• The file won't open at all. Check the first 12 bytes. FORM … ILBM is an Amiga picture, FORM … PBM the PC variant, FORM … 8SVX or AIFF a sound, FOR4 … CIMG a Maya image, and AT&TFORM a DjVu document.

IFF pictures contain no scripts or macros. The risk is in decoders, which are often old, rarely used code paths that get little testing:

• Crafted chunk sizes. A chunk can claim to be longer than the file, or a ByteRun1 stream can try to write past the end of a row. In 2026 a flaw of this kind in GIMP's IFF import plug-in (CVE-2026-82324) allowed out-of-bounds reads from crafted files. Keep viewers updated, and open files of unknown origin in up-to-date software.
• Text chunks. ANNO, AUTH and (c) chunks can carry names and notes that viewers don't show.
• Servers that convert uploads should check the dimensions in BMHD before decoding and limit the decoded size.