PicaJet
Search Build shortlist

Reference Formats

HEIF

An ISO/IEC 23008-12 container standard for storing images, bursts and metadata independent of codec, of which Apple's HEVC-based HEIC is the dominant real-world implementation.

Extension

.heif

Full name

High Efficiency Image File Format

Introduced

Draft finalized October 2015; published as ISO/IEC 23008-12:2017

Vendor

MPEG (Moving Picture Experts Group), ISO/IEC JTC 1

What is inside the container

HEIF is codec-agnostic by design — the standard defines the ISOBMFF-based container structure for storing single images, image collections, bursts, and sequences alongside thumbnails and metadata, without mandating a specific compression codec. In practice, nearly every HEIF file in the wild uses HEVC encoding, making it functionally identical to HEIC in metadata capability: full EXIF and XMP item support per the ISO spec.

How to open it

macOS Preview and Photos (same native support as HEIC, since virtually all real-world HEIF is HEVC-encoded)
Cross-platform GIMP with libheif, Adobe Photoshop, ExifTool
Web browsers Safari only, natively — same limitation as HEIC since both rely on HEVC

For archives

Same guidance as HEIC: convert to TIFF or JPEG for long-term DAM master storage. HEIF's ISO standardization is a modest positive for long-term legibility compared to HEIC being an Apple-branded format name, but the practical risk profile — HEVC patent licensing, thin non-Apple ecosystem support — is effectively identical, since almost all real-world HEIF files are HEVC-encoded.

HEIF is the ISO/IEC container standard (ISO/IEC 23008-12) that MPEG finalized in October 2015 and published in 2017, part of the broader MPEG-H family. Unlike HEIC, which names a specific Apple product, HEIF describes only how images, image sequences, and their metadata are packaged — it deliberately does not mandate a compression codec, so in principle a HEIF file could wrap any codec’s data.

In practice this distinction rarely matters for a DAM: virtually every HEIF file encountered in the wild is HEVC-encoded, making it functionally identical to HEIC in every way that matters for ingest, preview generation, and metadata extraction. The container was explicitly designed to also carry thumbnails and auxiliary images alongside the primary image, a structural advantage over JPEG or PNG for storing image sequences (bursts, focus stacks) as a single logical asset.

For a DAM taxonomy, the cleanest way to think about the relationship is: HEIF is the format family and container standard, HEIC is its dominant real-world instance. Every .heic file is a valid HEIF file, but a DAM will almost never encounter a non-HEVC HEIF file in practice — so cataloging, preview-generation, and archival-conversion policy can treat the two identically, with HEIC simply being the file extension Apple’s ecosystem happens to use.

Frequently asked

Is HEIF meaningfully different from HEIC for DAM purposes?

Barely, in practice. HEIF is the codec-agnostic ISO container standard, while HEIC is Apple's HEVC-encoded implementation of it — but virtually every real-world HEIF file is HEVC-encoded, so DAM cataloging, preview generation, and conversion policy can treat the two identically.

Should a DAM archive HEIF files as masters?

Same guidance as HEIC: convert to TIFF or JPEG for long-term storage. HEIF's ISO standardization is a modest positive for long-term legibility, but the practical risk profile — HEVC patent licensing, thin non-Apple ecosystem support — is effectively identical.

Does HEIF display in web browsers?

Safari on macOS and iOS is the only major browser with native HEIF support, since HEIF images in practice carry HEVC-encoded data. Chrome, Firefox, and Edge don't decode HEIF client-side, largely due to HEVC's licensing costs. For a DAM, this means HEIF files should never be linked directly into web pages or asset previews — generate JPEG or WebP derivatives at ingest so galleries, embeds, and shared links render consistently everywhere.

What metadata does HEIF support?

The ISO spec defines EXIF and XMP as metadata items linked to the primary image item within the ISOBMFF container, plus optional MPEG-7 metadata for structured description. This is functionally equivalent to HEIC's metadata model, but the storage mechanism differs from JPEG's APP1 segments — a DAM's extraction pipeline needs explicit HEIF support, or embedded EXIF and XMP fields can be silently skipped during ingest.

What structural advantage does HEIF offer over JPEG or PNG?

Because it's built on the ISOBMFF box structure rather than a flat JPEG/PNG bitstream, a single HEIF file can bundle a primary image with thumbnails, auxiliary images like alpha or depth maps, non-destructively derived edits, and even burst or animation sequences. For a DAM, that means one file may represent an entire capture — Apple's Live Photos are a common example — so cataloging rules need to decide whether it's one asset or several.

Does HEIF require a specific compression codec?

No — the ISO spec defines HEIF purely as an ISOBMFF-based container and says it's extensible to other coding formats. In practice, though, nearly every HEIF file in the wild is HEVC-encoded, which is exactly what makes it a HEIC file. AVIF is a separate, related format that swaps HEVC for the royalty-free AV1 codec. For a DAM, decode support hinges on the codec license, not the container spec.

When was HEIF standardized?

MPEG, part of ISO/IEC JTC1, finalized the HEIF draft in October 2015, and the standard was formally published in 2017 as ISO/IEC 23008-12:2017 — Part 12 of the MPEG-H suite alongside HEVC video coding. A newer edition, ISO/IEC 23008-12:2022, later followed. Apple's adoption of HEIF as HEIC in iOS 11, also 2017, is what actually pushed the format into everyday camera use.

How should a DAM think about the HEIC/HEIF relationship for cataloging?

Every .heic file is a valid HEIF file, but a DAM will almost never encounter a non-HEVC HEIF file in practice, so the two can share the same ingest, preview, and archival-conversion policy.

Sources