HEIC file format
High Efficiency Image Container, Apple's default photo format since iOS 11.
- MIME type
- image/heic
- Extensions
- .heic
- Category
- Images
Magic-number signature
| 0x00000004 | 66747970 | ftyp | ISO-BMFF 'ftyp' box |
| 0x00000008 | 68656963 | heic | brand 'heic' |
About the HEIC format
HEIC wraps HEVC-compressed stills in the HEIF container, cutting photo sizes roughly in half versus JPEG. It is an ISO-BMFF file whose 'ftyp' brand is 'heic'. What arrives from an iPhone is rarely a single picture, though: the same file routinely carries a thumbnail, a depth map, an HDR gain map and the unmodified original alongside a non-destructive list of edits, all as separate items indexed by a 'meta' box near the front of the file. That is the real difference from JPEG — a HEIC is a small database of images, and which one a viewer shows depends on which item it decides is primary.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | ftyp box size | Big-endian length of the file-type box, twenty-four when there is a major brand and two compatible brands. All ISO-BMFF integers are big-endian. The special values are the same everywhere in the container: 1 means a 64-bit size follows the type, 0 means the box extends to the end of the file. |
| 4 | 4 | Box type | 66 74 79 70. The file-type box must come first, so these four bytes are the only truly fixed position in the whole format, and they are shared with AVIF, HEIF, MP4, MOV and 3GP without distinction. |
| 8 | 4 | Major brand | 68 65 69 63 for a single HEVC-coded still at Main profile. Related brands cover the variants: heix for Main 10 and higher profiles, hevc and hevx for image sequences, and heim, heis, hevm and hevs for multiview. All of them are HEVC and all of them are commonly called HEIC in conversation. |
| 12 | 4 | Minor version | Informational only, conventionally 00 00 00 00. It is not a revision of the brand and a reader must not reject a file because of an unexpected value here. |
| 16 | variable | Compatible brands | A list of four-byte brands filling the rest of the box. macOS writes heic and mif1; an iPhone typically writes mif1, heic, miaf and a coding-constraint brand such as MiHB or MiHE. A reader is allowed to open the file on any brand it recognises, which is precisely why mif1 appearing here does not make the file HEIF. |
| 24 | 4 | Next box size | The header of whatever follows a 24-byte ftyp. Boxes are traversed by adding each size to the current offset and there is no other index and no resynchronisation, so a single wrong length costs everything after it. |
| 28 | 4 | Next box type | Almost always 6D 65 74 61 — meta. Inside it the pitm box names the primary item, iinf lists every item with its type, iloc gives each item's byte range and iprp holds their properties including dimensions and rotation. Everything a viewer needs to choose what to display lives there. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| AVIF | Byte for byte identical through offset 7, then 68 65 69 63 against 61 76 69 66 at offset 8. Structurally they are the same container with the same meta and item machinery; the difference is which codec compressed the item data, HEVC against AV1. That distinction decides where the file opens: HEIC needs an HEVC decoder and a patent licence, AVIF does not, and no browser except Safari will render a HEIC. |
| HEIF | The major brand at offset 8 again: heic asserts specifically that the items are HEVC, while mif1 is the codec-agnostic brand and asserts only that the file follows the image-file structure. Almost every HEIC lists mif1 among its compatible brands as well, so matching on mif1 anywhere in the box is a classic detector bug that reports HEIC files as generic HEIF. |
| QuickTime Movie | Live Photos ship as a pair — a .heic still and a .mov video with a matching content identifier — and both begin with a box size then ftyp. The brand at offset 8 separates them: heic against qt, and the MOV carries trak boxes with samples where the HEIC carries items in a meta box. Copying only one half of the pair is why a Live Photo so often arrives as a plain still. |
| JPEG | FF D8 FF at offset 0 against a box length that is usually 00 00 00 18. The camera setting behind the choice is one toggle: High Efficiency captures HEIC, Most Compatible captures JPEG, and Apple's transfer path will also transcode HEIC to JPEG on the way out to a Windows machine — which is why the same photo can arrive in either format depending on how it was copied. |
How these files break
- A missing HEVC decoder mistaken for a broken file. Windows requires a separately installed codec extension to open HEIC at all, and most browsers never will. A file that reports an error everywhere except on Apple hardware is almost always intact: confirm by checking that offset 4 reads ftyp and offset 8 reads heic before trying to repair anything.
- Truncation. The meta box sits near the front, so dimensions, orientation and the item list survive and only the image data is missing. Viewers respond inconsistently — some show the embedded thumbnail, which is a separate and much smaller item, and give the impression the file is fine until it is opened full size.
- The wrong item shown. A HEIC holds several images and the pitm box names the primary one. Software that ignores pitm and decodes the first item it finds can display the depth map, the thumbnail or the unedited original instead of the picture the user expects, which looks like corruption and is a reader bug.
- Edits lost in conversion. iOS stores adjustments non-destructively as an auxiliary item plus the untouched original, so a converter that extracts the primary item without applying them produces a technically correct file showing the photo as it was before every edit. Nothing warns that this has happened.
- A box size that does not match its contents. Because traversal is nothing but repeated pointer arithmetic over the box tree, one bad length makes the parser read a payload as a box header and abandon the rest of the file. The reported error usually names a box far from the actual damage.
Where the format stands today
HEIC has been the default capture format on every iPhone since iOS 11 in 2017 and on many Android flagships since, so it is by volume one of the most-produced image formats on earth even though almost nobody publishes in it. At matching quality it is roughly half the size of JPEG, and it carries things JPEG structurally cannot: ten-bit depth, an alpha channel, depth maps for portrait blur, burst and Live Photo sequences, HDR gain maps and non-destructive edit history. What stopped it becoming the web's format is licensing. HEVC patents are pooled across multiple holders, browser vendors declined to ship a decoder, and to this day only Safari renders one — which is the gap AVIF was created to fill with a royalty-free codec in the same container. The practical position is that HEIC is a capture and storage format, excellent at both, and that anything leaving the Apple ecosystem gets converted: to JPEG for maximum compatibility, or to AVIF or WebP for the web. Apple's own Most Compatible camera setting exists to make that conversion unnecessary for people who never wanted it in the first place.
Open HEIC 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 HEIC — compare their leading bytes.