How to Password Protect a Client Photo Gallery

Passwords on clientgallery.io are per gallery. They are opt-in and off by default, which is deliberate. Most galleries do not need one, and a password on a gallery that does not need it costs you a support message from a client who cannot find it.

In the studio, open the gallery and turn the password on. Type the password you want and save. From that moment the gallery link prompts for it. There is no account-wide password, no per-client login and no client account to manage. A client never signs in to anything. They open a link and, if the gallery is protected, they type one word.

Pick a password a human can read out over the phone. Your client will forward it in a text message, so a random string of symbols buys you nothing and costs them ten minutes. A short phrase tied to the job works well.

There is a gap in most gallery workflows that nobody talks about. You export, you upload, the gallery goes live, and then you go into the web interface and set the password. For those few minutes the gallery was live and open.

The clientgallery.io plugin for Lightroom Classic, which registers in Lightroom as "ClientGallery", closes that gap. The Export dialog carries a field for the gallery password. Fill it in, export, and the gallery is password-set the moment it publishes. There is no window in which the link exists unprotected, and there is no second trip to a browser.

That matters more than it sounds for confidential work. If you are publishing a brand shoot at the end of a long edit, the password is one field in a dialog you were already filling in, next to the settings you were already choosing. It gets set because it is in front of you, not because you remembered to go and do it afterwards.

The plugin works as both an Export service and a Publish Service, and it forces sRGB JPEG export settings rather than leaving them to chance. The published collection is the gallery. Full walkthrough in publishing a gallery from Lightroom Classic.

Password checks run on the server, not in the browser. That distinction matters: a check that runs in page code can be skipped by anyone willing to read the page source. These are enforced before the response is built.

Five of those six are the whole surface a person reaches through the link you sent. Send a protected link to the wrong address and the recipient sees a password prompt and nothing else. No thumbnails, no file names, no counts.

A gallery can hold sections, one level deep. Ceremony, reception, portraits. Product on white, lifestyle, detail. You can create them in the studio or get them automatically by dragging folders in, one section per folder.

A section link resolves to its parent gallery, so the parent's password covers every section inside it. You set one password for the job and every section link you hand out sits behind it. There is no per-section password to keep track of, and no section that is quietly open while the parent is closed.

Individual proof image URLs on clientgallery.io are public and they do not expire. The password stops the gallery page from handing those URLs out to anyone who has not typed it. It does not protect an image URL that somebody already holds.

In plain terms: a guest who saved or forwarded a direct image link before you set the password, or a client who copied one out of the gallery after typing the password, can still open that one image later without the password. The gate is on the gallery, on the downloads, on the comments and on face search. It is not on the individual image file sitting at a URL that has already left your control.

This is how most photo hosts behave, and we would rather write it down than let you discover it. So do not tell a client that a password protects every photo or every file, because that is not the claim we make and it is not what we built. Tell them the gallery is private, which is true, and use the tool below when private is not enough.

When material is genuinely sensitive, revocation is the real lever, not the password. Revoking a gallery kills the page, the whole-gallery download and the full-resolution link. It is a state change on our side, so it applies to everyone at once, including people who already have the link.

Reach for revocation, rather than a password change, when:

• A link went to the wrong recipient and you do not know how far it travelled.
• A campaign leaked early and the client needs the gallery closed today, not on the next round of edits.
• A job ended badly and you want the delivery surface gone rather than merely locked.
• The work was always meant to be temporary: a review round, a casting selection, a set shown to one stakeholder.

Changing a password locks out people who have not typed it yet. Revoking closes the gallery for everyone. If you are deciding between the two under pressure, revoke first and rebuild the gallery afterwards. A gallery is cheap to republish.

Worth keeping the two lifespans straight while you are here. Hosted galleries never expire on their own. The full-resolution ZIP is the part with a clock on it: it stays live for three days per handoff, and you can re-upload it whenever the client asks.

Agency work is where password handling usually breaks down. The gallery goes to an art director, who forwards it to a producer, who drops it in a channel with fourteen people in it. That is normal, and no gallery tool changes it.

The pattern that actually works:

• One password per job, circulated once. Not one per person. There is no per-recipient credential here, so pretending otherwise creates work with no benefit.
• Send it through the channel the team already uses. The project channel or the existing email thread beats a separate message they will lose. Put the link and the password in the same message, because splitting them across two channels is a ritual, not a control, once the team forwards both anyway.
• Name the gallery for the round. When the second and third rounds arrive, a team scrolling back needs to tell them apart.
• Use sections for a multi-day or multi-set job. One gallery, one password, a section per shoot day or per set. The team gets one credential and clean navigation.

The honest note to keep in mind: a password shared with a whole team is only as private as that team. Once it is in a channel, it is in an archive, in a search index and in the notifications of everyone who has ever been in that channel. It is a reasonable working assumption for a shoot under embargo among professionals. It is not a guarantee, and it should not be sold to a client as one.

More on agency delivery in delivering photos to an ad agency.

There is a line between confidential and merely unpublished, and it is worth knowing which side your job sits on.

Merely unpublished covers most work. A wedding the couple wants to share first. A product line announced next month. A headshot day where nobody wants a draft circulating. A password handles all of it, because the risk is casual discovery and a password removes casual discovery.

Confidential is different. If there is an embargo with a date attached, a non-disclosure agreement, or a client who will suffer real commercial damage from an early leak, the control is a contract plus a workflow that assumes links leak. That means naming who may receive the gallery, agreeing what happens if it goes wide, keeping the window short, and revoking on the publication date rather than leaving the gallery open forever. The password is one layer inside that plan, not the plan.

We wrote the workflow up separately in sharing unreleased campaign photos. If the words embargo or NDA appear in your job, read that one instead of relying on this page.