They exist, and this converter gives you one JPG back: the image that comes first in the file. The others are dropped without a word.
Short answer: you get one JPG, and it is the image stored first inside the HEIC — not the one the file marks as its primary image, and not the largest one. I ran ten multi-image HEIC files through the live converter today at the default 85%. Every one of them produced exactly one download link, one JPG, and no warning that anything had been left behind.
What I measured on this site: a file holding eight 1,200×900 images produced a JPG that is byte-for-byte identical to the JPG from a one-image control file — 7,174 bytes, SHA256 starting 1ff154eb57af — and took 687 ms on average against the control’s 700 ms. The seven extra images cost nothing measurable, because they are never decoded.
Each file was built on this machine with libheif, opened in a fresh page and converted at 85%. Each file’s images are flat single colours so there is no ambiguity about which one came back — I checked the output JPG pixel by pixel.
| File | What is inside | HEIC in | JPG out | Size | Time | Which image came out |
|---|---|---|---|---|---|---|
| two-green-red | green, then red | 736 B | 1,474 B | 400×300 | 627 ms | The green one — image 0 |
| two-red-green | red, then green | 736 B | 1,474 B | 400×300 | 633 ms | The red one — image 0 |
| two-primary-second | green, then red; red marked primary | 736 B | 1,474 B | 400×300 | 623 ms | The green one — identical bytes to two-green-red |
| three-rgb | green, red, blue | 938 B | 1,474 B | 400×300 | 581 ms | The green one — image 0 |
| burst8 | eight images, 300×200 | 1,534 B | 1,132 B | 300×200 | 544 ms | Only the first |
| big-then-small | 800×600, then 400×300 | 1,082 B | 3,611 B | 800×600 | 609 ms | The 800×600 one — image 0 |
| small-then-big | 400×300, then 800×600 | 1,082 B | 1,474 B | 400×300 | 532 ms | The 400×300 one — not the largest |
| main-with-thumb | 1,200×900 plus 320 and 96 thumbnails | 1,736 B | 7,174 B | 1,200×900 | 694 ms | The full-size image, not a thumbnail |
| real-plus-red | real iPhone photo, then red | 90,890 B | 37,978 B | 700×476 | 817 ms | The photograph |
| real-plus-green-primary1 | real iPhone photo, then green; green marked primary | 90,889 B | 37,978 B | 700×476 | 704 ms | The photograph — identical bytes to real-plus-red |
Every single row produced one JPG. In no case did the page offer a second file, a zip, or a note that more images existed. The two two-image files are the clearest proof that order is what counts: same two colours, same 1,474-byte output size, but two-green-red.heic gave a solid green JPG (SHA256 starting 5633b95c837a) and two-red-green.heic gave a solid red one (SHA256 starting e2d7d7005bc9).
A HEIC file can name which of its images is the main one. That is not a matter of opinion — it is a box in the file called pitm, and I read it back out of my own test files. In two-primary-second.heic the pitm box points at item 2, the red image, and libheif on this machine agrees: it reports a primary index of 1. The converter still handed me the green image, and the JPG it produced is byte-identical to the one from the file where green is simply first — 1,474 bytes, SHA256 starting 5633b95c837a.
The same thing happens with a real photograph. real-plus-green-primary1.heic holds my 700×476 iPhone photo with a flat green image second, and the file marks the green one as primary. The converter returned the photograph — 37,978 bytes, SHA256 starting ea6830010938, the same bytes as the file where the order is the same but the flag is not set.
So if you are hoping to rearrange a file to change what comes out: what decides it is the order the images sit in, not the flag.
I wondered whether the decoder was quietly picking the largest image, which would be the friendly thing to do. It is not. small-then-big.heic holds a 400×300 image first and an 800×600 image second, and the JPG came out 400×300. Flip the order and you get the 800×600 one. Neither file errored and neither file said anything.
The same applies to thumbnails. libheif can embed real HEIF thumbnails — my main-with-thumb.heic carries two, sized to fit inside 320 and 96 pixel boxes. The converter returned the 1,200×900 original, so you are not getting a shrunken copy without noticing.
This is the part I found most useful, because it tells you something about the cost. I built a file with eight 1,200×900 images and a control file with just the first of them, then ran each three times in fresh pages at 85%.
| File | Images inside | HEIC in | Run 1 | Run 2 | Run 3 | Mean | JPG out |
|---|---|---|---|---|---|---|---|
| one-1200 | 1 | 1,179 B | 685 ms | 708 ms | 706 ms | 700 ms | 7,174 B |
| burst8-1200 | 8 | 7,084 B | 669 ms | 707 ms | 686 ms | 687 ms | 7,174 B |
The eight-image file is six times the bytes and carries seven more full-size pictures, and it converted in the same time to the same bytes — SHA256 starting 1ff154eb57af for all six runs. The only difference between the two files is data the decoder never looks at.
I also called the decoder directly in the page rather than going through the file input. It returns a single Blob — [object Blob], not an array, with no length and no per-image handle. There is no plural form of the call to make, which is why no setting on the page will get you the other images.
two-green-red.jpg — 400×300 — 1 KB. That describes the JPG you got; it does not mention the one you did not.two-green-red.heic becomes two-green-red.jpg. No “-1” or “-first” suffix, so a file that lost images looks exactly like a file that had one to begin with.HEIC is a container, not a picture. Its file is a stack of boxes, and inside the meta box there is a list of items — each infe entry is one item, and an image item is one of type hvc1. I counted them in my own test files: the eight-image burst has eight infe entries, the one-image control has one.
The real iPhone photo I use for testing here — 41,465 bytes, 700×476 — has three items: two hvc1 image items and one Exif block. The second image item is tied to the first by an auxl reference, which marks it as an auxiliary image rather than a second photo. libheif reads that file as having one image, and that is what the converter returns. I did not work out what the auxiliary image actually contains, so I am not going to say.
The only way I verified on this machine is to ask libheif directly, which is the same library this converter uses. With Python and pillow-heif installed:
import pillow_heif
pillow_heif.register_heif_opener()
h = pillow_heif.open_heif("photo.heic")
print(len(h), h.primary_index)That printed 8 0 for my eight-image file and 1 0 for the iPhone photo. If the first number is more than 1, the converter is going to give you one of them and you will not be told which.
I did not test Preview, Windows Photos, ExifTool or any other tool for this, so I am not going to claim what any of them show you.
Not here. The decoder returns a single Blob per call, so one file in means one JPG out. I found no way to reach the others from this page.
The first one. I built a file where the second image is marked primary and libheif confirms it, and the converter still returned the first image — byte-identical to the version without the flag.
No. A file holding a 1,200×900 image plus two embedded thumbnails came back at 1,200×900.
Not measurably. Eight 1,200×900 images converted in 687 ms on average against 700 ms for the one-image control, and produced the same bytes.
No. A Live Photo is a still image plus a separate video track, and what happens to that pair is measured in the Live Photo test. This page is about several still images inside one container.
Because the one you get is a complete picture. If you were not expecting more than one, you have no way of noticing — the summary line and the download name describe only the JPG that was produced.
auxl; I did not decode it.Not sure what is inside your HEIC? Open the converter — and if the result is not the frame you expected, the file may be holding more than one image.
First published: 28 September 2026