Why Your Colours Change Between Devices

Why the same file looks different everywhere

An image stores each pixel as amounts of red, green, and blue. But 'the most red this device can produce' is not a fixed colour — it depends entirely on what the display hardware is capable of. A value of maximum red means one thing on an older office monitor and a noticeably more saturated thing on a modern wide-gamut phone screen.

So the numbers alone are ambiguous. They describe proportions of whatever primaries the device happens to have, and devices differ. Two screens showing the same file are both displaying it correctly according to their own capabilities, and the result looks different.

A colour profile resolves the ambiguity by recording which colour space the numbers were written for. Colour-managed software reads the profile, works out what actual colours were intended, and then works out what numbers this particular display needs to reproduce them as closely as it can. The numbers change on the way to the screen; the appearance stays consistent.

When the profile is missing, software has to guess. Almost everything guesses sRGB, which is why sRGB images look right nearly everywhere and images from a wider colour space look wrong when their profile is lost.

The colour spaces you will meet

sRGB is the long-standing default for screens and the web. Its range of reproducible colours is modest by modern standards, but it is the one thing essentially every device and application understands. For anything going to an unknown destination, it is the safe choice precisely because it is the assumption everything falls back to.

Display P3 is a wider space used by many recent phones, tablets, and laptops. It reaches more saturated greens and reds than sRGB. An image in Display P3 with its profile intact looks richer on a capable screen and correct on an older one; the same image with its profile stripped looks oversaturated and wrong, because the extra-wide numbers get interpreted as sRGB.

Adobe RGB is a wider space traditionally used in print-oriented photography, chosen because it covers more of what certain printing processes can reproduce. It is a poor choice for web publishing for the same reason as Display P3 — if the profile is lost anywhere along the way, the image looks dull and flat.

ProPhoto RGB is wider still and is an editing space rather than a delivery space. Working in it preserves headroom during processing; publishing in it is asking for trouble.

CMYK is not an RGB space at all. It describes ink coverage for printing and is discussed below.

What stripping a profile actually does

Removing an ICC profile does not alter a single pixel value. It removes the note explaining what those values meant. The file is unchanged; its interpretation is now a guess.

If the image was sRGB to begin with, nothing visible happens, because the guess matches the reality. This is why stripping profiles is harmless for the overwhelming majority of web images and is a routine optimisation — the profile is a few kilobytes of data that changes nothing.

If the image was in a wider space, stripping the profile is destructive in effect if not in data. The wide-gamut numbers get read as sRGB numbers, and every colour shifts. Saturated areas typically look garish and the overall balance is off. The pixels are intact and the appearance is wrong.

The correct operation in that case is conversion rather than stripping: convert the image into sRGB, which recalculates the pixel values so they produce the same appearance in the narrower space, and then the profile is genuinely redundant. Converting changes the numbers to preserve the appearance; stripping keeps the numbers and changes the appearance.

PixelConvert rebuilds prepared outputs without copying the source profile, which is the right behavior for the sharing and upload workflows it is built for and a reason to keep the original when colour-managed output matters.

Print is a different problem

Screens emit light and combine red, green, and blue to do it; starting from black, adding more of each produces brighter colours. Print reflects light and uses cyan, magenta, yellow, and black inks; starting from white paper, adding more ink produces darker colours. These are opposite processes with different reachable ranges.

Some colours a screen can display cannot be reproduced in ink at all — intensely saturated blues and greens in particular, and anything relying on emitted brightness. Some ink colours, especially with specialist inks, fall outside what a typical screen shows. There is no setting that eliminates the mismatch because it is a physical difference between emitting and reflecting light.

Colour management narrows the gap by converting deliberately rather than accidentally, using a profile describing the specific printer, ink, and paper combination. The conversion decides how to handle colours that cannot be reproduced — compressing the whole range to preserve relationships, or clipping out-of-range colours to the nearest achievable one — and which choice is better depends on the image.

Practical advice for anyone sending work to print: ask the printer what they want, supply it in that form, and where colour accuracy matters, ask for a proof. A proof produced on the actual process is the only reliable preview, and it costs far less than a full run that comes back wrong.

Practical rules

For the web, publish in sRGB. Convert rather than strip if the source is in a wider space. This single rule prevents most colour complaints.

For an upload form or an unknown destination, sRGB again. Some validators reject CMYK or unusual profiles outright, and an image that has been through a print workflow is a common cause of an otherwise inexplicable rejection. Re-saving as plain sRGB is a cheap thing to try when a form refuses a file for no visible reason.

For photographic editing, work in a wider space if your tools and display support it, and convert to sRGB when exporting for the web. The wider space gives headroom during adjustment; the narrow one gives predictability on delivery.

For print, follow the printer's specification and keep your original. The file you send to print is a derivative built for one process, not an archival master.

And keep expectations realistic about matching. Two screens side by side will not match unless both are calibrated, and print will never match a screen exactly. Colour management makes differences small and predictable rather than large and arbitrary; it does not make them zero.

Diagnosing a colour problem

If an image looks oversaturated or garish in a browser but correct in an editor, the likely cause is a wide-gamut file whose profile was lost, with the numbers now being read as sRGB. Converting the original to sRGB fixes it.

If an image looks dull and flat on the web but rich in your editor, the likely cause is an Adobe RGB file published without conversion. Same fix.

If colours differ between two of your own screens, that is normal and expected unless both are calibrated. Judge colour on the display you trust, not the one that happens to be in front of you.

If a form rejects a file with no useful message and everything else checks out, try re-saving it as a plain sRGB baseline JPEG. CMYK sources and unusual profiles are a real and invisible cause of this.

If print came back different from the screen, compare it against a proof rather than against the monitor. If there was no proof, the lesson is to ask for one next time.