The short answer: converting an iPhone HEIC photo to JPG with Pixohub kept it visually almost identical (SSIM 0.996–0.998), but the file did not get smaller. On all five of our photos the JPG was the same size or bigger, by 0.3% to 28%. It was still 23–34% smaller than the JPG macOS makes from the same photo, because macOS saves at a higher quality setting. WebP was the only format that came out smaller than the HEIC, and PNG was 8–11 times its size. Along the way three other things change: the location and camera metadata are removed, the HDR highlights are lost, and the colours are slightly less saturated on a wide-gamut screen.
What we tested
We used five HEIC photos taken on iPhones, each 12 megapixels (4,032 × 3,024 or 3,024 × 4,032) and between 1.16 and 1.93 MB:
- Photo 1: a bright, high-contrast snowy street scene in daylight (landscape).
- Photo 2: a close-up of a slice of bread, taken with the ultra-wide/macro lens (portrait).
- Photo 3: a low-light indoor shot (landscape).
- Photo 4: a wooden chair indoors (portrait).
- Photo 5: a toy kitchen indoors (landscape).
All five are tagged with the Display P3 colour profile, all five are iPhone HDR photos that carry a gain map, and all five contain EXIF metadata including GPS location. None is a Portrait-mode photo, so depth maps were not covered. Each photo went through Pixohub's HEIC to JPG, HEIC to PNG and HEIC to WebP pages at their default settings. For comparison we also exported each one to JPG with macOS's built-in sips command, which uses Apple's own decoder and its default quality.
File size: the JPG is not smaller than the HEIC
| Photo | HEIC | Pixohub JPG | macOS JPG | PNG | WebP |
|---|---|---|---|---|---|
| 1. Snowy street | 1.75 MB | 1.76 MB (+0.6%) | 2.53 MB (+44%) | 14.5 MB (8.2×) | 1.24 MB (−29%) |
| 2. Bread close-up | 1.64 MB | 2.09 MB (+28%) | 2.91 MB (+77%) | 17.6 MB (10.7×) | 1.42 MB (−14%) |
| 3. Low light indoors | 1.16 MB | 1.43 MB (+23%) | 1.85 MB (+60%) | 13.3 MB (11.4×) | 0.77 MB (−34%) |
| 4. Wooden chair | 1.93 MB | 1.93 MB (+0.3%) | 2.94 MB (+52%) | 16.3 MB (8.4×) | 1.29 MB (−33%) |
| 5. Toy kitchen | 1.92 MB | 2.08 MB (+8.3%) | 3.03 MB (+58%) | 17.7 MB (9.2×) | 1.44 MB (−25%) |
| All five | 8.41 MB | 9.30 MB (+11%) | 13.26 MB (+58%) | 79.3 MB (9.4×) | 6.15 MB (−27%) |
HEIC is often said to be about half the size of an equivalent JPG. That depends entirely on the JPG's quality setting, and our numbers show both sides of it. Pixohub's JPG, at 85% quality, came out between 0.3% and 27.7% bigger than the HEIC: almost exactly the same size for the snowy street and the chair, about a quarter bigger for the bread and the low-light shot. None of the five got smaller. The detailed close-up and the noisy low-light photo grew most, which fits how JPG behaves: fine texture and sensor noise cost it more bytes than they cost HEVC, the codec inside HEIC.
macOS's own JPG export was much bigger, 44% to 77% over the HEIC. Reading the quantisation tables in the files, we estimate that sips saved at about quality 95 (93 for the low-light photo), against 85 for Pixohub. That is why Pixohub's JPG was 23.0% to 34.2% smaller than Apple's on every photo, 29.9% smaller across the five. The extra bytes in Apple's file bought very little: its SSIM was higher by only 0.0005 to 0.0012.
WebP at the same 85% setting was the only format smaller than the HEIC, by 13.5% to 33.9%, and 29.8% to 46.2% smaller than Pixohub's JPG of the same photo. PNG is lossless, so it stores every decoded pixel exactly and pays for it: 13.3 to 17.7 MB, which is 8.2 to 11.4 times the HEIC and 8.2 to 9.3 times the JPG.
Quality: how close each result is to the original
| Pixohub JPG | PNG | WebP | macOS JPG | |
|---|---|---|---|---|
| SSIM (range) | 0.9958–0.9981 | 0.9989–0.9996 | 0.9891–0.9958 | 0.9970–0.9986 |
| PSNR, luma (range) | 50.1–51.1 dB | 51.9–54.6 dB | 46.9–48.4 dB | not measured |
| Mean ΔE2000 (range) | 1.27–1.74 | 1.16–1.64 | 1.45–2.00 | not measured |
| 95th percentile ΔE2000 | 2.32–3.00 | 2.03–2.63 | 2.56–3.53 | not measured |
| Time to result (range) | 3.4–4.2 s | 3.6–4.6 s | 4.0–5.5 s | not comparable |
SSIM (structural similarity) compares brightness patterns between two images; 1 means identical, and above about 0.99 differences are very hard to see at normal viewing size. Every result here was above 0.989. The JPG's lowest score was on the wooden chair and its highest on the bread; WebP's lowest was also the chair, at 0.9891. At 85% quality WebP is a little less faithful than JPG on these photos, while being about a third smaller. If you want a WebP that matches the JPG's quality, raise the quality setting and you will still usually end up smaller.
ΔE2000 measures colour difference the way people perceive it. Below 1 is generally invisible; around 2 is the point where a careful viewer comparing side by side starts to notice. The mean differences here were 1.2 to 2.0, with the worst 5% of pixels between 2.0 and 3.5. The surprising number is PNG's: it is lossless, yet its mean ΔE was still 1.16 to 1.64. That is not compression. It is mostly the colour profile, explained next.
Colour: Display P3 values labelled as sRGB
iPhones record in Display P3, a wider colour space than the sRGB used by most of the web. Reds, oranges and greens can be more saturated in P3 than sRGB can show. To move a P3 photo into sRGB properly, each colour has to be converted: a P3 orange, for example, becomes a slightly different set of sRGB numbers.
Pixohub's HEIC decoder does not do that conversion. It hands over the P3 numbers unchanged, and the JPG and WebP are then tagged as sRGB (the PNG has no profile, which viewers also treat as sRGB). To check this directly, we made a test HEIC of flat colour patches tagged Display P3 and ran it through the HEIC to JPG and HEIC to PNG pages. Every patch came out with exactly the P3 numbers. A correct conversion would have changed some of them: a P3 value of 255, 127, 0 should become about 255, 117, 0 in sRGB, and a tan of 200, 151, 121 about 209, 148, 116. Those two misses are ΔE 3.0 and 2.9. Neutral greys are the same in both spaces, so they don't change at all.
In practice, the converted photo looks slightly flatter than the HEIC on an iPhone, Mac or other wide-gamut screen, most visibly in warm and saturated colours. On our five photos, which are mostly neutral and muted scenes, this showed up as the mean ΔE of about 1.2 to 1.6 that even the lossless PNG had; a small part of that comes from the two decoders rounding colour differently. For most sharing it won't be noticed. When colour must be exact, convert to PNG, assign Display P3 to it in an editor, then convert it to sRGB there before exporting.
HDR: the gain map is dropped
All five photos are iPhone HDR images. Each stores a normal standard-range picture plus a gain map: a second, smaller image that tells an HDR screen how much brighter to make the highlights. On a recent iPhone or Mac, the Photos app uses it to make skies, snow and lights glow.
The converted files are standard-range images, and Pixohub's output contains no gain map. What you get is the standard-range picture the HEIC already contains, which is what non-HDR screens show anyway. On an HDR screen, the bright parts of the converted photo will look dimmer than in the original HEIC. Scenes with strong highlights, like our snowy street, are where you would expect the difference to show most. If the HDR look matters to you, keep the HEIC, or share it from the Photos app to a service that supports HDR.
Metadata: location and camera details removed
All five HEIC files carried EXIF metadata, including GPS location. In all fifteen Pixohub results, the EXIF was removed, GPS included. The conversion draws the decoded pixels onto a canvas and encodes them from there, and the canvas carries no metadata. macOS's sips export kept both EXIF and GPS in all five.
Which is better depends on what you are doing. Before posting a photo publicly or sending it to someone you don't know, losing the location is a privacy gain. For your own archive it's a loss: the date taken and the place go with it, so photo libraries may sort the converted file by the date you made it, not the date you took it. Keep the original HEIC if you need either. You can check any file with our EXIF viewer.
Orientation and speed
All fifteen results came out upright, at the right size: 4,032 × 3,024 for the three landscape photos and 3,024 × 4,032 for the two portrait ones. The orientation is applied to the pixels themselves, so a converted portrait photo stays upright even in apps that ignore orientation tags.
Each 12-megapixel photo took 3.4 to 5.5 seconds from choosing the file to the download being ready, on an Apple M2 Mac. Most of that is decoding the HEIC, which happens in WebAssembly on your device, so JPG (3.4–4.2 s) and PNG (3.6–4.6 s) were close and WebP (4.0–5.5 s) a little slower. Expect a phone or an older laptop to take longer.
How we tested
On 24 October 2026 we drove Pixohub's /heic-to-jpg, /heic-to-png and /heic-to-webp pages in Chromium via Playwright on an Apple M2 Mac, against a production build of the site. A script uploaded each HEIC, waited for the result and saved exactly what the download button returns, at default settings. Pixohub decodes HEIC with the heic-to library, which bundles libheif. The macOS comparison files were made with sips, converting to JPEG at its default quality.
For the reference, we decoded each HEIC with libheif through pillow-heif, applied its orientation, and converted it from its embedded Display P3 profile to sRGB with LittleCMS. Each output was opened the same way, converted to sRGB from its own profile if it had one, and treated as sRGB if it had none. Both images were scaled to 1,080 px wide with Lanczos resampling. We then computed SSIM and PSNR on luminance with scikit-image, and CIEDE2000 per pixel after converting both to CIELAB, reporting the mean and the 95th percentile. JPEG quality was estimated from each file's quantisation tables. Metadata was checked for presence only. The colour-profile test used a synthetic HEIC of six flat patches, tagged Display P3 and made with pillow-heif.
Limits: five photos is a small sample, all from one iPhone model family, so other models, ProRAW, Portrait-mode photos with depth maps and 48-megapixel shots may behave differently. We used one browser on one machine; Safari decodes and encodes through its own engine, so its times, and possibly its colour handling, differ. The reference uses a different decoder from Pixohub's, and decoders round colour slightly differently, which accounts for part of the ΔE even for lossless PNG. SSIM and ΔE are averages over the whole image; a difference concentrated in one small area counts for little in them.
Which format to choose
- For an upload form, email or anyone on Windows: HEIC to JPG. It opens everywhere and looks the same. Expect the file to be about the same size as the HEIC or a bit bigger, not half.
- For a website or anywhere WebP is accepted: HEIC to WebP. It was 14–34% smaller than the HEIC and about a third smaller than the JPG.
- For editing, or colour work: HEIC to PNG. It's lossless, so nothing is lost before you edit, but it's 8–11 times the HEIC's size, so don't use it for sharing.
- If the JPG is too big for a size limit: run it through compress image afterwards rather than converting at a lower quality by guesswork.
- If you need the date, place or HDR highlights: keep the original HEIC. The converted copy has none of them, which is also why it's safer to share.