Convert HEIF to AVIF

HEIF is ISO/IEC 23008-12, published by MPEG in 2015: a still picture stored in an ISO base media container, compressed with the intra-frame half of a video codec. AVIF, published by the Alliance for Open Media in 2019, is the same idea executed again — a still picture in an ISO base media container, compressed with the intra-frame half of a video codec. The codec is the difference: HEVC in one, AV1 in the other.

That shared ancestry is why people expect the conversion to be cheap, and it is the one thing this page has to correct early. The boxes around the picture may be near relatives, but the compressed data inside them is not interchangeable, so this is a full decode and a full re-encode rather than a repack.

Convert if something downstream asks for AVIF: a build pipeline, an image CDN, a site that serves AVIF to browsers announcing support, a client whose specification names it. In those cases the conversion is doing real work and the small quality cost is the price of getting the picture into the pipeline at all.

Do not convert because AVIF is newer. If the HEIF files are your photograph collection and nothing is currently refusing them, converting the lot costs a generation of quality, hours of encoding, and the ability to go back — because this site can read HEIF and cannot write it. A format migration with no destination is a lot of work to end up where you started with slightly worse pictures.

The registry records HEIF browser support as partial and AVIF as modern, and that gap is the real product of this conversion. HEVC decoding sits behind patent pools that many vendors declined to license, which is why a .heif file is awkward in exactly the places a picture needs to be easy. AV1 was built by a consortium specifically to avoid that. HEIF itself is an ISO standard like AVIF; what is not free to implement is the HEVC inside it.

On file size there is no reliable win to promise. The two codecs are close on still images, close enough that which one is smaller depends on the picture, the encoder build and the quality setting. Anyone who tells you a fixed percentage is quoting one test image.

Quality defaults to 82 on a 1 to 100 scale. Because the HEIF was already lossy, this is a second generation: the AV1 encoder never sees the original scene, only the pixels the HEVC decoder reconstructed, and it makes its own decisions about what to discard from those.

At 82 on a photograph the result is not something you will pick out in a comparison. What it is not is free, and the practical consequence is a rule rather than a number: always convert from the HEIF, never from a previously converted file, and do not run the picture through a chain of lossy formats because each link takes a little more.

This is the slowest raster target on the site, and the registry records it as a known property of the format rather than a fault of this build. AV1 buys its efficiency with an expensive search, and a full-resolution photograph takes noticeably longer here than the same picture into JPG or WebP.

The interface is built around it: progress is reported after decoding and again after encoding, precisely so that a file which sits at sixty percent for several seconds does not look like a hang. If you are converting a folder, expect it to take real time, and expect a phone to take considerably more of it than a laptop.

AVIF is specified to twelve bits per channel and HEIF to ten, so on paper this is the rare conversion with room left over — the target can hold everything the source could and more.

The pipeline here does not exercise it. The decoded picture passes through an eight-bit buffer on its way to the encoder, so eight bits per channel is what gets written. On a photograph that is invisible; on a long smooth gradient it can mean faint banding that a ten-bit path would not have produced. If deep colour is the reason you are converting, this converter is not the tool that will preserve it.

Both formats have an alpha channel, so transparency arrives intact. Both formats also allow animation and several images in one file, and that part does not survive: the decoder takes the primary image and the encoder writes a single still.

For a photograph, which is what almost every .heif file contains, neither of those is a loss. It is worth knowing before you point the converter at a burst or a sequence and get one frame back, because nothing about the output announces what it left behind.

AVIF can hold EXIF, XMP and an ICC profile, exactly as HEIF can. None of it makes the trip, because the picture is decoded to raw pixels and re-encoded from those, and there is no route across that step for a metadata block.

For publishing that is the outcome you want — no camera serial number, no capture time, no GPS coordinates in a file you are putting on a page. For a migration it is a second reason not to do one: a converted library arrives with its dates and locations gone, and those are frequently the only thing making a collection navigable.

There is no AVIF to HEIF page here and there will not be one. HEIF decoding is done by libheif under LGPL-3.0, which a static site can ship honestly by naming the library, publishing the licence text and serving it as a replaceable chunk. Writing HEIF would need an HEVC encoder, and the common one is GPL, whose conditions this site cannot meet.

That is worth weighing before a bulk conversion rather than after. The AVIF files are the derivative, the HEIF files are the only originals, and no setting on this page can turn the first back into the second.

Decoding and encoding both happen in the browser tab, on your processor, with no upload and no queue. There is no per-day allowance to run into and no server-side copy of your photographs to wonder about, and the free tier accepts files up to 100 MB each.

For this pair the local execution has a second consequence worth planning for: the encoding time is yours. A hundred photographs will occupy the machine for a while, they will all convert without a single request carrying an image, and an "all as ZIP" button appears once two of them are finished.

Browser support is the good half of the story. Away from the browser, AVIF is a young format: plenty of desktop image viewers, office suites, mail clients and older operating system versions do not show it, and a colleague sent one may be no better off than with the HEIF you started from.

That splits the decision cleanly by destination. For a web page served through a pipeline that knows what it is doing, AVIF is a good target. For a file you are emailing to a person, it is a worse choice than JPG and no better than WebP. The format's advantage is real and it lives entirely on the delivery side.

This pair rewards a measurement more than an opinion, because both the size result and the encoding time depend on your pictures and your machine. Convert ten representative photographs — a landscape, a portrait, a dim indoor shot, a screenshot — and look at what came out.

Two numbers decide it. If the AVIFs are not meaningfully smaller than the HEIFs, the compression argument has evaporated and only compatibility remains, which the destination either needs or does not. If the ten took several minutes, multiply that out honestly before starting a library-wide job, and remember it is your processor doing every second of it rather than a queue you can walk away from.