One is the box, one is the compressor, one is a name Apple picked. I rewrote the name on a real file eight times — and the converter did not care once.
Short answer: HEIF is the container — the box your photo is packed in. HEVC (H.265) is the codec — the maths that shrank the pixels. HEIC is the brand name for the combination: HEIF packaging carrying HEVC-coded images. Android’s own documentation puts it exactly this way, calling HEIC “a high efficiency video encoding (HEVC) specific brand of the high efficiency image file format (HEIF)”. So it is not three competing formats; it is a box, a compressor, and a label.
What I measured on this site: I took one real iPhone HEIC (41,465 bytes, 700×476) and changed only the four bytes that declare its brand — to heix, heim, heis, hevc, mif1, avif, jpeg and even the nonsense xxxx. Every single one converted, each producing the same 38,078-byte JPG, in 131–299 ms. Then I built a real AVIF — the same container family, but AV1 inside instead of HEVC — and it was refused in 118 ms, whether it was named .avif or renamed .heic. The label is decoration; the coded stream is what decides.
ftyp box at the front of the file.One more name worth knowing now that it is common: AVIF is HEIF’s box carrying AV1 instead of HEVC. Same container, different codec — and, as you will see below, that swap is exactly what breaks a HEIC decoder.
The first box in a HEIF file is ftyp, and it is where the file states what it is. In the HEIC I tested, that box is 24 bytes long and its payload reads:
68 65 69 63 00 00 00 00 6d 69 66 31 68 65 69 63 — heic, version 0, then the compatible brands mif1 and heic
The rest of the file is meta (3,816 bytes, describing what is inside) followed by mdat, which declares its length with a 64-bit size field — the box header says 1, the signal that the real eight-byte length follows. The whole file is 41,465 bytes. That structure is the container doing its job; the brand is the four bytes at the front.
I copied the file and overwrote only those four brand bytes, leaving every other byte — the boxes, the coded image, everything — untouched. Each copy went through the live converter at the default 85% quality:
| Brand written into the file | Result | JPG out | Time |
|---|---|---|---|
heic (untouched original) | Converted | 38,078 bytes | 1,075 ms |
heix | Converted | 38,078 bytes | 234 ms |
heim | Converted | 38,078 bytes | 299 ms |
heis | Converted | 38,078 bytes | 131 ms |
hevc | Converted | 38,078 bytes | 202 ms |
mif1 | Converted | 38,078 bytes | 209 ms |
avif | Converted | 38,078 bytes | 201 ms |
jpeg | Converted | 38,078 bytes | 200 ms |
xxxx (nonsense) | Converted | 38,078 bytes | 194 ms |
heic, but with heic scrubbed from the compatible-brand list | Converted | 38,078 bytes | 231 ms |
Ten files, ten successes, one identical output every time — 38,078 bytes at 700×476. The 1,075 ms on the untouched original is simply the first conversion after a page load; the rest land in a couple of hundred milliseconds.
So this decoder does not ask “is your brand heic?” It does not even ask “is your brand anything I recognise?” — xxxx sailed through — and it does not read the compatible-brand list either. It goes to the coded data and tries to decode it as HEVC.
Now the control that makes the point. I encoded the same photograph as a real AVIF: 27,709 bytes, an ftyp box declaring avif with compatible brands avif, mif1, miaf and MA1B. By declaration it is a HEIF file — mif1 is right there in its compatible-brand list. What is inside is AV1, not HEVC.
| File | Bytes | Result | Time |
|---|---|---|---|
photo.avif | 27,709 | Refused | 118 ms |
avif-named.heic — identical bytes, renamed | 27,709 | Refused | 128 ms |
Both came back with the same message the page shows for anything it cannot read:
“Could not convert this file. Make sure it is a valid HEIC or HEIF photo from an iPhone.”
Renaming the AVIF to .heic changed nothing, which is the same lesson from the other side as the brand test: neither the file name nor the declared brand gets you in. A decoder built around HEVC meets AV1 data and stops — in this case after about a tenth of a second.
.heic name is refused, and so is an AVIF — same message, same speed. Both are measured..mp4 and .mov; handing one of those to a still-image converter does not work, which I ran into with the video half of a Live Photo in the Live Photo test.Not to this converter. I relabelled the same file’s brand as heix, heim, heis, hevc and mif1, and every one produced the same 38,078-byte JPG. For the file name, both extensions are accepted — the picker advertises .heic,.heif,image/heic,image/heif.
No. Measured: a real AVIF of 27,709 bytes was refused in 118 ms, and renaming it to .heic did not help — refused in 128 ms.
Because the name is not what is being read. Something inside the file is not HEVC data the decoder can handle — a JPEG renamed to .heic fails the same way, as does an AVIF.
The codec is the same; the container is not. A HEIC is one coded frame in a HEIF box. I did not run video files through this converter today beyond what is in the Live Photo test, so I will not claim more than that.
No. All ten brand variants produced byte-identical output — 38,078 bytes at 700×476 each time.
heis variant is a single image relabelled as a sequence brand. I did not build a genuine multi-image sequence or a real 10-bit or alpha variant here; those are covered in what a HEIC holds that a JPG cannot.HEIF processing error); the reader-facing sentence is the page’s. I measured both, but I did not investigate what else triggers that internal message.Wondering what is really inside your file? Drop it in the converter — it reads bytes, not labels, and it happens on your own device.
First published: 27 September 2026