Deliver an Online Gallery and a Full-Resolution ZIP From One Link

Nothing about two links is wrong on the day you send them. The failures show up weeks and months later, and they are always the same handful.

• The client bookmarks the pretty one. They save the gallery, because that is the page they enjoyed. The transfer link was a wall of text in an email, and the email is gone.
• The transfer expires while the gallery lives on. Now the client has a working link that shows photos and a dead link that held the files. From where they sit, the delivery half broke for no reason.
• Nobody remembers which link had the finals. You sent a preview set, then a corrected set, then the finals. Three links, three dates, one confused couple.
• The re-send request arrives eight months later. The client wants the files for an album, and you are the archive. You reopen the job, find the export, and rebuild a transfer by hand.
• Forwarding breaks it further. The client sends the gallery to a parent who wants prints. The parent gets the browsing half of the delivery and none of the files.

Every one of these is a routing problem, not a storage problem. The fix is to make one address the answer to every question the client will ever ask about this shoot.

A delivery link is asked to do two things that pull in opposite directions. Browsing wants small files, instant loading and a page that survives being forwarded to twenty people. Handover wants the heaviest version of every frame, downloaded once, by one person, on a computer.

clientgallery.io keeps both on the same page by serving two different assets from it. The photos you upload are compressed in your own browser into proof JPEGs of roughly 0.6 MB each, and those are what the gallery page renders. The full-resolution delivery is a separate ZIP you upload for that gallery, and the client reaches it from a button on the same page.

The client never has to know which is which. They see the gallery, and when the full-resolution ZIP is live they see one more button labelled with the file size and how many days are left on it.

This is the part a marketing page would skip, so here it is plainly. One link doing both jobs is true of the link. It is not true of the timing.

The gallery does not expire. It stays at the same address for as long as your account exists, and so do the proofs, the picks and the sharing. The full-resolution ZIP is a handoff, not storage. It stays live for three days from the moment you upload it, and then it goes. The gallery is untouched when it does. Only the heavy file leaves.

The recovery path is the reason this works in practice. You can upload the ZIP again at any time, and each upload restarts the three-day clock. An account can hold 100 GB of live ZIPs at once across all its galleries, and expired ones release their space, so re-issuing a delivery a year later costs you nothing but the upload. When the client writes in asking for the files again, you do not rebuild a transfer or hunt for a new host. You drop the ZIP back onto the gallery they already have bookmarked and reply with the same link you sent the first time.

Tell the client this in one sentence when you deliver. Something like: the gallery is yours to keep, the full-resolution download is live for three days, and if you miss it, ask and I will put it back. A window the client knows about is a policy. A window they discover on day four is a complaint.

The workflow below is the whole thing. It assumes the shoot is edited and exported.

1. Create the gallery and upload the photos. They are compressed in your browser on the way up and become the proofs the client browses. This is the page that will live at the client's address permanently.
2. Arrange it the way you want it read. A gallery can be divided into named sections, getting ready, ceremony, reception, and the client sees them as headed blocks on one page with a jump bar at the top.
3. Decide the download posture before you send. The per-gallery downloads toggle is on by default. If the delivery is gated on an invoice, switch it off now and back on later by hand.
4. Export the finals as one ZIP and upload it to that gallery. The studio page takes one ZIP per gallery. The quota is checked before the bytes start moving, so a file that will not fit is refused up front rather than halfway.
5. Send the link, once. The client link is on your own subdomain and carries your logo, your name, your colours and no platform branding. Both jobs now answer to that one address.
6. Re-upload when it is asked for. The studio shows Replace ZIP once one is present, with a countdown of the days remaining. Replacing it deletes the old object and restarts the clock.

Full-resolution delivery is part of the paid plan, which is $10 a month or $100 a year, and the refusal for an unpaid account happens on the server rather than in the interface. A free account holds one gallery.

Photographers who gate delivery on payment need to know exactly how strong the switch is, because a half-understood control is worse than none.

The per-gallery downloads toggle is checked on the server for the whole-gallery ZIP route. With downloads off, that route answers with a refusal, not a file. The single-image path is different: turning the toggle off hides the per-photo download button, but it does not make an individual proof URL unreachable. Treat it as a clear signal to an honest client rather than a lock against a determined one.

If you need a real barrier, use the gallery password instead. That check runs on the server before anything is rendered. Without the password the page returns only the prompt, the photos are never queried, and the whole-gallery ZIP and the full-resolution handoff both refuse the request as well.

There is a client this page does not fit, and pretending otherwise would waste your time. If what the client actually needs is permanent full-resolution access, meaning they expect to pull original-size files on demand in year two without asking you first, then a gallery with a handoff window is the wrong tool. A shared cloud folder is the honest recommendation for that case.

It is not a glamorous answer, and it is cheap. Every Google Account includes 15 GB of storage at no charge, and the 100 GB Google One plan is listed at CA$2.79 a month on the Canadian storefront. Dropbox Basic is free with 2 GB, and Dropbox Plus is listed at CA$12.99 a month for 2 TB, described as being for one person. Both prices are the Canadian storefront figures fetched on 7 September 2026.

A cloud folder buys you permanence and nothing else. There is no proofing, no picks, no branding, and the client is one wrong click from your other files. Worth knowing too: a Dropbox shared link does not expire on its own, expiry has to be set per link, and Dropbox publishes that setting as available on Professional, Essentials, Standard, Advanced, Business, Business Plus and Enterprise. So the trade is real in both directions. The folder keeps the files sitting there for as long as you keep paying for the storage, and gives you no control over the experience. The gallery owns the experience and puts a window on the heavy files.

The arrangement that works for most studios is not one or the other. The client link is the gallery, and it is the only address they ever get. Your own archive lives somewhere else entirely, off-site, and is never the same copy you deliver from. Delivery is not backup, and a delivery platform holding your only master is a plan waiting to fail.

Six lines, one link, one email. That is the whole delivery, and the client only ever has to keep track of one address.

• clientgallery.io product behaviour, plan price and limits, verified in the application code on 2026-09-07 (gallery hosting, proof compression, the 1,000-photo per gallery ceiling, the per-gallery full-resolution ZIP with its three-day window and 100 GB standing cap, the downloads toggle and the password gate).
• Google One plans and pricing, https://one.google.com/about/plans, fetched 2026-09-07 (Canadian storefront).
• Dropbox plans and pricing, https://www.dropbox.com/plans, fetched 2026-09-07 (Canadian storefront).
• Dropbox, Set shared link permissions, https://help.dropbox.com/share/set-link-permissions, fetched 2026-09-07.