HEIC and AVIF: decoding and licensing

HEIC and AVIF share a container and part company at the decoder: the same box parser tells them apart, then HEIC goes to the one third-party decoder this site carries and AVIF to the browser itself. This guide follows that path for the six lanes — HEIC to JPG, HEIC to PNG, AVIF to JPG, AVIF to PNG, JPG to AVIF and PNG to AVIF — and explains why the site encodes AVIF but never HEIC. Every figure is computed at build time by the engine that processes your files, on illustrative inputs; the methodology page is the vetted summary and the other guides cover neighbouring mechanisms.

One container, two codecs — what the detector reads

Both formats begin with an ISO-BMFF ftyp box: a four-byte big-endian size, the FourCC ftyp, a four-byte major brand, a four-byte minor version, then compatible brands four bytes each to the end of the box. The detector parses that structure — never substring-searching the file — and clamps the declared size to the bytes actually present, so a truncated or hostile size cannot read past the buffer. The brands decide: an explicitly HEVC-coded brand (heic, heix, hevc, hevx) means HEIC, an AV1-coded brand (avif, avis) means AVIF, and the structural brands mif1 and msf1 are treated as HEIC unless an avif or avis brand is also present — so a box listing only mif1 and miaf is HEIC, while the AVIF rows below list mif1 as well and stay AVIF. The table runs the detector on illustrative boxes constructed in this page's build.

Two boundary cases: a box whose declared size cannot even hold the size, type, major-brand and minor-version fields is rejected — on illustrative boxes declaring 15 and 16 bytes the verdicts are unrecognized and HEIC — and a box declaring the largest possible 32-bit size is read only to the end of its data, so one carrying the avif brand is still AVIF. The last row is the precedence rule: a box listing both heic and avif is HEIC. The other signatures are in how image formats are detected.

Names are compared, not trusted

The filename is compared against that verdict, never trusted. The extension map reads .heic and .heif as claims of HEIC, .avif as a claim of AVIF, and .jpg, .jpeg and .jfif as claims of JPEG. On a HEIC body named IMG_0001.jpg the check returns actual HEIC, claimed JPEG, mismatch yes: the page shows a notice and converts from what the file actually is. Output names swap the extension for the target's canonical one — IMG_0001.HEIC to JPEG becomes IMG_0001.jpg — and when that would equal the input name, as with the misnamed IMG_0001.jpg, the engine writes IMG_0001-converted.jpg so the download cannot shadow the original.

Decoding HEIC: the one third-party decoder on the site

Every other tool here decodes with the browser's own codecs. HEIC is the exception, because no browser ships a HEIC decoder: the two HEIC pages load libheif — © struktur AG and contributors, licensed LGPL-3.0 — compiled to WebAssembly from pinned upstream source, together with its libde265 HEVC decoder from the same upstream family, also LGPL. The upstream codec source is compiled without source modifications, self-hosted from this site's own origin, and loaded at runtime as a separately replaceable module in a dedicated worker — a script plus a .wasm file under /vendor/libheif/, never compiled into the site's own JavaScript. Source code is at github.com/strukturag/libheif; exact versions, commits, checksums and the reproducible build recipe are in the project's provenance record, and the full licence text ships alongside the module at /vendor/libheif/LICENSE.txt.

The build is decode-only, and decoding happens entirely in your browser: the module is fetched from this site and your photo never leaves the tab. The methodology page gives the reason for carrying a third-party decoder at all: "convert my iPhone photo" is the single most common conversion request there is, and the alternative — uploading a camera roll to someone's server — is exactly what this site exists to avoid.

Decoding AVIF: the browser is the decoder

AVIF decoding deliberately vendors nothing. In the methodology page's words, current Chrome and Edge, Firefox 93+, and Safari 16.4+ decode AVIF natively, so AVIF to JPG and AVIF to PNG use the browser's own codec with a runtime feature probe and a plain-language notice when a browser cannot. The engine's native-only decode list is AVIF; the decode goes through createImageBitmap with imageOrientation: 'from-image', so orientation is applied during decoding.

What the plan decides for each lane

After detection, a pure planning module decides three things before any pixel moves: whether the source must be composited over a background colour because the target cannot hold transparency, what quality parameter (if any) the encoder receives, and whether the source container could be animated, so the "first frame only" caveat must be shown. HEIC and AVIF both count as alpha-capable sources — a HEIF image can carry an alpha auxiliary plane — so a JPEG target plans a flatten for both, a no-op on an opaque photo. Quality is shown on the encoder's 0–100 scale.

Reading the rows: HEIC to JPEG is flattened over #ffffff unless you pick another colour, receives the JPEG default of 92, and carries no first-frame caveat; HEIC to PNG is neither flattened nor given a quality. AVIF to JPEG adds the caveat, since the avis brand makes AVIF an animatable container. JPEG or PNG to AVIF never flattens — AVIF holds alpha — and receives the AVIF lane's default of 50. The planner refuses rather than guesses: given a background written as white instead of a hex colour, it returns "Enter the background as a hex color like #ffffff.". See transparency and flattening for the flatten and quality parameters and compress-to-target for the quality scale.

Why the site encodes AVIF but never HEIC

The engine's producible formats are PNG, JPEG, WebP, AVIF; its source-only list is GIF, BMP, HEIC, and the type naming a conversion target excludes HEIC. The methodology page states the reason. AVIF and HEIC are structurally siblings — the same HEIF container around a modern video codec — but they live under opposite legal regimes. HEIC's HEVC codec is covered by commercial patent pools, which is why browsers do not ship HEVC encoders and why this site's libheif build is decode-only: producing HEIC files would require licensing terms that a free, in-browser tool cannot honestly satisfy. AVIF's AV1 codec was developed by the Alliance for Open Media to be royalty-free under an explicit patent grant, which is why every current browser reads it and why the site is comfortable shipping an encoder for it. Conversions here go from HEIC and to AVIF, never the reverse.

That encoder follows the same self-hosting arrangement. JPG to AVIF and PNG to AVIF encode with libavif (© Joe Drago and contributors) driving the aom AV1 encoder (© Alliance for Open Media), both BSD-2-Clause, under the royalty-free Alliance for Open Media Patent License; the hardened browser binding is derived from Google's Squoosh/jSquash wrapper under Apache-2.0. Licence and patent-grant texts ship alongside the module at /vendor/avif/LICENSE.txt, LICENSE-libavif.txt, LICENSE-aom.txt and PATENTS-aom.txt. The lane sets the aom speed preset to 8 and leaves the compress-to-target search disabled, so the AVIF pages offer the quality slider only and say why.

Pinned bytes: the vendored-file discipline

Every vendored file's exact size and SHA-256 is pinned by automated tests, and every codec build uses immutable upstream commits, so served bytes cannot drift silently: a changed .wasm or loader script fails the test suite. Because the modules are separately replaceable files under /vendor/libheif/ and /vendor/avif/, anyone can inspect them, verify their checksums or substitute their own build; the exact versions, commits and checksums are recorded in the project's provenance record, and the licence texts sit beside the binaries for the same reason.

What re-encoding strips on these lanes

Whichever decoder produced the pixels, the output is a fresh encode, and canvas re-encoding strips all embedded metadata: EXIF (including GPS location, camera model and timestamps), colour-profile tags and text chunks — a feature and a caveat, so keep originals. Orientation is applied during decoding, before metadata is discarded, so uprightness survives. When an output comes out larger the row says so in the engine's words: on invented byte counts of 2,000,000 before and 18,000,000 after — arithmetic, not a measurement of any real file — the verdict reads "800% larger — keep your original". More in what re-encoding does to metadata.

How the output is verified

A download button means the output has already been checked: the produced bytes are sniffed with the same detector applied to inputs — a JPEG lane must yield image/jpeg bytes, an AVIF lane bytes the detector classifies as AVIF — so a browser silently substituting another format is reported as an error, never a mislabelled file. The blob is re-decoded to confirm its dimensions match the plan; the size shown is its true byte count; any percent on a row comes from those two measured counts for your file, the site publishes no blanket compression percentages anywhere, and a larger result says "larger — keep your original".

What the tool cannot know

• Whether the HEVC or AV1 compression already inside your file discarded detail: conversion preserves the image as it decodes and restores nothing.
• Whether a quality setting suits your purpose: the plan supplies a default and a range, and the row reports a measured byte count, not a visual judgement.
• Anything about your rights over a particular file: the licence texts under /vendor/ describe what this site ships and on what terms, nothing more.

Common misreadings

• "HEIC and AVIF are interchangeable names." Same container, different codec; a box listing both is HEIC.
• "There must be an AVIF to HEIC tool somewhere." HEIC is source-only (GIF, BMP, HEIC) and excluded from the target type; the reason is licensing.

Frequently asked questions

Local processing: whichever decoder a page uses — your browser's own codec or the self-hosted libheif module — files are decoded, converted, and verified entirely in your browser and never transmitted. HEIC decoding by libheif, LGPL-3.0, self-hosted and used unmodified — see the methodology page for the full attribution and how to verify the no-upload claim yourself.