How to Send Large Files Securely: Passwords, Permissions, and Practical Defaults

Security that fits creative work (without slowing you down)

When you send large files to clients and collaborators, the real goal is simple: the right people get the right files, and nobody else does. That usually comes down to a handful of practical choices you can make every time you share: link settings, access control, expiration, and a clean handoff message.

Below is a straightforward approach you can apply whether you’re sending a video cut, a photo gallery, final exports, or source files-especially when email attachment limits make “just attach it” impossible.

Step 1: Decide what “access” should mean for this delivery

Before you upload anything, pick the access model that matches the situation:

1. Client review delivery: client should download finals (and maybe previews), but not necessarily source files.
2. Collaboration handoff: a teammate or vendor needs the full package (exports + project files) and may need re-download access for a while.
3. One-time transfer: you want the recipient to download once, then the link should stop being useful.

If you’re not sure, default to least access for the shortest time that still lets the project move forward.

Step 2: Use an expiring link by default

Links get forwarded. Old emails get searched. People return to a download months later and expect it to still work-sometimes long after you’d prefer it didn’t. That’s why expiring links are one of the simplest, highest-impact privacy habits.

1. For client deliveries: set an expiration that comfortably covers review and sign-off.
2. For sensitive work: shorten the window and re-send a fresh link if needed.
3. For internal handoffs: keep it longer, but still finite, so folders don’t become permanent archives by accident.

If you want to understand the “why” behind this habit, What If the Internet Was Designed to Forget You? explores the idea of designing for temporary access rather than permanent copies.

Step 3: Add a password when the link could reasonably leak

A password is most useful when:

1. the client’s email threads get forwarded internally,
2. you’re sending pre-release or embargoed material,
3. the files contain personal data (contracts, IDs, private locations, unreleased product shots),
4. you’re sharing to a group and can’t be sure who will see the link.

Practical tip: don’t put the password in the same message as the link. Send the link by email and the password via another channel (or a separate message) to reduce accidental exposure.

If you’re new to LetsSend, you can send a file free and use simple link controls to keep deliveries tidy.

Step 4: Separate “finals” from “sources” to avoid oversharing

Creative projects often include more than the client actually needs. A clean security win is to split deliveries into two transfers:

1. Transfer A (client-friendly): finals in the formats they asked for (e.g., JPG/PNG, MP4, WAV/MP3, PDF).
2. Transfer B (restricted): source/project files (e.g., PSD/AI/INDD, PRPROJ, RAW, stems) only if they’re included in the agreement.

This reduces accidental IP leakage and avoids confusion (“Which file do I open?”). It also keeps approvals simpler: clients can focus on deliverables, while your team retains the working materials.

Step 5: Use clear naming so people don’t download the wrong thing

Security and workflow overlap here: when file names are unclear, recipients download multiple versions, forward the wrong export, or request re-sends.

A simple naming pattern works across disciplines:

1. Project - Deliverable - Version - Date
2. Example: EvergreenCafe_SocialCut_v03_2026-06-18.mp4

For multi-file deliveries, consider a top-level structure like 01_Finals, 02_Prevs, 03_Source. The goal is that a client can land in the folder and immediately know what to download.

Step 6: Put the important details in the message (so the link isn’t the only context)

Every transfer should answer three questions without a follow-up:

1. What is this? (Final exports for approval, updated cut, print-ready PDFs, etc.)
2. What should they do? (Download, review, share with print vendor, etc.)
3. By when? (Approval deadline, handoff date, expiry date)

Keeping this consistent is part of a smoother delivery process overall. If you want a lightweight system you can reuse, see A Simple Client Delivery Workflow for Creative Projects (That Clients Actually Use).

Step 7: Know when to use Free vs Pro settings

As your client list grows, the “secure by default” approach gets easier when you have consistent controls and delivery options.

1. If you’re just starting out, create a free account and get comfortable with link-based delivery.
2. If you’re delivering work every week, compare Free and Pro to choose a setup that matches your volume and the way you collaborate.

You can also see all features to understand what options are available for secure sharing and smoother client handoffs.

Common secure-sharing mistakes (and simple fixes)

Mistake: Reusing an old link for a new delivery

Fix: create a new transfer per milestone (v1 review, v2 review, final delivery). This keeps access scoped and makes it easier to track what changed.

Mistake: Sending “everything” because it’s faster

Fix: send only the files required for the next decision. Keep source files separate unless requested or contractually included.

Mistake: No expiry, no password, and a vague filename

Fix: use an expiring link, add a password when it matters, and name the file like a deliverable-not like an internal export.

A quick secure-delivery checklist you can reuse

1. Pick the right access model (review vs collaboration vs one-time transfer).
2. Set an expiration that matches the project stage.
3. Add a password if there’s any realistic chance the link gets forwarded.
4. Split finals and sources to avoid oversharing.
5. Name files clearly with version + date.
6. Write a 3-line handoff note (what / do / by when).

If you get stuck on a specific scenario (multiple recipients, changing deadlines, re-sends), read the FAQs or visit the Help Center for quick answers.