Image Compression for Proofing Galleries: How Far to Go
Resize first, budget the bytes, and test the three frames that break first.
A 6000 × 4000 frame holds 24,000,000 pixels. Stored uncompressed at three bytes a pixel, that is 72 MB, and nobody emails 72 MB to a client to pick a favourite. So every proofing gallery compresses, and the real question is how much image compression a proofing gallery can take before the client starts judging your retouching on artifacts you never put there.
The short answer: compress until the file is small enough to load on a phone on mobile data, and stop one step before gradients band or skin turns blotchy. That point is different for every photographer's work, so this post gives you the arithmetic for the size side and a ten-minute test for the quality side. It does not give you a magic quality number, because nobody can honestly hand you one.
What you are actually trading
A proof does two jobs. It has to be fast (a client opening a link on a train will not wait) and faithful enough that a decision made on it still holds for the final. Compression buys the first and spends the second.
The pixel count does most of the work before any quality setting is touched. Resizing a 6000 × 4000 original to 2048 pixels on the long edge gives 2048 × 1365 = 2,795,520 pixels, about 11.6% of the original (2,795,520 ÷ 24,000,000). That is an 88% cut in pixels with no compression artifact at all, which is why resizing comes first and the quality slider second.
| Step | Pixels | Uncompressed at 3 bytes/pixel |
|---|---|---|
| Original, 6000 × 4000 | 24,000,000 | 72 MB |
| Long edge 2048 px | 2,795,520 | about 8.4 MB |
| Long edge 1600 px | 1,600 × 1,067 = 1,707,200 | about 5.1 MB |
Those are raw pixel arithmetic, not file sizes. A JPEG stores far less than that; how much less depends on the picture. Detailed foliage compresses poorly and a seamless studio backdrop compresses very well, which is why one quality number gives wildly different file sizes across a shoot.
What too much compression looks like
JPEG works on 8 × 8 pixel blocks, and when the quality setting drops far enough the blocks start to show. These are the artifacts clients notice, in roughly the order they appear:
- Banding in smooth gradients. Studio backdrops, skies and out-of-focus backgrounds turn from a smooth ramp into visible steps.
- Blotchy skin. Fine texture is thrown away first, so retouched skin goes waxy or mottled in a way your master does not.
- Ringing around edges. A faint halo around hair against a bright sky, or around text on packaging.
- Colour bleed. Most JPEG encoders store colour at lower resolution than brightness by default, so saturated red or blue edges can smear.
The trap is that each of these reads as a retouching problem. A client who sees blotchy skin on a proof writes “skin looks rough” as a note, and you spend a revision round fixing something that exists only in the proof. If you are already trying to translate vague client feedback into real edits, do not hand them a source of false notes.
A size budget you can calculate
Instead of choosing a quality number, choose a size budget and let the encoder find the quality that meets it. Here is the arithmetic for one gallery of 300 frames:
The bar widths are proportional to the totals (240 ÷ 750 = 32%, 90 ÷ 750 = 12%). A client scrolling the whole gallery on mobile data loads a large share of those bytes, which is why the average matters more than any single file.
A per-frame budget also forces the right order of operations: resize first, then lower quality only as far as the budget needs. If the file is still too big after both, the fix is usually fewer frames in the gallery, not a lower quality setting. See whether clients need to see every frame for that decision.
A ten-minute test on your own frames
Because the threshold depends on your style, test it on your work. You need three frames that stress the encoder differently:
- One with a smooth gradient, such as a seamless backdrop or a clean sky.
- One close portrait with skin and hair detail.
- One busy frame, such as foliage or a patterned fabric.
Export each at descending quality settings and view them at 100% on your own screen, then on a phone. Note the first setting where you can see a difference from the setting above it. Then back up one step. That is your floor for that kind of picture.
Judge the gradient frame first. Banding appears there before it appears anywhere else, so if the backdrop holds, the other two almost certainly do too.
View on the device the client will use. A flaw that is invisible on a calibrated desktop can show on a bright phone, and the reverse can happen too; client screens differ in ways you cannot control.
Where compression should not touch the file
Two things do not belong in the compression conversation. The first is the master: the proof is a derivative, and the original stays untouched. Reviewing a proxy is normal, and RAW files in client review covers why clients get proxies rather than the file you shot.
The second is format. JPEG is the safe default because every phone and browser opens it. Newer formats can reach a given quality at a smaller size, but support and colour handling vary, and that is its own trade-off covered in JPEG vs HEIC, WebP and AVIF for client galleries.
One more point for anyone who reviews inside an app: a review tool that keeps your uploaded original and serves smaller previews, as Appruva does, gives you this separation by design. The compression question then applies only to the preview, never to what you eventually deliver.
How many pixels a phone screen can show
Resolution is where most of the waste hides. A phone whose screen is 390 CSS pixels wide at a 3× pixel ratio has 390 × 3 = 1,170 physical pixels across. A portrait frame shown full width on that phone can only display 1,170 pixels of width, so a 2048-pixel-wide file carries 2048 ÷ 1170 ≈ 1.75 times more width than the screen can show.
A laptop is the opposite case. A 2560-pixel-wide display showing a frame at full screen width can use every pixel of a 2048-pixel file and then some, so the same proof looks slightly soft there. That is the real argument for a pair of sizes: a smaller file for the first load and a larger one when the client zooms in to check a detail, rather than one compromise size for everybody.
The practical rule is to match the file to the job. A thumbnail grid needs files measured in tens of kilobytes. A full-frame view needs the 1600 to 2048 range. Zoom-to-check-focus is the only moment that justifies something bigger, and clients ask for that on a small share of frames, so it should load on demand rather than up front.
Sharpening, noise and the file you export
Output sharpening interacts with compression, and it is easy to get wrong. Sharpen a large image, shrink it, and the sharpening halos shrink with it; sharpen after resizing and the halos stay crisp, which is what you want on screen. Over-sharpening also makes the encoder work harder, because it spends bytes preserving edges you added.
Noise has the same effect from the other direction. Fine grain or high-ISO noise is expensive to encode, so a noisy frame produces a much bigger file than a clean one at identical settings. If a handful of frames blow your size budget, check for noise before you blame the quality slider. Light noise reduction on the proof only, never on the master, can bring them in line.
Finally, embed or convert to sRGB for proofs. A wide-gamut file stripped of its profile can look dull or oversaturated depending on the browser, and a client who sees the wrong colour will say so. Our sRGB vs Adobe RGB vs P3 guide explains the choice in detail.
If a proof looks different from the master, rule out colour space and compression separately. Changing both at once makes it impossible to tell which one the client is reacting to.
A defensible default
If you want a starting point rather than a test, use this and adjust after your ten minutes:
Common mistakes
- Exporting proofs at full resolution
- One quality number for every frame
- Judging only on a desktop monitor
- Re-compressing an already-compressed proof
Safer habits
- Resize to roughly 1600–2048 px on the long edge first
- Set a size budget, not a quality number
- Check the gradient frame on a phone
- Always export proofs from the master
The last habit matters more than it sounds. Every time a JPEG is re-saved as a JPEG, it loses detail again, so a proof made from last round's proof gets worse each round. Always go back to the master. If a client asks for a closer look at one frame, re-export that frame from the master at a larger size instead of enlarging the proof, because upscaling a compressed file only magnifies its artifacts.
Frequently asked questions
What JPEG quality should I use for client proofs?
There is no single correct number, because the same setting gives different results on a smooth backdrop and on foliage. Resize to about 1600 to 2048 pixels on the long edge, then pick the lowest quality where a gradient frame shows no banding when viewed on a phone.
What resolution should proofing images be?
Roughly 1600 to 2048 pixels on the long edge is a common range for screen review. At 2048 × 1365 a frame has about 2.8 million pixels, around 11.6% of a 24-megapixel original, which keeps files small while staying sharp on most screens.
How can I tell if my proofs are over-compressed?
Look at smooth gradients first for visible banding, then at skin for a waxy or blotchy texture, then at hair and edges for halos. If any of these appear in the proof but not in your master, the compression is too heavy.
Should I watermark and compress proofs?
They are separate decisions. Compression affects how the image looks and loads; watermarking affects whether it can be reused. Do both from the master in one export so you only encode the file once.
Why do clients say the skin looks rough when my master is clean?
Heavy compression removes fine texture and can leave skin blotchy, which clients read as a retouching problem. Compare the proof to the master at the same zoom before accepting the note.