Why colours shift after compression (ICC profiles)

The numbers in an image file do not mean anything on their own. A pixel recorded as 255 in the red channel means "the most red this colour space can express" — and how red that actually is depends entirely on which colour space you mean.

The most saturated red in sRGB is noticeably duller than the most saturated red in Display P3 or Adobe RGB. Same number, different colour. The ICC profile is the label saying which one applies.

Strip the label and software falls back to assuming sRGB. If the file was actually Adobe RGB, every colour is now being interpreted against a narrower scale than it was recorded on, and the image looks flat and desaturated.

Wide-gamut file, profile removed

Reads as sRGB. Colours look dull, flat and washed out. Most common when exporting from Lightroom or Photoshop in Adobe RGB and then stripping metadata.

sRGB file, tagged as wide-gamut

Reads as a larger space than it was made for. Colours look oversaturated and slightly wrong, particularly skin tones.

Both look like a compression fault and neither is one. The pixel values are unchanged; only the interpretation moved.

These are different operations and confusing them is the root of most colour problems.

Converting recalculates every pixel so it looks the same in the new colour space. An Adobe RGB image converted to sRGB has different numbers in it, chosen so the visible colour stays as close as the smaller space allows. This is safe.

Assigning or stripping changes only the label. The numbers stay as they were and are now interpreted differently, so the image visibly changes. This is what causes the shift.

The safe sequence for the web is always: convert to sRGB first, then decide whether to embed the profile.

Convert to sRGB. Browsers handle sRGB correctly and universally, and colour-managed workflows outside it are unreliable across the range of devices real visitors use.

Then either embed the sRGB profile — a few kilobytes, and unambiguous — or strip it, since sRGB is what software assumes anyway. Embedding is the safer default; stripping is defensible when every kilobyte counts, provided the pixels were genuinely converted first.

Keep wide-gamut for print masters and for editing, where the extra range is genuinely used.

These tools decode your image and re-encode it through a browser canvas, which operates in sRGB. That means a wide-gamut image processed here comes out as sRGB — the browser converts the pixels as part of decoding, so the colours are translated rather than merely relabelled.

For images headed to the web that is the correct outcome. For a print master in Adobe RGB or ProPhoto it is not: you would be discarding gamut you intend to use. Compress copies for the web and keep the wide-gamut master untouched.

This is a real limitation of doing the work in a browser, and it is worth knowing before you process anything colour-critical.

Browsers work in RGB. A CMYK JPEG loaded into a canvas is converted to RGB before anything else happens, and saturated cyans, oranges and deep blues can shift noticeably in the process.

That conversion is not a defect — it is what has to happen for the image to be displayed at all. Do web work in RGB, keep a separate CMYK master for print, and never round-trip between them.