What is actually in the file

Since the iPhone 7, the camera captures in Display P3, a wider gamut than sRGB. The HEIC file stores pixel values relative to P3 primaries and says so — either with an embedded ICC profile (prof / rICC colour box) or with an nclx box whose colour_primaries field is 12 (SMPTE EG 432-1: P3 primaries, D65 white).

A WebAssembly HEIF decoder such as libheif hands you raw RGBA bytes. Those bytes are P3 numbers. They carry no colour information of their own.

Where it goes wrong

The usual code looks like this:

const imageData = new ImageData(rgba, width, height); // colorSpace defaults to 'srgb'
ctx.putImageData(imageData, 0, 0);
const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.9 });

ImageData defaults to colorSpace: 'srgb'. So the browser takes numbers that mean "this much of P3 red" and treats them as "this much of sRGB red". P3 red is more saturated than sRGB red, so the same number under sRGB is a weaker colour. Every pixel loses a little saturation. That is the washed-out look.

Exporting does not help, because a JPG or PNG produced by canvas.toBlob() carries no colour profile. Every viewer will read it as sRGB anyway.

The fix: tell the browser what the numbers mean

ImageData accepts a colour space. Declare the pixels as P3 and let the browser convert them to the canvas's colour space when it draws:

const colorSpace = isP3 ? 'display-p3' : 'srgb';
const bitmap = await createImageBitmap(
  new ImageData(rgba, width, height, { colorSpace })
);

const canvas = new OffscreenCanvas(width, height);
const ctx = canvas.getContext('2d'); // an sRGB canvas
ctx.drawImage(bitmap, 0, 0);         // P3 → sRGB happens here

const jpg = await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.9 });

Now the output is genuinely sRGB: colours that fit in sRGB come out identical, and the few P3 colours outside sRGB are mapped to the nearest one sRGB can show. Because the result is real sRGB, it looks right in every viewer, profile or not.

Deciding whether the image is P3

You need isP3 from the file, not from a guess. Two cases cover iPhone photos:

• ICC profile present — the profile's description string contains "Display P3". A crude but effective check is to decode the bytes as Latin-1 and test for the name (it may appear in plain ASCII or as UTF-16):

  const text = new TextDecoder('latin1').decode(iccBytes);
  const isP3 = /Display P3|D\0i\0s\0p\0l\0a\0y\0 \0P\x003/.test(text);
  

• nclx box present — read colour_primaries; 12 means P3 with a D65 white point.

If neither is present, assume sRGB.

Two more things that bite

Take the primary image. A HEIC file often holds several images: the photo, thumbnails, burst frames, depth maps. libheif lists them all; "the first one" is not necessarily the photo. Look for the handle where is_primary() is true.

Large photos are tiled. A 12-megapixel HEIC is usually stored as a grid of 512×512 tiles. A good decoder stitches the grid for you when you decode the primary image — but if you ever see a small square instead of the whole picture, you have decoded a tile.

Checking the result

Put the converted JPG next to the original HEIC in a viewer that respects colour profiles (Preview on macOS, or Safari). With the default srgb ImageData the difference is visible on red and orange areas. With colorSpace: 'display-p3' the two should be indistinguishable.

ImageData colour spaces are supported in current Chrome, Edge and Safari. Check your target browsers: where the option is not supported it is ignored, the data is treated as sRGB, and you get the old washed-out behaviour rather than an error.