Skip to content
heic.fyi

Learn

What is HEIC? What's inside a HEIC file

HEIC is a photo file format. The .heic extension marks an image stored in the HEIF container and compressed with HEVC, the codec also called H.265. iPhones write HEIC when the camera is set to High Efficiency. Below: how HEIC, HEIF, HEVC and AVIF fit together, and what is physically inside one.

By the heic.fyi teamUpdated 14 min read

Key takeaways

  • HEIC = HEIF container + HEVC codec. HEIF is the file format (ISO/IEC 23008-12); HEVC is the same codec as H.265; .heic is the extension and the heic brand for the combination.
  • A HEIC is a small index plus a lot of compressed data. In a file we generated, the boxes that describe the picture were 1,289 bytes of 2,658,148 (0.05%); the rest was image data.
  • One photo can be many items. Tiles, a thumbnail, Exif and auxiliary images (alpha, depth, HDR gain maps) are separate items that point at each other.
  • HEIC can be lossless, but phone photos are not. We made a pixel-identical lossless HEIC, and found the default lossless setting was not.
  • The container is a standard; the codec is licensed. HEVC is covered by patent pools, which is why support depends on the software you use.
On this page
  1. The answer in one paragraph
  2. HEIF vs HEIC vs HEVC vs AVIF
  3. A short, sourced history
  4. What is physically inside a HEIC
  5. Is HEIC lossless?
  6. Bit depth and colour
  7. Why a HEIC is smaller than a JPEG
  8. Patents and licensing
  9. Who can open it
  10. When to use HEIC, and when not to
  11. What to do with a HEIC file

The answer in one paragraph

A HEIC file is an image stored in the High Efficiency Image File Format (HEIF) with its pixels compressed by HEVC (High Efficiency Video Coding). HEIF is a container: it holds a primary image and, optionally, a thumbnail, metadata such as Exif, tiles and extra images. HEVC is the compression inside it. Apple's High Efficiency camera setting (opens in a new tab) writes HEIC on iPhone 7 and later; choosing Most Compatible writes JPEG instead.

HEIF vs HEIC vs HEVC vs AVIF

These four names live on different layers, which is why they are so often mixed up. Two layers describe the file (the container and the extension and brand that name it) and one describes the pixels (the codec).

HEIF is the container; .heic, .heif and .avif are families of files that differ by brand and codecOne container standard, HEIF (ISO/IEC 23008-12, built on the ISO base media file format), sits under three families of files. A .heic file declares the brand heic or heix and holds HEVC. A .heif file declares mif1 and its codec is not fixed by the brand. A .avif file declares avif and holds AV1.Container: HEIF, ISO/IEC 23008-12Built on the ISO base media file format (14496-12).heicHEIF holding HEVCftyp brand:heic, heix, heim, heiscodec:HEVC (the codec also named H.265).heifHEIF, any codecftyp brand:mif1 (msf1 for sequences)codec:not fixed by the brand.avifHEIF holding AV1ftyp brand:avif (avis for sequences)codec:AV1
One container, three families of files. The extension is a label; the brand inside the file and the codec are what a program actually checks. Sources: IANA media type registrations, Nokia's HEIF technical page, the AVIF specification.
The names, and what each one actually is
NameWhat it isLayer
HEIFThe image container format, ISO/IEC 23008-12, built on the ISO base media file format (ISO/IEC 14496-12). It stores images as items, and can carry thumbnails, metadata and image sequences.Container
HEVC / H.265A compression codec. HEVC and H.265 are one codec under two names: ITU-T H.265 and ISO/IEC 23008-2 (MPEG-H Part 2). HEIC stores still pictures compressed with it.Codec
HEICA HEIF file whose images are HEVC-coded. .heic is the extension; heic is also a brand in the file header. IANA registers the media type image/heic.Extension and brand
HEIXA brand for HEVC images using the extended profiles, such as Main 10 and the range extensions (10-bit and beyond). IANA lists it under the same image/heic type as heic.Brand
HEIFS, HEICSExtensions for image sequences (bursts, animations) rather than single images; sequences use different brands (msf1, hevc, hevx) and -sequence media types.Extension
AVIFHEIF holding AV1-coded images. Brand avif (avis for sequences), extension .avif, media type image/avif.Extension, brand and codec
MIAFA set of extra constraints on HEIF (ISO/IEC 23000-22) for interoperability. Files from libheif list miaf as a compatible brand, as in our file below.Constraints

Sources: Nokia HEIF technical page, IANA image/heic registration, Library of Congress format description, the AVIF specification v1.2.0, Via LA's HEVC licence page (for the ISO/IEC 23008-2 number).

The filename is a label; the brand is in the file

IANA's registration says there is no magic number: the way to recognise a HEIF file is the ftyp box at the start, which lists a major brand and compatible brands. Nothing stops a file's name and its brand from disagreeing, because the name is only a label. Here are the first 28 bytes of the HEIC we generated for this article, decoded.

The first 28 bytes of a HEIC file, decodedSeven four-byte groups make up the ftyp box at the start of the file created for this article: a size of 28, the box type ftyp, the major brand heic, a minor version of zero, and three compatible brands, mif1, heic and miaf.hex bytesas textmeaning00 00 00 1C(number)box size: 28 bytes66 74 79 70ftypbox type68 65 69 63heicmajor brand00 00 00 00(number)minor version6D 69 66 31mif1compatible brand68 65 69 63heiccompatible brand6D 69 61 66miafcompatible brand
Real file: the ftyp box of a HEIC created with libheif and x265 for this article (not an iPhone file). Major brand heic; compatible brands mif1 (generic HEIF), heic and miaf.

This is why a viewer can support HEIF and still fail on a HEIC: reading the container is one job and decoding HEVC is another. The HEIC viewer and the tools below read the brand, not the filename.

A short, sourced history

Timeline of HEVC, HEIF and HEIC, 2013 to 2025HEVC (H.265) was approved in April 2013. HEIF work began around 2013, a committee draft followed in January 2014, and the specification was technically complete in June 2015. Apple's iOS 11 and macOS 10.13 added HEIC in 2017, and ISO published the first edition of ISO/IEC 23008-12 on 12 December 2017. IANA registered the image/heic and image/heif media types on 30 July 2018. The second edition followed on 29 September 2022 and the third on 3 July 2025.Apr 2013H.265 (HEVC), first editionapproved by ITU-Tsource: ITU-T2013HEIF work begins in MPEG“around 2013”source: Library of CongressJan 2014HEIF committee draft107th MPEG meetingsource: Library of CongressJun 2015HEIF technically complete112th MPEG meetingsource: Library of Congress, Apple2017iOS 11 and macOS 10.13 readHEIC; iPhone 7 and later capture itsource: Apple12 Dec 2017ISO/IEC 23008-12:2017 publishedfirst editionsource: ISO30 Jul 2018image/heic and image/heifregistered with IANAsource: IANA29 Sep 2022Second edition publishedsource: ISO3 Jul 2025Third edition publishedcurrent editionsource: ISO
Each date comes from a page we opened; the source is named on the row. ITU-T lists editions by month and year, so April 2013 has no day.

Two dates for HEIF look contradictory and are not. The Library of Congress format description says MPEG declared the specification technically complete at its 112th meeting in June 2015, and Apple's engineers, in their WWDC 2017 session, say version one became an ISO standard in June 2015. ISO's catalogue, however, lists the first edition of ISO/IEC 23008-12 as published on 12 December 2017. We report both and do not try to reconcile them further.

HEVC came first (ITU-T lists its first edition as April 2013), and HEIF was designed to store its still pictures. The Library of Congress says Apple and Nokia were heavily involved in HEIF's development; Nokia Technologies publishes an open HEIF implementation (opens in a new tab) on GitHub. Apple made it practical for everyone: Apple's support page says you need iOS 11 or macOS High Sierra or later (opens in a new tab) to view or edit HEIF media, and iPhone 7 and later can capture it.

What is physically inside a HEIC

A HEIC is a sequence of boxes, a length and a four-letter type followed by contents, as defined by the ISO base media file format (the same box structure MP4 video uses). Rather than draw this from memory, we generated a HEIC and ran this site's own bounded parser on it, the same code behind the HEIC structure viewer.

The box tree of a real HEIC file, as reported by this site's parserA 2,658,148-byte HEIC created for this article has three top-level boxes: ftyp (28 bytes), meta (1,261 bytes, 0.05 percent of the file) and mdat (2,656,859 bytes). Inside meta are hdlr, idat, iloc, iinf with 15 infe entries, pitm, iprp with ipco and ipma, and iref with dimg, cdsc and thmb.The whole file: 2,658,148 Bmdat: the compressed picture dataftyp + meta = 1,289 B (0.05% of the file)Everything that describes the picture is this small.ftyp28 Bbrands: file typemeta1,261 Bstructure, no pixelshdlr33 Bhandler declarationidat16 Bsmall inline datailoc316 Bwhere item bytes sitiinf329 Bitem list, 15 entriesinfe ×1521 Beach, one per itempitm14 Bprimary item = 1iprp465 Bitem propertiesipco345 B7 shared property boxesipma112 Bwhich item uses whichiref76 Blinks between itemsdimg36 Bgrid made of tilescdsc14 BExif for the imagethmb14 Bthumbnail of imagemdat2,656,859 Bpixels + Exif bytes
Real file: the box tree exactly as the parser reported it (sizes in bytes). The strip at the top is drawn to scale: ftyp and meta together are too thin to see.
The boxes in that tree, and what each one does
BoxSize hereWhat it holds
ftyp28 BFile type: the major and compatible brands (see the bytes above).
meta1,261 BThe container for everything that describes the image items.
hdlr33 BA handler declaration saying what kind of content meta describes.
pitm14 BWhich item is the primary image: item 1 here.
iinf, infe329 B, 21 B eachThe list of items. One infe entry per item gives its id and type (grid, hvc1 for an HEVC image, Exif).
iloc, idat316 B, 16 BWhere each item's bytes are, as offsets into mdat. Item 1, the grid, has no file offset in iloc; its 8 bytes appear to be the payload of the 16-byte idat box.
iprp: ipco, ipma465 B (345 B, 112 B)Item properties. ipco holds the properties (dimensions ispe, HEVC decoder settings hvcC, colour colr, bit depth pixi); ipma says which items use which. Seven property boxes serve every image item, so the twelve tiles share one set.
iref: dimg, thmb, cdsc76 BTyped links between items: dimg (the grid is derived from these tiles), thmb (a thumbnail of), cdsc (a description of, used for Exif).
mdat2,656,859 BThe media data: the compressed tiles, thumbnail and Exif block, concatenated.

Box meanings follow ISO/IEC 14496-12 and 23008-12 as described by the Library of Congress and Nokia; the sizes are from our parser's output on the example file.

The shape is the point: everything that tells a program how to read the file is in meta, at the start, and costs about a kilobyte. A reader can parse meta, find the primary item or the thumbnail, and jump straight to its bytes without decoding anything else. Apple's WWDC 2017 session makes this argument for putting thumbnails early in the file: it allows displaying a large number of HEIF images "without the need to parse the whole file".

Items: what the parser found

Real file: the item table, condensed (twelve tile rows folded into one)
ItemTypeSizeNotes
1grid8 BThe primary image. Declared 4032 × 3024, 8-bit, 3 channels. Not hidden. It contains no pixels: it says how to assemble the tiles.
2 to 13hvc1202,985 to 230,441 B eachTwelve HEVC-coded tiles, each 1024 × 1024, each flagged hidden so a viewer does not list them as separate photos.
14Exif208 BThe Exif block, hidden, linked to item 1 by cdsc.
15hvc112,842 BThe thumbnail: HEVC, 320 × 240, linked to item 1 by thmb.

Produced by parseHeifStructure() on the example file. The parser reads iloc, iinf, ipma and iref; it does not decode pixels.

A big photo is a grid of independent tiles

Our 4032 × 3024 image is stored as twelve tiles because we asked for 1024-pixel tiles. Without that setting, the same image was a single hvc1 item. So tiling is an encoder choice, not a law of the format. Apple's WWDC 2017 session says iOS 11 encodes images using 512 × 512 pixel tiles positioned in a grid, and lists the benefits: parallel decoding, lower memory use when resizing and fast cropping. By that rule a 4032 × 3024 iPhone photo would be 8 × 6 tiles. We have not opened an iPhone file, so that count is our arithmetic, not an observation.

A 4032 by 3024 photo stored as 12 independent HEVC tilesIn the HEIC created for this article, the primary item is a grid of 4 columns by 3 rows. Each of the 12 tiles is its own 1024 by 1024 HEVC item with its own byte range, between 202,985 and 230,441 bytes. The tiles cover 4096 by 3072 pixels, so the last column and row are cropped to the 4032 by 3024 output.4,032 px wide3,024 px tall#2228 kB#3229 kB#4230 kB#5214 kB#6227 kB#7227 kB#8225 kB#9213 kB#10216 kB#11215 kB#12215 kB#13203 kBDashed line: the 4032 × 3024 picture you see.Tiles cover 4096 × 3072; 64 px and 48 px are cropped.12 tiles = 12 separate hvc1 items, 1024 × 1024 each.Sizes differ (203 kB to 230 kB) because content does.
Real file: item 1's twelve tiles, in the order the dimg reference lists them, with each tile's byte size from the parser. The tiles cover slightly more than the picture; the grid crops the overhang.

Everything else is an item pointing at an item

How items point at each other in a real HEIC fileIn the file created for this article, item 1 is the primary image, a grid. It references 12 tile items by dimg. A thumbnail item (15) points at it with thmb, and an Exif item (14) points at it with cdsc. In a second file, an alpha plane item points at the main image with auxl.FILE 1: PHOTO WITH THUMBNAIL AND EXIFitem 1: gridprimary imagepitm points hereitem 15thumbnail320 × 240thmbitem 14Exif data208 bytescdscitems 2–1312 HEVC tiles, hiddendimgbuilt fromFILE 2: PHOTO WITH TRANSPARENCYitem 2alpha plane1 channel, auxiliaryitem 1primary imageauxlMarked by an auxC property: …:auxid:1Not in these files (we could not make one)Depth maps and HDR gain maps: further auxiliary items.
Real files: the reference graph of the example photo, and a second generated file whose transparency is stored as an auxiliary alpha item. Arrows run from the item that holds the reference to the item it points at.
  • Thumbnail. A separate small image, linked with thmb. Apple's session describes a 320 × 240 HEVC thumbnail, four times the area of a common 160 × 120 JPEG thumbnail. The thumbnail extractor and the thumbnail extractor cover pulling it out.
  • Exif and XMP. Metadata blocks stored as their own items, linked to the image with cdsc.
  • Auxiliary images. An image that complements the main one and is not normally shown. Apple's session names an alpha plane or a depth map as examples, and says Apple stores depth as an auxiliary image coded with HEVC's monochrome profile. Our second file shows the alpha case: an auxl reference to the primary image.
  • HDR gain maps. Apple's WWDC 2024 session describes an SDR base image plus a gain map, and says a Core Image save includes the gain map as an auxiliary image along with the base SDR image. The file holds ingredients and a recipe, not a finished HDR picture, in Apple's words.
  • Extra full-size images. A HEIC can hold several pictures with one marked primary. A macOS dynamic wallpaper is one: a stack of frames plus an XMP note saying when to show each; see HEIC dynamic wallpaper.
  • Live Photos are not inside the HEIC. Apple's 2016 session describes a Live Photo as two assets, a still image file and a QuickTime movie, tied together by a shared UUID. That session predates HEIC (the still was then a JPEG); we have not opened a Live Photo file, so treat this as the design Apple described, not an inspection.

Is HEIC lossless?

The format can be; the files your phone writes are not. Nokia's HEIF site and the Library of Congress both say HEIF supports lossy and lossless storage, and HEVC includes a lossless mode. We found no Apple documentation of lossless HEIC capture, and Apple states its saving as about 2x against JPEG "at the same visual quality", which is a lossy-coding comparison, not an exact-pixels one.

We tested what "lossless" means in practice. We encoded one image four ways, decoded each, and compared every pixel with the source:

Lossless HEIC exists, but the default settings were not losslessOne synthetic 1600 by 1200 image saved four ways and decoded again. Lossy HEIC at quality 60 was 111 kilobytes and not pixel-identical. A HEIC saved with the lossless flag at default 4:2:0 chroma was 733 kilobytes and still not identical. A HEIC saved lossless at 4:4:4 with the identity matrix was 1.90 megabytes and pixel-identical, similar to a 2.06 megabyte PNG. Uncompressed RGB would be 5.76 megabytes.HEIC, lossy (quality 60)111 kB✗ not pixel-identicallargest pixel error 69 of 255HEIC, “lossless”, 4:2:0 default733 kB✗ not pixel-identicallargest pixel error 65 of 255HEIC, lossless, 4:4:4 + identity matrix1.90 MB✓ pixel-identicalevery pixel matchesPNG (lossless)2.06 MB✓ pixel-identicalevery pixel matchesBar length is relative to uncompressed RGB (5.76 MB, full width).One synthetic test image; ratios vary with content.
Measured for this article: a 1600 × 1200 synthetic RGB image through pillow-heif 1.8.0 (libheif 1.23.4, x265 4.2), decoded and compared pixel by pixel. One test image only, so the sizes are illustrative.
  • The default lossless setting was not pixel-identical (largest error 65 of 255). The likely cause is 4:2:0 chroma: the colour channels are stored at quarter resolution, so detail is already gone before lossless coding starts.
  • With 4:4:4 chroma the error shrank to 1, and with the identity matrix (matrix coefficients 0, so no RGB-to-YCbCr conversion) the result was bit-exact. That file was 1.90 MB, close to the 2.06 MB PNG of the same pixels.
  • So a tool that says "lossless HEIC" is worth checking. Chroma layout and colour conversion decide whether it is.

Bit depth and colour

JPEG's lossy modes carry 8 bits per channel (Library of Congress (opens in a new tab)), which is 256 levels per colour. HEVC's original Main Still Picture profile is also 8-bit, 4:2:0 and one picture (Sullivan et al. (opens in a new tab)); Apple's session says that is the profile iOS 11 used for images. The heix brand covers the Main 10 and range-extension profiles, which add more bits per sample.

We made a 10-bit file to see what that looks like to the parser: its major brand was heix instead of heic, and the pixi property reported 10, 10, 10 bits per channel (1,024 levels). Apple's WWDC 2024 session says the most modern way to save HDR is 10-bit HEIF with a PQ colour space. Colour is declared by a colr property, either as numeric colour codes (nclx) or an embedded ICC profile; in our files it was nclx with full-range flag set. We did not verify which of those forms Apple's cameras write, or how Display P3 is signalled, so we make no claim about them here. The HEIC HDR guide goes into bit depth, PQ and gain maps, and Can a HEIC file contain a virus? covers safety.

Why a HEIC is smaller than a JPEG

Apple's engineers put the saving at "an average of 2X compression compared to JPEG containing the same visual quality". It is an average, not a guarantee: it depends on content, the encoder and the quality target, and the HEVC authors' roughly 50% goal was set for video. Three design differences, from the HEVC authors' own overview, explain most of it:

  1. Prediction. Instead of coding every block from scratch, HEVC predicts a block from neighbouring pixels that were already decoded and stores only the difference. Its intra prediction offers 33 angular directions plus planar and DC modes.
  2. Bigger, more flexible blocks. HEVC divides a picture into coding tree blocks of up to 64 × 64 samples and uses transforms from 4 × 4 to 32 × 32. JPEG's lossy modes work on fixed 8 × 8 blocks. Flat areas can be coded as a few large blocks; detail gets small ones.
  3. Better entropy coding. The last stage packs the numbers into bits. HEVC uses context-adaptive binary arithmetic coding (CABAC), which adapts to the data as it goes.

The cost is work: HEVC encoders and decoders are far more complex than JPEG's, so hardware support matters. For a photo-by-photo size comparison with caveats, see HEIC vs JPG. We give no size ratio from our synthetic test image, because a generated picture does not behave like a photograph.

Patents and licensing

The HEIF container is an ISO standard. HEVC, the codec, is covered by patents licensed through pools. Access Advance (opens in a new tab) says its HEVC Advance pool licenses patents essential to HEVC on fair, reasonable and non-discriminatory terms. Via LA (opens in a new tab) runs a second HEVC/VVC licence, says it extends to devices implementing the technology, and adds that each user must determine its own licensing needs. Both are about companies shipping encoders and decoders; neither page describes anything a person viewing their own photo has to do.

AVIF exists partly as an alternative. The Alliance for Open Media's patent licence (opens in a new tab) grants a perpetual, worldwide, non-exclusive, royalty-free licence for its specifications. We did not verify what individual vendors pay or how Windows and Apple license HEVC, so we say nothing about that. See the Windows guide for the practical side.

Who can open it

Apple's support page says iOS 11 or later and macOS High Sierra or later can view, edit and duplicate HEIF media. Elsewhere it varies by operating system, app and browser, and it changes. These pages track the details: browser support, opening HEIC on Windows, HEIC on iPhone and converting on a Mac, HEIC on Linux and HEIC in Photoshop, Lightroom and GIMP. If a file will not open, start with HEIC will not open.

When to use HEIC, and when not to

A practical rule of thumb
SituationChoiceWhy
Photos staying on Apple devices, storage is tightKeep HEICSmaller files at similar visual quality; it is what Apple's High Efficiency setting writes.
Archiving originalsKeep the HEICIt holds the thumbnail, metadata and auxiliary items; a JPEG copy is a lossy derivative.
Sending to people on unknown software, or a form or portal that asks for JPEGConvert to JPGJPEG opens nearly everywhere. Apple's sharing flow may do this for you.
Editing repeatedlyAvoid lossy re-savesEvery lossy re-save loses detail; export a final copy at the end.
Converting a JPEG to HEICUsually pointlessThe detail JPEG discarded does not come back; you only change the wrapper.

What to do with a HEIC file

Frequently asked questions

Try it yourself

Related reading

Sources

How we research and correct: editorial policy.

Written by the heic.fyi team · Last updated: · Spotted an error? Tell us.