HEIF file format
High Efficiency Image Format, the general still-image profile of the HEIF container.
- MIME type
- image/heif
- Extensions
- .heif
- Category
- Images
Magic-number signature
| 0x00000004 | 66747970 | ftyp | ISO-BMFF 'ftyp' box |
| 0x00000008 | 6D696631 | mif1 | brand 'mif1' |
About the HEIF format
HEIF is the general-purpose still-image profile of the same container HEIC uses, able to hold image sequences and auxiliary data. Its 'ftyp' brand is 'mif1'. The point of that brand is what it does not say: unlike heic or avif it makes no claim about which codec compressed the pictures inside. A mif1 file is a promise about structure — that there is a meta box, that the images are items, that a primary item is named — and the codec is discovered afterwards from each item's type and properties. That is why mif1 turns up in the compatible-brands list of almost every HEIC and AVIF as well as being a major brand in its own right.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | ftyp box size | Big-endian byte length of the file-type box including this field, twenty-four for a major brand plus two compatible brands. Every integer in an ISO-BMFF file is big-endian, and the two special sizes apply here as anywhere: 1 promises a 64-bit length after the type, 0 means the box runs to the end of the file. |
| 4 | 4 | Box type | 66 74 79 70. The file-type box is required to come first, which makes this the one reliably fixed field in the format. It is shared unchanged with HEIC, AVIF, MP4, MOV and 3GP, so on its own it narrows a file to a container family and nothing more. |
| 8 | 4 | Major brand | 6D 69 66 31 for a still image or image collection. The image-sequence counterpart is msf1, which signals timed content and a different set of structural requirements. Neither brand names a codec, and that is the deliberate design choice separating HEIF from HEIC and AVIF. |
| 12 | 4 | Minor version | Informational, conventionally all zero bytes. It carries no structural meaning and a reader is not permitted to refuse a file on the strength of it. |
| 16 | variable | Compatible brands | Four bytes per brand, filling whatever is left of the box. This is where a mif1 file tells you what it actually contains — heic for HEVC items, avif for AV1 items, miaf for the interoperability profile — and a reader may open the file on any brand in the list that it understands. |
| 24 | 4 | Next box size | Where the next box header begins after a 24-byte ftyp. The whole file is traversed by adding each box's size to the current position; there is no central index and no way to resynchronise after a bad length. |
| 28 | 4 | Next box type | Normally 6D 65 74 61 — meta — which is what makes the file an image file rather than a movie. Its children do the real work: pitm names the primary item, iinf lists the items and their four-character codec types, iloc records where each one's bytes are and iprp attaches dimensions, rotation and colour information. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| HEIC | The four bytes at offset 8 and nothing else. 68 65 69 63 is a file asserting its items are HEVC; 6D 69 66 31 asserts only that the structure is a HEIF image file. In practice a mif1-major file with heic in its compatible-brands list holds exactly the same HEVC data as a heic-major one, so a converter should read both lists rather than branching on the major brand alone. |
| AVIF | Genuinely awkward, because AVIF files list mif1 among their compatible brands — a macOS-produced AVIF has avif at offset 8 and mif1 at offset 20. A detector that scans the whole ftyp box for mif1 will label most AVIFs as HEIF. Only the major brand at offset 8 says which format the file leads with, and the item types inside the meta box say which codec is actually used: av01 for AV1, hvc1 for HEVC. |
| Image sequences | The still brand is mif1 and the sequence brand is msf1, one byte apart. A msf1 file holds timed images and often a track structure alongside the items, and software written only for stills renders the first frame and stops. The extension is no help at all, since both are commonly written as .heif. |
| MP4 | Identical at offset 4, different at offset 8: isom, mp42 or avc1 for video against mif1 for images. The structural test is what the top-level boxes are — a meta box with items means a picture, moov with trak boxes means a movie — and a HEIF may legitimately contain both when it carries an image sequence. |
How these files break
- A codec the reader does not have. Because the brand is codec-agnostic, opening a mif1 file successfully proves nothing about being able to decode its contents: a HEIF holding AV1 items fails on software that only implements HEVC and the other way round. The failure looks like a corrupt file and is a capability gap, findable by reading the compatible brands at offset 16.
- Truncation. The meta box normally precedes the image data, so item dimensions and properties survive intact while the bytes they point at are gone. Readers report the right size and render nothing, or fall back to the embedded thumbnail item and appear to work until the image is opened at full resolution.
- A box size that does not match its payload. Traversal is nothing but adding lengths, so one wrong size makes the parser read arbitrary data as a box header and give up. The error message will name whatever four bytes it happened to land on, which is rarely anywhere near the actual damage.
- An item location pointing outside the file. The iloc box records each item's offset and length independently, so a file assembled or edited by a careless tool can list a primary item that starts past the end while its thumbnail remains perfectly readable. The result is a file that previews correctly and refuses to open.
- The primary item never declared. Without a pitm box a reader has to guess which of several items is the picture, and different implementations guess differently — one shows the photograph, another shows a depth map or an alpha auxiliary. Every byte is valid and the file simply displays as something else.
Where the format stands today
HEIF as a brand in its own right is mostly what you meet when a tool wants the container without committing to a codec, and it is far less common in the wild than the two named profiles built on it. Its real significance is architectural: HEIC and AVIF are both HEIF files, and the machinery that makes modern phone photography work — multiple images in one file, depth maps, alpha auxiliaries, HDR gain maps, thumbnails, non-destructive edit lists, burst sequences and derived images built by cropping or rotating another item without re-encoding — is defined here rather than in either of them. Where a plain mif1 file does show up is as an interchange or intermediate format inside imaging pipelines, and in image collections such as bursts and stacks where the container's ability to hold many related pictures is the whole reason to use it. For delivery it is the wrong choice: no browser will open a file that only claims mif1, and anything published on the web should be AVIF, WebP or JPEG. Treat the brand as a statement about structure, look at the compatible brands and the item types to learn what is actually inside, and convert before shipping.
Open HEIF files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with HEIF — compare their leading bytes.