Why your photo looks washed out after you upload it
The colours were not compressed away. A small tag went missing, and the same numbers now mean duller colours. What colour profiles are, how they get lost, and how to stop it.
You take a photo on a recent phone. On the phone it is vivid — the red of a jacket, the green of a hillside. You put it on a website, or through a converter, or into a listing, and it comes back flatter. Not blurrier, not blockier. Just quieter, as though somebody moved a saturation slider down by a fifth.
Almost everybody blames compression. Compression is almost never what did it. What went missing was a few hundred bytes of description, and without it the same colour numbers have quietly started meaning something different.
A colour value is not a colour
In a file, a pixel is three numbers. Full red is 255, 0, 0.
That triple, on its own, does not name a colour. It says the reddest thing this file’s colour space can express — and how red that is depends entirely on which colour space is meant. It is the same problem as a recipe that calls for “one cup” without saying whose cup.
The specification of whose cup is the colour profile: a small block of data, usually an ICC profile, embedded in the file. It says which physical red, green and blue the numbers refer to, plus how the numbers scale into brightness. Strip it out and the numbers survive perfectly. Their meaning does not.
Two colour spaces, and the gap between them
sRGB was defined in 1996 to describe the average CRT monitor of the day. It is small, it is conservative, and it is why the web works at all: for twenty-five years it was a safe assumption that any screen could show roughly this range and no more.
Display P3 is what current phones, tablets and better laptops capture and display. It uses the more saturated primaries of the DCI-P3 cinema standard with sRGB’s white point and roughly its tone curve, and it reaches noticeably further into vivid reds, oranges and greens than sRGB can.
So a modern phone photograph frequently contains colours that literally have no sRGB equivalent. The file stores them as P3 numbers and attaches a P3 profile to explain itself. Everything is fine — as long as the explanation travels with the file.
The failure, in one table
Take a saturated red. In P3 it is stored near 255, 0, 0. What a viewer shows depends on the tag,
not on the pixels:
| What the file contains | What tag it carries | What you see |
|---|---|---|
| P3 numbers | P3 profile | The colour that was captured. Correct. |
| P3 numbers | nothing | Treated as sRGB. Every saturated colour lands short of where it should. Washed out. |
| sRGB numbers | sRGB profile, or nothing | Correct — untagged is assumed to be sRGB, and it is. |
| sRGB numbers | P3 profile | Pushed outward into a wider space. Oversaturated, sunburnt skin tones. |
The second row is the common one, and it explains the specific quality of the disappointment: it is not that the image got worse, it is that the extremes got pulled inward. Mid-greys, which are nearly identical in both spaces, do not move at all. That is why the photo looks flat rather than wrong.
Row four is rarer but memorable when it happens, because faces go orange.
Where the profile gets lost
Nothing announces this. The profile is simply not in the output file.
Metadata stripping. Tools that remove EXIF and other metadata to save bytes often remove the ICC profile at the same time, because as far as the code is concerned it is another chunk it did not recognise. On a large photo the profile is a rounding error in file size; on a small icon it can be half the file, which is why aggressive optimisers drop it by default.
Re-encoding through code that only handles pixels. A great deal of image processing decodes a file to a raw grid, does the work, and encodes a new file. If the code never reads the input profile, there is nothing to write back out, and the result is untagged by construction.
Screenshots. A screenshot of a P3 display is P3 data. Sent to somebody with no colour management in the path, it lands in row two.
Old export presets. “Save for web” settings inherited from a decade ago frequently have “embed colour profile” switched off, because in 2012 the bytes mattered more and everything was sRGB anyway.
Platforms that re-encode on receipt. Anything that generates its own thumbnails and variants is re-encoding your file with its own settings, and its handling of profiles is not something you control.
What to do about it
The reliable fix is not to preserve P3 everywhere. It is to decide, once, and convert deliberately.
For anything going on the web, convert to sRGB before you export. Note the verb: convert, not strip. Converting recalculates every pixel so that the colour stays as close as the smaller space allows — a slightly duller red, chosen on purpose, instead of the same numbers reinterpreted. Every operating system’s built-in preview app can do this, as can any editor, usually as “convert to profile” or an sRGB option in the export dialog.
Stripping, by contrast, changes nothing and hopes. That is exactly row two.
Do the colour conversion first, then everything else. Once a file is honestly sRGB, resizing, cropping and compressing cannot shift its colours, and it no longer matters whether the next tool in the chain understands profiles. If you are preparing images for a page, that order — convert, then resize to the pixel dimensions you need, then compress to the byte budget — is the one that never surprises you.
Test with one file before you do two hundred. Put the original and the output side by side on the same screen, full size. A colour shift is obvious in a direct comparison and nearly invisible in memory. It is worth doing this once for every tool and platform you rely on, and then not worrying about it again.
If your work is for print, do not convert to CMYK yourself unless the printer has asked you to and told you which profile. Their equipment and paper decide that, and a conversion done with the wrong assumption is harder to undo than one that was never done.
A note on the formats
Which format you choose does not cause the problem, but it does limit the options.
JPEG, PNG, WebP and AVIF can all carry an ICC profile. AVIF and HEIC additionally support a compact tag — a short code naming a standard colour space rather than a full profile — which is why a HEIC photo from a phone can describe itself in a handful of bytes. GIF cannot describe colour at all; its palette is interpreted as sRGB by convention.
None of this rescues an untagged file. If you have one and you no longer know what it was, the honest answer is that it is now sRGB — because that is what every viewer will assume, and any attempt to guess otherwise is just a different guess. If you still have the original, go back to it, convert properly, and export again. If you are changing format anyway, doing it in one deliberate step with a converter is less risky than a chain of tools each of which might quietly drop something.
The short version
- A pixel value means nothing without a colour profile; the profile is the units.
- Phone photos are usually Display P3. The web assumes sRGB. Untagged P3 is read as sRGB, and reads as washed out.
- Convert to sRGB deliberately. Do not strip the profile and hope.
- Convert first, then resize and compress.
- Compare one file side by side before you trust any tool with the rest.