Should You Upload RAW or JPEG Files to a Client Proofing Gallery?

• A RAW file is sensor data plus a recipe, so two people see two different images from one file.
• A client who approves a RAW file has approved a version you will never deliver.
• Browsers do not display RAW at all, so the gallery has nothing to draw.
• The files are far larger, on a device that is usually a phone on mobile data.
• Handing over the negative is a rights decision with a price, not an upload setting.

Four of those are technical and one is commercial. The commercial one is the reason to be deliberate rather than casual about it.

Adobe describes a RAW file as the uncompressed, unprocessed image data captured by the sensor, and states plainly that RAW files are not images in themselves: they have to be imported into software before they can be edited or exported as an image. What comes out of that software is an interpretation. Demosaicing, white balance, tone curve and colour profile are all applied at open time, by whichever converter happened to open the file.

So the same file opened in two different applications produces two different pictures. Not slightly different: different contrast, different colour, different saturation, sometimes a visibly different exposure. Adobe also notes that RAW formats are not standardised, which is why some software cannot read files from certain cameras at all.

Approval work requires one image that everyone sees the same way. A file whose appearance depends on the viewer's software is disqualified from that job before any other consideration. This is not a preference about workflow. It is the definition of the file format.

Your edit is the product. The client is not buying frames, they are buying finished photographs, and the edit is most of the distance between the two. A proof that shows the unedited capture asks the client to judge something you are not selling.

The practical damage arrives later. The client picks twenty frames from flat, unprocessed renderings. You edit those twenty and deliver them. The delivered files look different, because that is what editing is for, and now the client has a legitimate reason to say the delivery does not match what they chose. You created that argument at upload time.

Proof with the finished look, or close enough that the final file reads as a fulfilled promise rather than a surprise. If your edit is not ready, proof with a consistent baseline applied to the whole set and say so in the delivery message. Both of those are JPEG.

This is the part photographers underestimate. The image formats browsers actually render are a short list: APNG, AVIF, GIF, JPEG, JPEG XL, PNG, SVG and WebP, per Mozilla's own format guide. Camera RAW formats are not on it, and TIFF sits in the group that guide tells developers to avoid.

So a gallery of RAW files is not a slow gallery. It is not a gallery. Any platform that appears to show you RAW files is generating a JPEG preview behind the scenes and showing you that. You are already looking at a JPEG. The only question is whether you chose which one.

Size compounds it. RAW files are uncompressed by design, and Adobe lists their size as a disadvantage of the format. Clients overwhelmingly open proofing links on a phone, often on mobile data, often in a gap between other things. A set that takes minutes to become viewable is a set that gets closed and never reopened.

Suppose the client downloads the files instead of viewing them in the gallery. Now they need software that reads their camera model's flavour of RAW, since the formats are not standardised. If they find it, they install it, learn it, and then look at that application's interpretation of your work, which is the problem from two sections ago wearing a different coat.

Most clients will do none of that. They will reply asking what to do with these files, or say nothing at all, and your proofing round stalls for a week over a decision you made in an export dialog. The gallery link should lead directly to photographs. Nothing between the tap and the picture earns its place.

This argument is not technical, and it is the one worth thinking about properly. The RAW file is the negative. Whoever holds it can re-edit your work, publish a version you did not approve, hand it to another retoucher, or use it in ways your licence never covered. Once it is out, it does not come back.

None of that means you should never release originals. Plenty of commercial work is sold with the originals included, at a price that reflects it. The point is that it is a decision, made in the contract before the shoot, with a number attached. What it should never be is a default that happened because RAW files were sitting in the folder you dragged into the upload box.

A proofing round is exactly the wrong moment for that decision. The client has not chosen anything yet, the work is not finished, and in most cases the invoice is not settled. Proof with JPEGs, keep the negatives, and let the contract decide the rest.

These cases are real. A page that pretends otherwise is not worth trusting.

• A commercial or agency client who contracted for the originals. They bought them. They are a deliverable with a price on the invoice, handed over once at the end of the job.
• A retoucher or second editor working on the job. They need the negative to do the work you hired them for. They are a collaborator, not a proofing client, and they do not need picks, comments or a branded gallery.
• A studio handing a job to another photographer. Same logic. This is an archive move between professionals.

In all three, the mechanism is a file transfer, not a proofing gallery. Nothing a gallery does well applies: nobody is choosing favourites, nobody is browsing on a phone, and the recipient wants a folder structure rather than a grid.

Said plainly: clientgallery.io is not the right tool for that transfer. It hosts JPEGs. It does not warehouse RAW files or master video, and that limit is deliberate, because it is what keeps the price flat and the galleries fast. Move contracted originals the way you move any large archive, and use the gallery for the half of the job it is built for.

Choosing JPEG is the easy half. The half that changes how your work looks on a client's screen is what you do in the export.

Colour space: sRGB, without exception. The W3C colour specification for the web states that untagged images must be treated as sRGB unless something says otherwise. Profiles get stripped by intermediaries, ignored by older viewers, or lost when a client saves a copy. Export in AdobeRGB or ProPhoto and the moment the tag goes missing, those wide-gamut numbers are read as sRGB numbers, and saturated colours turn flat, dull or oddly shifted. Skin goes first. sRGB is defined by IEC 61966-2-1:1999 and registered by the ICC, and it is the fallback the web specification requires, so export into the assumption instead of betting against it.

Size: for the screen it will be judged on. A proof is a decision aid, not a print file. Size it to display cleanly on a laptop and a phone, and no larger. Anything beyond that costs load time and hands over a more usable file than you meant to. On clientgallery.io the sizing decision is largely made for you: photos are compressed in the browser into proof JPEGs of roughly 0.6 MB each as they upload.

Quality: there is no magic number, and anyone quoting one is guessing. Google's web.dev guidance makes the point that different tools do not interpret the same quality value the same way, and that across most of the scale the difference is invisible even side by side. So test once instead of arguing about numbers. Take your busiest frame, one with a smooth sky or a soft gradient behind a subject, export it at your candidate setting, and view it at the size a client will actually see. Step the setting down until block edges appear in the gradient, then go back up one notch. Save that as a preset and stop thinking about it.

Sharpening: for screen, at output size, after resizing. Sharpening applied before the downsize, or tuned for paper, reads as crunchy edges and halos on a phone. Sharpen last, judge it at full magnification on a screen, and be conservative. A proof that looks over-processed makes your finished work look worse than it is.

Metadata: strip location, keep authorship. There is no reason for GPS coordinates from a private home or a closed set to travel in a client-facing file. Your copyright and contact fields should stay.

Watermark: usually no, for private proofing. A watermark exists to protect a set that is visible before payment. It also makes photographs harder to judge and much harder to fall in love with, which is the opposite of what a proofing round is for. If the worry is use before payment, a password on the gallery and downloads switched off do that job without a logo across someone's face. Reserve watermarks for galleries that are public, promotional, or shown to people you have no agreement with.

Photos are compressed in the browser as they upload into proof JPEGs of about 0.6 MB each, and those galleries stay hosted for as long as the account exists. Fair use is written out rather than hidden: 1,000 photos per gallery and 250 GB of proofs per paid account, with free accounts holding 5 GB.

Full-resolution delivery is a separate, paid step, which is exactly the separation this page argues for. You upload a full-resolution ZIP for a gallery, it stays live for 3 days per handoff and can be re-uploaded any time the client needs it again, with 100 GB of standing ZIPs per account. Proofs are for choosing. The ZIP is for delivering. Neither is a RAW archive.

If you work in Lightroom Classic, the two-way plugin closes the loop without the RAW files ever leaving your studio. Proofs publish straight from the catalog, and the client's picks come back into it. The negatives stay on your drives, the client sees a fast gallery of the images you intended, and nothing in the middle has to be exported by hand.

• Adobe, "RAW file format", adobe.com/creativecloud/file-types/image/raw.html. Fetched 9 September 2026. Cited for: a RAW file is unprocessed sensor data, RAW files are not images in themselves and must be processed by software, RAW formats are not standardised so some software cannot read some cameras, and large file size.
• Mozilla Developer Network, "Image file type and format guide", developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types. Fetched 9 September 2026. Cited for: the list of image formats browsers render (APNG, AVIF, GIF, JPEG, JPEG XL, PNG, SVG, WebP), which contains no camera RAW format.
• W3C, "CSS Color Module Level 4", section on colour spaces of untagged colours, w3.org/TR/css-color-4/. Fetched 9 September 2026. Cited for: untagged images must be treated as sRGB unless otherwise specified.
• International Color Consortium, sRGB entry in the ICC RGB registry, registry.color.org/rgb-registry/srgb. Fetched 9 September 2026. Cited for: sRGB is defined by IEC 61966-2-1:1999.
• Google web.dev, "JPEG" chapter of Learn Images, web.dev/learn/images/jpeg. Fetched 9 September 2026. Cited for: quality is a 0 to 100 integer, tools do not interpret the same value identically, and most of the scale is visually indistinguishable side by side.
• clientgallery.io product behaviour (proof compression, hosting duration, fair-use ceilings, full-resolution ZIP handoff, Lightroom Classic plugin) is stated from the product itself.