Yes, if the photo is Display P3. The numbers are copied through untouched and then labelled sRGB — so the warm tones come out flatter than the original. Here is the measurement.
Short answer: the converter does not read the colour profile embedded in the HEIC. I made two 500 × 500 test images with exactly the same pixel values, tagged one Display P3 and one sRGB, and converted both. The two output files were byte-for-byte identical — same 4,834 bytes, same SHA-256 hash. The P3 numbers arrive in the JPG unchanged, but the JPG declares itself sRGB, so a viewer interprets those numbers as the narrower space and the saturated tones render duller than they were.
How I know: I generated a Display P3 ICC profile locally, wrote it into a HEIC, converted the file at two quality settings, pulled the resulting JPG back out of the browser and read its pixels and its ICC segment. Every number below came out of that run.
One 500 × 500 image, five vertical bands of solid colour, 8-bit, saved as HEIC. Two copies with identical pixel values:
| File | Embedded profile | Size on disk |
|---|---|---|
p3-swatches.heic | Display P3, 2,040 bytes | 12,225 bytes |
srgb-swatches.heic | sRGB, 588 bytes | 10,773 bytes |
The P3 profile is one I generated myself. I checked it before using it: feeding it sRGB pure red (255,0,0) returns (234,51,35), which is the correct Display P3 value for that colour, so the profile is behaving like a real P3 profile and not like a broken one.
The five bands, read back out of the saved HEIC before conversion: an orange (230,130,70), a sky blue (110,170,220), a grass green (110,160,89), a skin tone (220,171,141) and a neutral grey (128,128,128). The grey is the control — a neutral should look the same in both colour spaces.
| Band | Value in the HEIC | What sRGB should have been | What the JPG contains | ΔE76 |
|---|---|---|---|---|
| Orange | 230, 130, 70 | 246, 123, 52 | 230, 130, 70 | 13.5 |
| Sky blue | 110, 170, 220 | 89, 172, 225 | 110, 170, 220 | 5.0 |
| Grass green | 110, 160, 89 | 94, 162, 81 | 110, 160, 89 | 8.1 |
| Skin tone | 220, 171, 141 | 229, 167, 135 | 220, 171, 141 | 5.8 |
| Neutral grey | 128, 128, 128 | 128, 128, 128 | 128, 128, 128 | 0.0 |
Every saturated patch landed on the wrong colours. The neutral grey landed exactly right, which is what you would expect: greys sit on the axis both colour spaces share, so ignoring the profile costs them nothing.
The ΔE76 column is the distance in Lab between the colour the photo actually contained (the P3 numbers read as P3) and the colour the JPG will show (the same numbers read as sRGB). A value around 5 is visible side by side; 13.5 on the orange is obvious.
Conversion took 0.7 s to 1.8 s per file. At the lower quality setting the P3 file produced a 4,007-byte JPG with the same patches (±2 on one channel), so the shift has nothing to do with quality — it is the same at both settings.
Two different inputs, two different colour profiles, two different source files — and the converter produced one file twice. The P3-tagged HEIC and the sRGB-tagged HEIC both came out as a 4,834-byte JPG with the SHA-256 hash starting a8af458e. Not similar. Identical, byte for byte.
That can only happen if the profile is discarded before the pixels are written. And the output file then states what it is: its APP2 segment is 472 bytes, of which 458 bytes are an ICC profile whose description reads sRGB. So the P3 numbers get a new label claiming they are sRGB. Every viewer downstream believes the label.
HEIC can store ten bits per channel; JPG cannot. I made a 1,024 × 64 gradient that uses all 1,024 levels a 10-bit file can hold, confirmed the file reports bit_depth = 10, and converted it. The output JPG's middle scanline holds 256 distinct values, not 1,024 — exactly four source levels collapse into each output level. The gradient still looks smooth here because it is a synthetic ramp; in a real sky or a sunset, that is where banding comes from, and no setting on this converter can prevent it, because JPG has eight bits per channel to work with.
nclx box rather than an embedded ICC profile. My test files use an ICC profile. A file that carries only nclx metadata might behave differently; I did not test that, so I am not claiming it.Thirty seconds of work, and it settles the question for whatever tool you actually use.
On this converter, for a Display P3 source, yes. The numbers survive untouched but the file is relabelled sRGB, so saturated colours render differently — up to ΔE 13.5 on the most saturated patch I measured. Neutral greys were unchanged.
Because the embedded profile is not read. I proved it by converting two files with identical pixels and different profiles: the outputs were byte-for-byte identical, 4,834 bytes each with the same hash, and both carried a 458-byte sRGB profile.
Not washed out — slightly less saturated in the strong colours. On my orange patch the difference is 16 levels of red and 18 levels of blue. You would notice it in a sunset, much less in a portrait or a document scan.
Not with a JPG output, because the JPG format has no way to say "these numbers are P3" here — the converter writes an sRGB tag. Keep the original HEIC if the exact colour matters; the conversion does not modify it.
No. My 10-bit gradient held 1,024 distinct levels going in; the JPG that came out held 256. JPG stores eight bits per channel.
I did not test other converters and will not speak for them. This is a measurement of this one, run today.
Try it yourself: convert a HEIC with strong colour in it, then compare the JPG against the original on the same screen.
First published: 23 September 2026