Private Client Galleries for Boudoir Photographers

Break the worry into parts and it becomes answerable. A boudoir client is usually afraid of four things.

• A stranger finding the images. A gallery behind a password is not a public page that search engines index.
• Someone in her life seeing them by accident. A shared laptop, a forwarded email, a browser tab left open.
• You using them. Portfolio, social, a print on your studio wall. That is a paperwork question, answered in your release, not by a setting.
• The images living online forever. She wants to know there is an end, and who controls it.

Three of those four you control with how you set the gallery up and what you write in your contract. The fourth, what happens after she shares the link herself, is outside any platform's reach. Say so early and the rest of the conversation gets easier.

Every gallery can carry its own password. Nothing loads without it: not the thumbnails, not the full view, not the download. That is the control doing the real work, and it is the one to set before you send anything.

Here is the limit. A password stops someone who does not have it. It does not stop someone who does. If your client sends the link and the password to a friend, the friend is in, and the gallery cannot tell them apart. There is no per-person access and no way to revoke one viewer while keeping another.

Say that to the client directly. It turns a vague fear into a practical instruction: the link is hers, the password is hers, and if she passes them on she is choosing who sees the set. Generate a password for the gallery rather than using a name or a date, send it in a separate message from the link, and do not reuse it on another client.

Client-facing pages carry no platform branding, and galleries live on your own subdomain. The client sees your studio name in the address bar and your studio on the page. She does not see a software company's logo sitting under her portraits.

That matters more here than on a family session. The gallery reads as an extension of the business she hired and trusts. The URL she might paste somewhere also does not announce which platform you use or invite anyone to go looking for other galleries on it.

Boudoir sets are rarely uniform. A client often wants to show a few frames to a partner or a friend and keep the rest to herself. Sending individual files ends with images scattered across message threads. There is a better mechanism.

Inside a gallery you can organise images into sections. Sections are an organising tool on your side. The client is not asked to navigate anything: she sees one continuous scrolling page with a jump-to bar at the top that moves her between sections.

Each section also has its own standalone share link, and that is the useful part here. It opens a view-only page showing only that section. There is no ZIP download, no picks, no full-resolution download, no face search, and no link back to the parent gallery.

So the workflow is: put the frames she is comfortable showing into their own section, send her that section link, and keep the full gallery link private to her. Treat a section link as shareable by design, because that is what it is, and keep anything she would not want circulating out of it.

Face Search lets a guest upload a selfie and find themselves in a large gallery. It exists for weddings and events, where a hundred guests hunt for their own faces in three thousand photos. It is off by default and is switched on per gallery.

For boudoir work, leave it off. That is not a criticism of how it is built. The matching runs entirely inside the guest's browser, the selfie is never uploaded anywhere, and the index it matches against sits behind the gallery password. Those properties hold.

The reason to leave it off is about the promise you can make. Turning it on means face data is computed and stored for that gallery's photos. Deleting the gallery does not clear that stored data; deleting the account does. The gallery also shows a short disclosure and a file input before a guest uses the feature, which is not the same thing as asking someone to agree to something.

For a wedding, none of that is a problem. For an intimate set it means introducing a data type you did not need and cannot remove on its own later. Off is the simpler and more honest position, and it is where the setting already sits.

Downloads are a setting on the gallery and you can switch them off entirely. With downloads off, the client can view the set and make her picks, and no file leaves the page. That is often the right state during proofing.

If you take payment before delivery, know that this part is manual. You paste your own payment link into the gallery and the gallery shows it. Nothing connects that payment to the download setting. When you have been paid, you switch downloads on yourself. There is no automatic unlock, and you should not describe it to a client as though there is.

Manual is arguably the right shape for this work. You decide, deliberately, on one gallery, at one moment, that files can now leave.

Hosted galleries do not expire. They stay up while your account exists, so the end date is one you decide and can act on. If a client asks you to take the set down, you delete the gallery. Put that in your contract so she knows the answer before she asks.

Uploads are compressed in the browser into web-sized proof JPEGs before they are stored. Your RAW files and masters are not warehoused; they stay on your own drives, which is one fewer copy of an intimate set on someone else's servers. Full-resolution delivery is separate: you upload a ZIP for that gallery, it is live for three days per handoff, and you can re-upload it whenever you need it again.

The three-day window applies to that ZIP, not to the gallery link. The gallery link does not expire on a timer. Do not sell a time limit you do not have.

There is no seat model. No multi-user accounts, no roles, no separate login for an assistant or a second shooter. A two-person studio shares one account.

That cuts both ways. There is no standing assistant account with access to every gallery you have ever made, and nothing to revoke when someone leaves. There is also no limited retoucher login and no per-user record of who opened what. If your privacy promise depends on showing which staff member opened which gallery, say plainly that this tool does not do it.

A page about privacy that overclaims is worse than no page. Here is what is not on offer, so you never promise it by accident.

• No end-to-end encryption. Images are stored and served like normal web images behind an access check. Do not call the gallery encrypted.
• No screenshot blocking. Nothing stops a viewer capturing a screen, here or anywhere else.
• No forensic or invisible watermarking. There is no traceable mark that identifies who leaked a file.
• No expiring gallery links. The only time limit is the full-resolution ZIP handoff.
• No per-image or per-viewer permissions. Access is at the gallery level, and at the section level through a section's own share link.

If a client's requirements genuinely need one of those, tell her the tool does not have it. Losing a booking to an honest answer costs less than being the photographer who promised a set could not leak.

Keep the answer short and concrete. Something close to this works.

Your gallery sits on my own domain with a password only you have. Nobody finds it by searching, and there is no platform name on the page. I can send you a section link with just the frames you want to show someone, and that link goes nowhere near the rest of the set. I never turn face matching on for this work. Downloads stay off until I switch them on. Nothing goes in my portfolio unless you sign the release, and if you ever want it taken down, you tell me and I delete it.

Then the limit, in the same calm tone: once you have the link and the password, anyone you give them to can see the gallery, so keep them to yourself. That sentence is what makes the rest of it credible.

Every product fact on this page was verified in the clientgallery.io application code on 21 September 2026: gallery passwords, the absence of platform branding on client-facing pages, the studio subdomain, sections rendered as one scrolling page with a jump-to bar and their view-only standalone share links, the manual download setting and the pasted payment link, the browser-side Face Search behaviour and its off-by-default state, the single-account model, and the fair-use figures in the table above.

No third-party or competitor figures are cited, so no external source is listed.