It does not survive — and it does not simply vanish. It gets flattened onto black, in exact proportion to the alpha value.
Short answer: the transparency is gone, and what replaces it is black — but not a flat black. Every pixel comes out as its stored colour multiplied by its alpha value. In my test a white pixel at alpha 128 came out as (128,128,128), a mid grey; the same white pixel at alpha 0 came out as (0,0,0), and the colour stored underneath it was lost. A red pixel stored as (254,0,0) at alpha 64 came out as (64,0,0). This is exactly what you get if the image is placed on a black background before it is written out.
Two things make this final on this page. The JPG this converter writes has three colour components — I read the frame header of the output files — so there is nowhere to put a fourth, alpha channel. And the page has no format control at all: one quality selector with three options (0.95, 0.85, 0.75), no PNG output, no mention of transparency anywhere in the page text. All eight conversions I ran finished with the error box empty; nothing warned me that alpha had been dropped.
I built six HEIC files that really carry an alpha channel and converted them on this site today, then pulled the JPG bytes back out and sampled individual pixels. Before converting, I decoded each file locally to confirm the alpha is genuinely stored: the alpha plane sits inside the file as a second hvc1 item, wired to the main image by an auxl reference.
| File | Size | Dimensions | What the alpha does |
|---|---|---|---|
bands-white.heic | 4,093 B | 600×500 | five bands, colour constant white, alpha 255 / 192 / 128 / 64 / 0 |
bands-red.heic | 4,103 B | 600×500 | same five bands, colour constant red |
gradient-alpha.heic | 10,444 B | 700×476 | colour constant (232,215,195), alpha fades 255 → 0 left to right |
opaque.heic | 90,908 B | 700×476 | a real photo, alpha 255 everywhere (control) |
half-alpha.heic | 92,142 B | 700×476 | same photo, right half alpha 0, colour kept |
circle-alpha.heic | 104,629 B | 700×476 | same photo, alpha 255 inside an ellipse, 0 outside |
Across twenty-five sampled pixels, the JPG came out as stored colour × alpha ÷ 255. The largest gap between that prediction and what I actually measured was 2 — the rounding you would expect from JPEG encoding. Both of these files converted without complaint: the white bands came out at 3,369 B in 874 ms, the gradient at 8,062 B in 602 ms.
| Alpha | Colour stored in the HEIC | Pixel measured in the JPG |
|---|---|---|
| 255 | (255,255,255) | (255,255,255) |
| 192 | (255,255,255) | (192,192,192) |
| 128 | (255,255,255) | (128,128,128) |
| 64 | (255,255,255) | (64,64,64) |
| 0 | (255,255,255) | (0,0,0) |
| 255 | (254,0,0) | (254,0,0) |
| 192 | (254,0,0) | (190,0,0) |
| 128 | (254,0,0) | (126,0,1) |
| 64 | (254,0,0) | (64,0,0) |
| 0 | (254,0,0) | (0,0,0) |
| 242 | (232,215,195) | (221,204,186) |
| 191 | (232,215,195) | (174,161,145) |
| 127 | (232,215,195) | (116,108,97) |
| 63 | (232,215,195) | (57,54,49) |
| 12 | (232,215,195) | (10,10,8) |
So the answer people usually expect — "the transparent part turns black" — is only half right. A pixel that is fully transparent turns black. A pixel that is half transparent turns half as bright, which is a different kind of damage: the shape survives, but every soft edge of a cut-out comes out as a dark halo.
I converted the same red-band file at all three quality settings. The five bands measured 254, 190, 126, 64, 0 at 0.85 and at 0.95, and the same at 0.75 apart from one blue channel that read (190,0,2) instead of (190,0,0) — a difference of 2, well inside what JPEG rounding produces. Only the file size really moved: 3,537 B at 0.75, 4,040 B at 0.85, 4,620 B at 0.95, from the same 4,103 B source. Timings were 584 ms, 586 ms and 635 ms.
There is no setting on this page that preserves alpha, because preserving alpha is not a matter of quality. It is a matter of the output format, and the output format here is JPG.
The control photo — the same image with alpha 255 everywhere — converted to 37,978 B in 711 ms. The same photo with its right half set to alpha 0 converted to 18,195 B in 652 ms, a little under half the size, because half the picture had become flat black.
Sampling the same coordinates in both outputs: on the untouched left half the two files agreed exactly, down to (6,2,3) at x=280. On the right half, a pixel that was (137,121,98) in the control came out as (0,0,0). The colour was still stored in the HEIC — the converter read it and then multiplied it away.
The ellipse mask behaves the same way in both directions. Inside the ellipse, the output matched the control photo exactly ((78,62,36) at the centre). Outside it, every sampled point came back (0,0,0). The 104,629 B source converted to 28,651 B in 742 ms, and the dimensions were unchanged at 700×476 — no cropping, no resizing, no error message.
I read the structure of the output files byte by byte. Each one is a baseline JPEG: APP0/JFIF, APP2/ICC, two quantisation tables, SOF0, four Huffman tables, then the scan. The frame header declares 3 components. That number is the whole story — three channels, luminance and two chroma, and no fourth slot where an alpha plane could live. (The same files also carry no EXIF block, which is a separate thing I measured in the EXIF and GPS article.)
On the input side, alpha is not exotic in HEIC: it is stored as a second image item in the same container and referenced from the main image. I confirmed that by walking the box structure of the files I generated. So the information is there when the decoder opens the file — the loss happens on the way out, when the result is written as JPEG.
<select> with three quality options, and its text mentions neither PNG nor transparency nor alpha. There is no format switch to find.One honest limit: I tested only this converter, so I am not going to tell you what other tools do with alpha. What I can tell you is what the files above measured here, today.
Black. I stored white — (255,255,255) — at alpha 0 and got (0,0,0) back. Had it been flattened onto white, that pixel would still be white.
No. In the half-alpha test a pixel stored as (137,121,98) came out as (0,0,0). Once it is written as JPEG the original colour is not in the file.
It did not, in any of the eight conversions I ran. Every one finished with the error box empty, and the result looked like a successful conversion.
Not in my runs. The eight conversions took between 584 ms and 874 ms; the opaque control photo took 711 ms, which is in the middle of that range.
No. Every file came out at the dimensions it went in at — 600×500 for the band files, 700×476 for the photo files.
That is a separate measurement, in the pixel-by-pixel quality article. Transparency is not a quality setting — it is a channel that JPG does not have.
Try it: open the converter and drop in a HEIC with a transparent background — then look at the background in the JPG you get back.
First published: 29 September 2026