Appruva

Why Client Monitors Show Your Photos Differently

Five causes behind "the colours look off" emails, and how to tell a file problem from a screen problem.

Client monitors show your photos differently because every screen decodes the same file with its own brightness, white point and gamut, and some of them ignore the embedded colour profile entirely. Three reviewers on two devices each means six different renderings of every frame, and only one of them is the one you graded on.

You cannot calibrate a client's screen. You can control the file you send, the way it is tagged, and how you ask people to look at it. This post covers the five causes behind most “the skin looks orange” emails, what to check first, and how to keep the argument about a frame instead of a monitor.

Five reasons the same JPEG looks different

Almost every colour complaint traces back to one of five things. They stack, which is why a note like “too warm” is so hard to act on.

CauseWhat changes on the client's screenCan you control it?
Colour profile ignoredAn untagged or unmanaged viewer treats pixel values as if they were the screen's own colour space, so saturation shiftsYes: tag the file
Wide-gamut screen, sRGB fileAn app that skips colour management stretches sRGB values across a wider gamut and everything looks over-saturatedPartly: sRGB is the safest bet
Brightness and contrastShadows clip or wash out depending on backlight level and ambient lightNo
White point shiftsNight-shift and True Tone style features tint the whole display warmerAsk the client to turn them off
Where it is viewedAn email preview, a chat app and a browser tab can each recompress or re-render the imageYes: send one review link, not attachments

The first row is the one you own completely. The rest you can only reduce, and the next sections go through how.

Tag the file and keep to sRGB for review

For proofing, deliver sRGB with the profile embedded. Browsers colour-manage tagged images, so an embedded profile gives the viewer what they need to render it correctly; an untagged file leaves them guessing, and the usual guess is sRGB. Wide-gamut files look better on a wide-gamut screen that handles them properly, but a review round is the wrong place to find out which of your client's apps do not. The full trade-off, including when Display P3 earns its place, is in sRGB vs Adobe RGB vs P3 for client delivery.

Two quick checks before sending a round:

  • Export, then re-open the export. Open the exported JPEG in a browser and compare it with the file in your editor. If they differ here, they will differ for the client.
  • Check the profile survived. Exports that strip metadata for privacy can strip the profile too. Confirm it is still there after your export preset runs.

If you also strip location and camera data before sending, see what to strip before delivery and keep the colour profile out of that list.

Phones, dark mode and in-app browsers

More approvals now happen on a phone than anyone planned for, and a phone adds its own layers. Auto-brightness changes the backlight as the client walks from a desk to a window. Dark mode puts a near-black frame around the photograph, which makes midtones look brighter by contrast. Tapping a link inside a chat or email app often opens an in-app browser, which may not behave like the client's main browser. None of these is a fault in your file, but each changes how it reads.

The practical consequence is that a phone review is good for composition, expression and crop, and weaker for fine colour judgement. Say so when you send the link: ask for gut reactions on framing and selection from the phone, and save critical colour sign-off for a laptop session. If you are building rounds for people who only ever check on a phone, designing for phone-only approvers covers the rest of that problem.

  • Auto-brightness: a fixed brightness during the round removes one variable at no cost.
  • Dark mode: surrounding black exaggerates highlights, so judge exposure against a neutral grey background where you can.
  • In-app browsers: if a frame looks odd, ask the client to open the link in their regular browser before you change anything.

Count the renderings so you stop chasing ghosts

The arithmetic of a review round explains why colour feedback feels random. Take a modest case: 40 frames, 3 reviewers, 2 devices each (a laptop and a phone).

3 reviewers × 2 devices = 6 renderings of every frame. 6 renderings × 40 frames = 240 separate looks at your work, none of which you saw. If even one reviewer is on an office monitor with the brightness pushed up, one person's “too dark” can be another's “perfect” on the very same file.

That is why a colour note needs an anchor. “Warmer” on the whole gallery cannot be checked by anyone. “The white shirt in the lower left reads yellow” can be checked against a known neutral in your own file. This is the same reason per-image comments beat whole-gallery feedback: the note is tied to a place you can measure.

Ask the client to set up the room, then check before you send

Nobody will calibrate a screen for a review round, but a 20-second instruction removes the two biggest variables. Put it at the top of the review message, not in a PDF:

  1. Turn off night-shift or True Tone style warm-tint features while reviewing.
  2. Set brightness to a comfortable mid-to-high level and keep it fixed.
  3. Review on a laptop or desktop screen if the shoot is for print or a hero banner, and on a phone if the final destination is social.
  4. Do not judge colour from an email preview or a chat thumbnail.
Pro Tip

Match the device to the destination. A frame that will live on Instagram should be approved on a phone. A frame going to a brochure should be approved on the best screen the client has, with the caveat that screens never replace a printed proof.

Most of the avoidable colour disputes are caught by a routine you run before the link goes out. It costs minutes, and it saves a round, which is the expensive unit: a single extra round means another pass through export, upload, client review and revision.

  1. Re-open the exports. Look at three or four frames, including your hardest skin tone and any frame with a large neutral area, in a browser rather than your editor.
  2. Confirm the profile. Make sure the delivered files are tagged sRGB and not stripped.
  3. Look at it on a phone. Your own phone is the cheapest second device you have. A frame that looks wrong there will look wrong for the client.
  4. Write the viewing note. Two lines at the top of the message: turn off warm-tint features, hold brightness steady, and say which device you want for which decision.
  5. Label the round. Name it clearly so feedback about version two is never confused with version one.

The step people skip is the third one. It takes one minute and it tells you whether the problem you are about to be blamed for is real.

Where this stops

None of this makes a client's screen accurate. It narrows the gap enough that a colour note is about the photograph. If colour is the product, as in apparel or print, agree on a printed or hardware-calibrated proof in the brief rather than trying to win the argument on a laptop.

Turn a screen disagreement into a checkable note

When a client says a frame looks wrong, ask for the location and the device before you touch a slider. In Appruva the client can draw on the frame itself, so the note arrives pinned to the area they mean, which lets you sample that region in your own calibrated setup and decide whether the file or the screen is at fault.

Vague colour note

  • “It looks too warm overall”
  • No device, no location
  • You re-grade the whole set and risk breaking the frames that were fine

Anchored colour note

  • Marked on the shirt, lower left
  • Device and brightness stated
  • You sample that area, compare with a known neutral, and change one thing or none

A practical rule: if the sampled neutral reads neutral in your file and the file is tagged sRGB, the problem is the screen, and the right answer is a short note asking the client to check on a second device. If the neutral really is off, fix it and send the next round as a clearly labelled new version so nobody compares against the wrong one.

When the destination is print or a retoucher

Approving on screen and delivering for print are different jobs, and mixing them is a common source of late surprises. A client who signs off a bright, saturated phone view may be disappointed by an ink-on-paper result that cannot reproduce the same colours. Say early which destination governs the decision, and keep that destination in the note on the frame.

When the frame is headed for a retoucher, anchored notes matter more still, because the retoucher works in a calibrated environment and cannot guess which of six renderings the client was reacting to. A note that says where on the frame, which device and what the client expected gives the retoucher something to sample and compare. For the wider habit of writing notes this way, see translating vague client photo feedback into real edits. If the retoucher works in Photoshop, the Appruva panel brings those notes and their markup onto the file, so the pinned area is on the canvas rather than in an email.

Frequently asked questions

Why do my photos look different on my client's screen?

Because each screen has its own brightness, white point and colour gamut, and some apps ignore the embedded colour profile. The same file is rendered differently on each device even though the pixels are identical.

What colour space should I send to clients for review?

sRGB with the colour profile embedded is the safest choice for review rounds, because it is the assumed default when software does not manage colour. Wide-gamut files such as Display P3 can look better on supporting screens but behave less predictably elsewhere.

Should I tell clients to calibrate their monitor?

No, that is an unrealistic request. Ask for the two things that are easy: turn off night-shift or True Tone style tinting, and keep brightness fixed while reviewing.

Why do my photos look more saturated on a phone?

Phone screens are often wide-gamut and bright. If an app shows an untagged or sRGB image without colour management, the values are stretched over the wider gamut and look more saturated. Tagging the file and viewing it in a colour-managed browser usually fixes this.

How do I know if the problem is my file or the client's screen?

Open your exported file in a browser on your own calibrated screen and check a known neutral, such as a grey card or white shirt. If it reads neutral there and the profile is embedded, the difference is on the client's side.