When the Gallery ZIP Is Too Big for Your Client

Ask the client two questions before you touch a single file: what device are they on, and where did the download stop. The answers separate the four causes almost every time.

Notice how few of those rows are solved by sending the same link again. Notice also that the last row is the most common one in practice. A client who wants a photo for their mother does not want twelve gigabytes of master files.

There are two different downloads in a gallery and they are not the same size at all. Confusing them is what sends people hunting for a delivery problem that does not exist.

The everyday one is the whole-gallery download. One click gives the client a ZIP of every proof in the gallery, numbered in order, with no account to create at any point. Proofs are compressed in the browser before they are hosted, so this archive is a fraction of the master set. For a great many clients it is all they need until the final handoff.

Those figures come from an average proof of roughly 0.6 MB. They are arithmetic, not a measurement of your particular gallery, and a gallery of very detailed frames will sit above the line.

The second download is the full-resolution ZIP, and that is the one that gets heavy. It is heavy because it is your master JPEGs, which is the point of it. Its size is whatever you exported, and that is the lever this page is really about.

Here is the part that surprises people. The full-resolution ZIP is a file you build and upload yourself. The platform does not assemble it for you, which means you decide what goes in it.

So when a client cannot take the whole set at once, you do not need them to do anything clever. You build a smaller ZIP containing the part they need now, upload it, and tell them it is there. When they have it, you build the next part, upload that in its place, and tell them again. The client only ever clicks one button.

This costs you nothing in storage terms, and that is worth spelling out because it is not obvious. An account holds up to 100 GB of standing full-resolution ZIPs. Only live ones count against it. When you replace a ZIP, the space it held is freed first, so a five-part handoff never occupies more room than its largest single part.

The other number to keep in view is the handoff window. Each full-resolution link is live for three days per handoff. That window is the reason the fourth row of the diagnosis table exists. A client who went away for a week comes back to a link that no longer serves files, and the fix is a re-upload, not an apology.

The obvious idea is to organise the gallery into sections and send the client each section's own link, so they download the wedding in four smaller pieces. It does not work, and it is better to know that before you spend an evening on it.

Sections are a studio-side organising tool. You group a shoot into named sections and move photos between them, and the client sees one scrolling page with a jump-to bar at the top. A section does have its own standalone share link, but that page is view-only. It carries no ZIP, no picks and no full-resolution download, and it does not link back to the parent gallery. It is built for showing one part of a shoot to somebody who should not see the rest, which is a different job.

So the split has to happen in the ZIP you build. That is the only place where you can decide how heavy each piece is, which is exactly what you need control over.

Be honest with yourself about the connection at the other end. If a client is on rural satellite, on a metered mobile plan, or in a house where the connection drops every twenty minutes, no platform fixes that. Splitting the handoff makes each attempt survivable, which is a real improvement, but it is not magic and it will still take them several sessions.

For that client, a physical drive is sometimes simply the right answer. Copy the masters, hand it over or post it, and keep the hosted gallery for the proofing, the picks and the sharing with family. Nobody loses anything by admitting that, and the client gets their photos this week instead of next month.

There is one more case worth naming. If your masters are RAW files or video, this is not the tool for the handoff at all. Galleries accept JPG and PNG. There is no RAW and no video, which is deliberate, because not warehousing those files is part of what keeps the price flat. Deliver those on a drive or through a file-transfer service and use the gallery for what clients actually look at.

If you are earlier in the process and sizing the whole handoff rather than rescuing a failed one, the large-delivery guide works through the arithmetic, and the one-link guide covers keeping the proofs and the master set behind a single address.

This page states no competitor figure and no external figure of any kind. Everything numbered above is a clientgallery.io plan or fair-use figure, checked against the running product on 12 September 2026: 1,000 photos per gallery, 250 GB of proofs per paid account, 100 GB of standing full-resolution ZIPs per account with only live ZIPs counted and replacement freeing space first, and a three-day window per full-resolution handoff. Proofs are browser-compressed JPEGs of roughly 0.6 MB each, and the proof-ZIP weights in the second table are arithmetic from that average rather than a measurement of any particular gallery. Nothing on this page claims a download speed or a load time, because no dated measurement of either exists to cite.