sRGB Export for Client Proofing

A colour in a photograph is not a colour. It is three numbers plus an agreement about what those numbers mean. The agreement is the colour profile. Every step below either honours that agreement, converts it correctly, or guesses.

Read the last column. You control four steps out of seven, and the only one where a wrong choice silently ruins the other six is the export. That is the whole reason this page exists.

In the Lightroom Classic export dialog, under File Settings, there is a Color Space dropdown. For anything a client will look at in a browser, it is sRGB. Not because sRGB is good, but because it is the assumption everything else falls back to.

The bottom two rows are the interesting ones. A wide-gamut file is not wrong. It is correct in every viewer that bothers to read its profile, and current desktop and mobile browsers do read it. The failure is what happens on the way past the browser: a photo saved to the camera roll and reopened in an app that does not colour manage, a file dragged into a chat window, a preview thumbnail, an older device, an image pasted into a document. Each of those reads your Adobe RGB numbers as sRGB numbers and quietly desaturates the photo.

sRGB survives all of that, because the wrong guess and the right answer are the same guess. That is the entire argument. It is not a quality argument, and anyone telling you that sRGB throws away colour your client would otherwise have seen is describing a viewing setup most clients do not have.

The export dialog is the fallback path. The Lightroom Classic publish service that ships with clientgallery.io renders JPEG in sRGB automatically, with location metadata stripped, so a studio publishing from the catalog never has to remember either setting. There is no Color Space dropdown to get wrong, because there is no dropdown.

That is worth saying plainly because it is the failure mode this whole page is about. Colour management does not usually break through ignorance. It breaks because someone built a print export preset in March, used it in November, and the dialog remembered the last setting. A publish service has no memory to get wrong.

The rest of that workflow is described in the two-way Lightroom workflow guide. If you are not using the publish service and want a hand-built preset instead, the export preset guide covers the whole dialog rather than just the colour part.

One detail specific to proofing galleries. Proofs here are browser-compressed JPEGs of roughly 0.6 MB each, so exporting a very large file to protect colour accuracy buys you nothing except a slower upload. Get the colour space right and the file size question takes care of itself.

Here is the honest half. Exporting in sRGB fixes the class of problem where a correct file is misread. It does nothing at all about the class of problem where a correct file is displayed correctly on a screen that is simply not yours.

A client on an uncalibrated laptop is not seeing your edit. A client on a phone at maximum brightness in a bright room is not seeing your edit. A client whose display runs a warm night mode after eight in the evening is not seeing your edit. A client on a television is definitely not seeing your edit. None of that is a colour management fault, and no export setting reaches any of it.

This matters because photographers waste real time re-exporting galleries to chase a difference that lives on the other end of the wire. The useful diagnostic is cheap.

The sentence worth keeping in a text file: the gallery is colour accurate, and screens vary in brightness and colour, so the files you receive are the reference and your phone is not. Said once, before delivery, it prevents most of these conversations.

Everything above is about proofing on screens. If the same shoot is going to a lab, an art director or a printer, do not let a web proofing rule leak into that path. A print deliverable has its own colour space, often its own profile from the lab, and its own soft-proofing step, and an sRGB web proof is a preview of it rather than the thing itself.

Run two exports. One in sRGB for the gallery, so the client can look and pick. One built to the lab specification, delivered the way that lab asks for it. They are not the same file and trying to make one file serve both is how a gallery ends up looking flat and a print ends up looking wrong at the same time.

The same caution applies to the full-resolution handoff. What the client downloads is the ZIP you uploaded yourself, so whatever colour space you put in that ZIP is what they get. If your clients open their finals in colour-managed software, an sRGB gallery proof and a wider-gamut master in the ZIP is a perfectly sensible pair. If they open them in whatever their computer opens by default, make the ZIP sRGB too.

One more thing that is not colour management but gets blamed on it. The gallery hosts JPEG. It does not warehouse raw files or master video, which is part of why the price stays flat, and it is also why the colour decision happens in your export rather than on the platform.

Three cases where the correct action is no action.

Your current exports already say sRGB. Then this was never your problem and changing tools will not change what your client sees. Check the preset, confirm it, and move on to the viewing-conditions conversation instead.

Your clients are print buyers working in a managed environment. If your deliverable is a wide-gamut or CMYK file and your client has the setup to read it, an sRGB web proof is a courtesy, not the product. Keep the pipeline you have.

Nobody has complained. Colour management rewards attention only where there is a symptom. If your galleries look right to you and your clients are quiet, spend the afternoon on something that earns money. Set the export preset to sRGB once so the question cannot come back, and stop there.

Nothing on this page requires buying anything. The fix is a dropdown in software you already own. If you want the wider picture of how proofing fits together, the client proofing guide covers the workflow that this colour decision is supposed to serve.

This page states no external figures, so there is nothing to cite from another platform. The clientgallery.io facts used above are the plan and fair-use figures as checked in the running product on 12 September 2026: one plan at 10 $/month or 100 $/year with the first gallery free, proofs as browser-compressed JPEGs of roughly 0.6 MB each, the Lightroom Classic publish service rendering JPEG in sRGB with location metadata stripped, and full-resolution delivery as a ZIP the studio uploads itself. Colour space behaviour described here is the documented behaviour of the Lightroom Classic export dialog and of profile-aware and profile-ignoring viewers in general, not a measurement taken on a particular device.