# HEIC to AVIF > Both formats share the same ISO-BMFF container, but this is a full decode and re-encode: the measured 718,114-byte HEIC became 491,861 bytes of AVIF. - URL: https://bytescope.dev/en/image-convert/heic-to-avif/ - Locale: en · Also: [ja](https://bytescope.dev/ja/image-convert/heic-to-avif.md) · [zh-Hant](https://bytescope.dev/zh-Hant/image-convert/heic-to-avif.md) - Runs: Your files never leave your browser — all processing is local. - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does ### What an HEIC loses on the way to AVIF The two files look like cousins and in one sense they are: both begin with an `ftyp` box, both are ISO-BMFF, and this converter tells them apart with a single function that reads the compatible-brand list rather than trusting the extension. That resemblance invites the assumption that the conversion is a repackaging — lift the coded picture out of one wrapper, drop it into the other, lose nothing. It is not, and it could not be. The coded data inside the source is HEVC; the coded data inside the target is AV1. No amount of rewriting boxes turns one into the other. The picture is decoded all the way down to pixels by the bundled libheif build and then encoded again from scratch, so every cost of a re-encode applies in full. The container is also usually holding more than one image, and only one of them makes the trip. The decoder returns every image it finds — the sample used for the measurement below has two — and the converter takes the first and tells you it did. Burst frames, image sequences, thumbnails, depth and other auxiliary images stay behind in the source. An Apple Live Photo goes further than that: the motion is a separate file on the device that this page never receives, so what you download is the still, and the pair on your phone is left as it was. Precision is the last thing to go, and it goes before the encoder is involved. libheif hands back an 8-bit RGBA buffer, so a photo captured with 10-bit tonal values and an HDR transfer curve arrives at the AV1 encoder already flattened into 8 bits — the target format could have carried the original depth, and is never offered it. The embedded ICC profile is not copied, nor is the EXIF block, so capture time, lens, exposure and GPS do not appear in the result. ### How the file size changed in a measured run On 2026-09-12 the script decoded the commit-pinned libheif example — 1280 × 854, two images, 718,114 bytes — and encoded the first image at quality 85, speed 8: 491,861 bytes, about 32% smaller. That is the opposite direction from the same encoder's result on an already-compressed JPG or WebP source, and the reason is worth knowing. Here the encoder was given the decoded original rather than a picture that had been through another encoder first, so it was not spending bits on someone else's artifacts. A detail that confirms the measurement is real: the byte count is identical to the one produced by the PNG route, because the PNG in that row is a lossless round trip of these same pixels. A 12-megapixel phone photo will take noticeably longer to encode than this sample did. ### When you should not convert HEIC to AVIF Keep the original when your recipient can open it — Apple's own apps and any recent phone handle it natively, and converting buys nothing. Keep it when you need the EXIF: dates, locations and lens data are all absent from the result, and a photo used as evidence or carrying a provenance trail should not be stripped. Keep it when the picture is a Live Photo you still want playable, when the container holds a burst or a depth map you may want later, and when the file is your only master and you expect to edit the highlights. Choose JPG instead — larger, but universally understood — if the destination is an old operating system, a print lab or a form whose accepted list predates AV1. For publishing an iPhone photo on a page you control, this is the right target. Conversion happens entirely in your browser — no upload, no queue, no watermark. Drop in as many files as you like and download them individually or as a zip. ## Limits The two files look like cousins and in one sense they are: both begin with an `ftyp` box, both are ISO-BMFF, and this converter tells them apart with a single function that reads the compatible-brand list rather than trusting the extension. That resemblance invites the assumption that the conversion is a repackaging — lift the coded picture out of one wrapper, drop it into the other, lose nothing. It is not, and it could not be. The coded data inside the source is HEVC; the coded data inside the target is AV1. No amount of rewriting boxes turns one into the other. The picture is decoded all the way down to pixels by the bundled libheif build and then encoded again from scratch, so every cost of a re-encode applies in full. The container is also usually holding more than one image, and only one of them makes the trip. The decoder returns every image it finds — the sample used for the measurement below has two — and the converter takes the first and tells you it did. Burst frames, image sequences, thumbnails, depth and other auxiliary images stay behind in the source. An Apple Live Photo goes further than that: the motion is a separate file on the device that this page never receives, so what you download is the still, and the pair on your phone is left as it was. Precision is the last thing to go, and it goes before the encoder is involved. libheif hands back an 8-bit RGBA buffer, so a photo captured with 10-bit tonal values and an HDR transfer curve arrives at the AV1 encoder already flattened into 8 bits — the target format could have carried the original depth, and is never offered it. The embedded ICC profile is not copied, nor is the EXIF block, so capture time, lens, exposure and GPS do not appear in the result. ## FAQ ### Is this conversion just a container swap? No. The two formats share the ISO-BMFF wrapper but not the codec inside it — HEVC on one side, AV1 on the other — so the picture is decoded to pixels and encoded again. That means a fresh lossy pass, and it is why the metadata and the extra images do not simply carry over. ### Which image from a multi-image container ends up in the output? The first one the decoder returns, and the page says so after converting. Bursts, sequences, thumbnails and auxiliary images such as depth maps stay in the source file. If you need a different one, extract it before converting rather than after. ### Does the result keep 10-bit tones and HDR? No. The decoder returns 8-bit RGBA, so the depth is gone before the encoder is called — even though the target format is perfectly capable of storing it. Smooth highlight rolloff that looked continuous on a phone can show banding in the converted file. ### Are my images uploaded anywhere? No. Conversion happens inside your browser using the canvas API and a Web Worker — files never leave your device. There is no upload step, no queue and no file size limit beyond your machine's memory. ### Is EXIF metadata kept in the converted image? No — and that's a feature. Re-encoding through the canvas strips all metadata: GPS location, camera model, timestamps and color profiles. The output contains pixels only, which is usually what you want before sharing an image publicly. ### Can I convert many images at once? Yes. Drop or paste any number of files; each is converted in the background with its own progress and download button, and you can grab everything at once as a .zip archive. ### Will converting lower my image quality? It depends on the target. The converter always decodes to raw pixels and re-encodes, whichever formats are involved, which is also how metadata gets stripped. For lossless targets (PNG, and GIF within its 256-color limit) the pixels stay identical to what was decoded; for JPEG, WebP and AVIF the quality slider controls the trade-off, and converting a file that is already lossy adds one more generation of loss.