Colour
Why Photos Look Different on Your Client's Phone
You approved the gallery on a screen you trust. Your client opened the same file on a phone and described something else. Both of you are looking at the same numbers, so the disagreement lives in one of two places: the file, or the screen.
Updated September 2026
This is one of the few complaints in photography where the client is not wrong and you are not wrong either. The file that left your machine is the file that arrived. Nothing in between edited it. And yet the two of you are describing different photographs.
That is possible because a photograph is not a picture until something decides what its numbers mean and then paints them onto a panel. Two decisions sit between your export and your client's eyes. The first belongs to the software showing the image, and it is governed by a written specification. The second belongs to the phone itself, and it changes on its own, without asking anybody.
This page separates those two, because they have completely different answers. One is worth checking on your own export before you reply to the email. The other is not fixable by you, by us, or by re-exporting anything, and the only useful response to it is a sentence you write once and reuse forever.
Cause one: the file, and what a viewer is required to do with it
Three numbers describe a colour only once you agree what those numbers mean. That agreement is the colour profile, and a JPEG either carries one or it does not.
This is not left to taste. The CSS Color Module Level 4 specification states that "colors specified in HTML, and untagged images must be treated as being in the sRGB color space", and that an image whose colour profile "is valid, must be treated as being in the specified color space". Read those two clauses together and you get the whole rule: tagged files are honoured as what they say they are, untagged files are read as sRGB.
The same baseline runs through the rest of the web. Colour functions in CSS work "in the implicit sRGB color space that most of the other color functions operate in" unless a different space is named explicitly. Wider spaces are reachable by name, including the Adobe RGB (1998) space, and a page can detect whether they are supported using the color-gamut media feature. Wider colour on the web is therefore something you ask for on purpose, never something that happens by default.
| What you uploaded | What the specification says a viewer does with it |
|---|---|
| JPEG with a valid embedded profile | It is treated as being in the space that profile specifies. |
| JPEG with no profile at all | It is treated as sRGB, whatever it was actually exported from. |
| JPEG exported in a wider space | Honoured when the profile is present and valid. With the profile gone, the sRGB rule above applies instead. |
| Colour in the page around the photo | sRGB unless the stylesheet names another space. |
Notice what that table does not claim. It says which space the numbers are read in. It does not describe how the result looks, because no specification describes that, and neither will this page. What matters operationally is simpler: if a file goes out untagged, the space it was exported from stops being part of the conversation. That is the one half of this problem sitting on your side of the wire.
Which space to pick, and why the gallery proof and the print-bound master can reasonably differ, is its own decision. It is laid out in Adobe RGB vs sRGB for client delivery, and the export dialog itself is covered in sRGB export for client proofing.
Cause two: the screen, which changes itself
Assume for a moment that the file is perfect. It still has to be painted onto a panel that the client carries around, and that panel is not a fixed instrument.
Apple documents True Tone on Mac as a feature that "uses advanced multichannel sensors to adjust the color and intensity of your display and Touch Bar to match the ambient light, so that images appear more natural". Read that carefully. The display is adjusted, continuously, in response to the room. Two people in two rooms are not being shown the same thing by design, and that is the feature working as documented.
Night Shift is the second one. Apple states that on iPhone and iPad it "automatically adjusts the colors of your display to the warmer end of the spectrum", and on Mac that it "automatically shifts the colors of your display to the warmer end of the color spectrum after dark". The Mac page also says plainly what warmer means: "Warmer color temperatures show more yellow and less blue."
Both of those adjust the display. Neither touches the photo. Your client's copy of the file is byte for byte the file you uploaded, and it will still be that file tomorrow morning when the screen has stopped being warm. This distinction is the thing to hold onto, because the email you are about to answer will describe a change to the photograph, and there was no change to the photograph.
Brightness belongs in the same category and gets less attention than it deserves. A phone held at half brightness, on a bus, in daylight, with a smudged screen, is not a colour-critical viewing environment and was never sold as one. Nobody would evaluate a print under those conditions. The phone does not announce that it is a poor place to judge a photograph, which is exactly why it gets trusted.
One related mechanism is genuinely about the file rather than the screen. Apple documents an HDR gain map stored alongside an image, which is why a photo can have more than one rendering, and that specific case has its own page at photos look dark on iPhone after export.
Check your own export before you reply
Four minutes of checking beats an afternoon of theory. Do this before you write back, because the answer you give depends entirely on which half of the problem you are in.
- Open the exported file, not the catalog. Your editing software shows you its own interpretation. Open the actual JPEG that went up.
- Confirm the profile survived the export. A file that left without a tag is read as sRGB by whatever opens it. That is the single check with a concrete fix behind it.
- Open the gallery on your own phone. Same file, different class of device. If it holds up on your phone and not on theirs, the file is not the variable.
- Turn your own warm modes and ambient adaptation off while you look. Otherwise you are comparing two moving targets.
- Ask the client one question. Not "what does it look like", but "which device and roughly what time of day". That one answer usually ends the investigation.
| What you find | Where the disagreement lives | What to do |
|---|---|---|
| The exported file has no embedded profile | The file. It is being read as sRGB regardless of origin. | Fix the export preset, re-upload, tell the client it is updated. |
| It matches your reference on your monitor and your phone | Their screen or their room. | Nothing technical. Send the paragraph in the next section. |
| It only disagrees in the evening or in bright sun | Ambient adaptation and warmth shifting on their display. | Ask them to look again in ordinary indoor light. |
| Every gallery you have ever sent draws the same comment | Your own reference, not their phone. | Audit your export and your editing environment once, properly. |
| One client, one device, nobody else | That device. | Leave it. Do not re-grade a shoot around a single screen. |
The last row is the expensive one. Re-editing a gallery to satisfy one phone moves the whole set away from your reference, and the next client with a different screen gets a worse file. Chase the file when the file is at fault. Do not chase a panel.
What to say to the client
Once you have checked, say the true thing plainly. Clients do not need colour science. They need to know that somebody competent already looked, and that what they have is correct.
Something close to this works: the files are correct and have not changed. Phone and laptop screens adjust their own colour and brightness to the room they are in, and warm evening display modes shift colours toward yellow, so the same photograph can read differently at different times of day on the same device. For a true look, view them indoors in ordinary light with the screen bright.
Three things to avoid in that reply. Do not apologise for a fault that does not exist, because it invites a re-edit request. Do not tell the client their phone is wrong, because it is a device they like and you are not going to win that. Do not promise a fix you cannot deliver, because there is no setting on your side, or on ours, that reaches into somebody else's display.
If the shoot is print-bound, this is the moment to say so. Screen appearance and print appearance are different questions with different reference conditions, and a client worrying about a phone is usually worrying about the wrong output.
Put it in the delivery note so it happens once
The difference between a studio that has this conversation on every job and one that has it almost never is not colour management. It is whether the expectation was set before the gallery link went out or after the complaint arrived.
Two or three sentences in the gallery welcome note and in the delivery email will do it. Say that the gallery is colour accurate as delivered. Say that screens differ, and that phones adjust their own colour and brightness to the room. Say which viewing condition you consider the reference, and say what the client should do if something looks off, which is to check on another screen in ordinary indoor light before writing to you.
Written in advance it reads as professional care. Written in response to a complaint it reads as an excuse, even when it is exactly the same paragraph. That is the entire reason to write it early.
It is worth knowing, in a general way, what your clients look at galleries on. On clientgallery.io the analytics dashboard is account-wide rather than per gallery, and one of the figures in it is a device split across mobile, desktop and tablet. If most of your account's traffic is mobile, the delivery note stops being a nicety. Galleries on small screens are covered in client galleries on mobile, and the studio-side app is in the client gallery app for iPhone.
What a proof is here, and what the handoff carries
Being straight about our own side of this matters, because a page about colour written by a gallery company should say what the gallery actually does to a photograph.
Normal uploads on clientgallery.io are compressed in the browser into proof JPEGs before they are hosted. A proof is a viewing copy. It exists so a client can scroll a large gallery quickly and pick, and it is not the file a lab should print from. We do not publish the proof's dimensions or quality setting, and you should not build a colour argument on top of a proof either.
Full-resolution delivery is a separate paid step, and it is a ZIP you upload yourself for a given gallery. It stays live for three days per handoff, it can be re-uploaded any time, and an account can hold 100 GB of standing ZIPs. Because you build that ZIP, whatever colour space you put in it is exactly what the client receives. That is the file to point a print lab at.
The plan is one plan, $10 a month or $100 a year. Unlimited galleries, photos and clients run under fair use, which means 1,000 photos per gallery and 250 GB of proofs per paid account, with free accounts holding 5 GB. None of those numbers changes what a client's screen does, and no pricing tier anywhere would. That is the honest shape of this problem: we can guarantee that the file we serve is the file you uploaded, and nobody can guarantee the panel it lands on.
Sources
Every colour rule and every quotation above traces to one of these pages, each fetched on 21 September 2026. The clientgallery.io plan, fair-use and delivery figures are our own product facts as they stand on that date.
- W3C, "CSS Color Module Level 4" (untagged images treated as sRGB, valid embedded profiles honoured) — https://www.w3.org/TR/css-color-4/ (fetched 21 September 2026)
- MDN Web Docs, "color() — CSS" (implicit sRGB space, predefined wider spaces including the Adobe RGB (1998) space, the color-gamut media feature) — https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color (fetched 21 September 2026)
- Apple, "Use True Tone on Mac" (the display is adjusted to match ambient light) — https://support.apple.com/en-us/HT208909 (fetched 21 September 2026)
- Apple, "Use Night Shift on your Mac" (colours shifted toward the warmer end after dark; warmer shows more yellow and less blue) — https://support.apple.com/en-us/102191 (fetched 21 September 2026)
- Apple, "Use Night Shift on your iPhone, iPad, and iPod touch" (display colours adjusted to the warmer end of the spectrum) — https://support.apple.com/en-us/118583 (fetched 21 September 2026)
Frequently asked
Why do my photos look different on my client's phone?
Two causes, and they need different answers. Either the file is being read in a colour space other than the one you exported from, which happens when a viewer has no valid embedded profile to honour and falls back to the sRGB default the web specifies, or the file is fine and the phone's own display is adapting to the room. Check the export first, because it is the only half you can fix.
Does the gallery change my photos?
Normal uploads are compressed in the browser into proof JPEGs, so a proof is a viewing copy sized for scrolling a large gallery, not a print file. The full-resolution handoff is a separate ZIP that you build and upload yourself, so its colour space is whatever you put in it.
Do True Tone and Night Shift change the photo file?
No. Apple's wording is that the display is adjusted. True Tone on Mac adjusts the colour and intensity of the display to match the ambient light, and Night Shift shifts display colours toward the warmer end, where warmer means more yellow and less blue. The photograph on disk is untouched, which is why it reads normally again under different conditions.
What happens if my export goes out without a colour profile?
The CSS Color Module Level 4 specification states that untagged images must be treated as being in the sRGB colour space, and that an image with a valid profile must be treated as being in the space that profile specifies. So an untagged file is read as sRGB no matter what it was exported from, and the space you chose stops being part of the conversation.
Should I re-edit the gallery so it matches what the client sees?
Almost never. Re-grading a shoot around one device moves the whole set away from your reference and hands the next client a worse file. Fix the file when the file is at fault, and otherwise explain the viewing conditions.
What should I write to a client who says the colours look off?
Say that the files are correct and have not changed, that screens adjust their own colour and brightness to the room, and that warm evening display modes push colours toward yellow, so the same photo can read differently at different times of day. Then ask them to look indoors in ordinary light with the screen bright.
Can any setting on the platform fix a client's screen?
No, and nobody should tell you otherwise. We can guarantee that the file served is the file uploaded. What a phone or a laptop does with brightness, ambient adaptation and warm modes is outside every photographer's control and outside ours. The durable fix is a delivery note that sets the expectation before the link goes out.
Your client galleries, under your name
Branded galleries, client selections and a Lightroom Classic workflow. Start with your first gallery, then compare the current plan. Full-resolution delivery is a separate handoff with its own limits and conditions.
Deliver galleries under your own name