How to Share Design Mockups Securely (Figma Exports, Prototypes, Screenshots) — Without Leaking Your Client’s Launch

If you do any kind of client work—branding, product design, UI/UX, landing pages—you’ve probably had this moment: you export a few PNGs, paste them into a chat, and instantly regret it.

Not because the work is bad. Because the workflow is leaky. Images get forwarded, saved to personal photo libraries, re-uploaded to random “temporary” hosting sites, or indexed by search engines. A single mockup can reveal a product name, a launch date, pricing, internal URLs, or customer data in test screenshots.

This guide is my practical, repeatable process for sharing design mockups fast while reducing the chance of accidental leaks. I’m writing it for the real world: clients on mobile, approvals in Slack/WhatsApp, and deadlines that don’t care about perfect security.

Why mockups leak more than you think

A mockup file is usually “just an image,” but it tends to include:

• Brand secrets: product name, tagline, positioning, campaign themes
• Launch details: dates, pricing tiers, promotions, discount codes
• Operational info: internal links, staging domains, admin panels, feature flags
• Personal data: user emails, addresses, phone numbers in screenshots
• Metadata: file names, sometimes EXIF (for camera photos of whiteboards)

The “leak” is rarely malicious. It’s typically a forward (“hey, can you weigh in?”), a screenshot reposted to a group, or an old link that stays accessible for months.

My default workflow (10 minutes) for secure client sharing

Step 1) Split your files: ORIGINALS vs SHARE

Create two folders: ORIGINALS (untouched exports) and SHARE(sanitized copies).

This saves you later when a client asks, “Can you send the version with the full pricing table?” and you realize you’ve permanently redacted it.

Step 2) Audit the canvas before exporting

Before you export from Figma/Sketch, zoom out and scan for the boring stuff that causes disasters:

• Old drafts with the real name of the product
• Sticky notes with credentials (yes, it happens)
• Hidden layers showing real customer data
• Comments that reveal strategy (“CEO hates this section”)

If you can remove it in the source file, do that first. Redaction is a fallback—not the first line of defense.

Step 3) Redact with opaque blocks (not blur)

If you need to hide something, use opaque rectangles (solid color). Blur can be partially reversible in some cases, and it always looks suspicious.

Common fields I redact:

• Emails / phone numbers in dashboard screenshots
• API endpoints, internal tool URLs, admin paths
• Promo codes that aren’t live yet
• Exact pricing if the client only needs layout approval

Step 4) Decide: “Preview” vs “Deliverable”

I treat design sharing as two different modes:

• Preview: low risk, quick feedback. Use fewer screens, minimal detail, shorter expiry.
• Deliverable: final assets or high-fidelity prototype. Longer expiry, clear structure, versioning.

The mistake is sending deliverable-grade detail when the client only needs a yes/no on layout.

Step 5) Use an expiring link you can revoke

Don’t send mockups as permanent URLs or attachments by default. Attachments get forwarded and stored forever.

Instead, upload your SHARE folder and generate:

• An expiring link (24 hours for previews, 7 days for typical review cycles)
• A separate password (sent in a different channel)
• A per-recipient link when multiple people need access (so you can revoke selectively)

Step 6) Name versions like a human

Clients don’t think in “v12-final-FINAL-2.png”. They think in decisions. I use:

• 2026-04-24 — date
• LP Hero Option A — what decision this file supports
• Approved / Needs edits — status

This reduces “wrong file” mistakes more than any security trick.

Practical settings I use (and why)

How long should the link last?

• 24 hours: first impressions, early previews, sensitive pricing
• 7 days: normal review cycles, stakeholder feedback
• 30 days: only when explicitly requested (and I still prefer re-issuing)

Should I watermark client previews?

Sometimes. Watermarks can help discourage casual sharing, but they also make feedback harder. My compromise:

• Watermark early concept boards
• Don’t watermark detailed UI screens where the client needs to read copy

What about prototypes?

Prototypes are trickier because links tend to live forever. If you must share a prototype link, consider:

• Turning off public indexing
• Using a password or invite list
• Making a “review-only” prototype without real data

“Client-friendly security” scripts you can paste

Message template for Slack / WhatsApp

Copy-paste this (it reduces confusion and stops clients from forwarding everything blindly):

Here are the latest mockups for review. The link expires in 7 days and can be revoked. Password sent separately. If you need to share with another stakeholder, tell me and I’ll generate a new link for them.

Simple approval checklist

• Layout: approved / changes
• Copy: approved / changes
• Brand: approved / changes
• Notes: (one sentence)

Final thoughts

Secure sharing doesn’t need to be dramatic. The goal isn’t “perfect security”—it’s reducing the most common failure modes: forwarding, permanent links, and accidental over-sharing.

If you adopt only one habit from this guide, make it this: always share a sanitized copy via an expiring link you can revoke. It’s the simplest upgrade with the biggest upside.