How to Share Large Files with Clients Professionally and Securely

Why email attachments stop working for real deliverables

Most client work eventually outgrows the email attachment. A brand video, a print-ready PDF with embedded images, a folder of product photos or a website backup can easily run to hundreds of megabytes or several gigabytes. Email was never designed for that.

The limits are lower than many people expect. Google's documentation says personal Gmail accounts can send up to 25 MB in attachments, and when you go over, Gmail replaces the attachment with a Google Drive link (Gmail Help). Microsoft's documentation for Outlook lists a default limit of 20 MB for internet email accounts, and a default of 10 MB for Exchange mailboxes unless an administrator changes it (Microsoft Learn). The recipient's mail server can apply its own, stricter limit.

Size is only part of the problem. Attachments get copied into every inbox they pass through, forwarded without your knowledge, and buried in long threads. Two weeks later, nobody is sure which attachment was the final one. A professional delivery process fixes both issues: it moves big files reliably and keeps you in control of who has them.

What "professional and secure" actually means

Before choosing a tool, it helps to agree on the outcome. A good file delivery has six qualities:

1. It arrives. The client can download it without errors, timeouts or a confusing sign-up wall.
2. It is the right file. The version is obvious, and there is no doubt about which file is final.
3. Only the right people can open it. Access is limited to the people who need it.
4. Access doesn't last forever. Links expire or can be revoked once the job is done.
5. You can tell what happened. You know whether the client downloaded it, and when.
6. It is easy to find later. Six months on, you and the client can both locate the delivered version.

Keep this list in mind as you work through the steps below. Each step covers one or more of these qualities.

Step 1: Prepare the files before you share them

A tidy package saves more back-and-forth than any tool. Before uploading, run through this short routine:

• Export the formats the client actually needs. A print shop wants a press-ready PDF, a web developer wants optimized images, a video editor wants the original codec. Ask if you're unsure. Sending only a 4 GB master when the client needs a 40 MB web version creates work for them.
• Name files so they explain themselves. Include the client or project, the deliverable, a version and a date, for example acme-annual-report_print_v03_2026-10-11.pdf. Avoid spaces and special characters, which some systems handle badly.
• Remove what doesn't belong. Delete working files, hidden system files, old versions and anything with internal notes or other clients' material.
• Group many small files into one archive. A zip file keeps folder structure intact and turns 300 downloads into one. Don't expect it to shrink video, JPEG or PNG files much, because those formats are already compressed.
• Add a short README for complex packages. One plain-text file that lists what's included, which file to use for what, and any font or license notes.

If the package is very large, consider splitting it into logical parts, such as "web assets" and "print masters", so the client can download what they need first.

Step 2: Choose the right delivery method

There is no single correct tool. The right choice depends on file size, sensitivity and how often you deliver to the same client.

Method	Works well for	Watch out for
Email attachment	Small, non-sensitive files under the provider's limit	Size limits, forwarding, version confusion
File transfer service	One-off large sends to someone outside your usual tools	Links that anyone can open, files that vanish after a few days, no history
Cloud drive link	Ongoing collaboration with clients who already use the same drive	Sharing settings defaulting to "anyone with the link", clutter in shared folders
Client portal	Repeated deliveries to the same client, with versions, approvals and history	Clients need a simple way to sign in
Physical drive or managed transfer	Very large archives, such as raw footage	Shipping time, encryption, chain of custody

For a one-time send of a non-confidential file, a transfer service is fine. For recurring client work, a single place per client where every delivered file lives, with versions and history, is much easier for both sides. That is the approach we take in Clientwharf: each client gets a private portal where you upload files with version numbers (v1, v2 and so on), and downloads go through signed, short-lived links rather than public URLs. You can read more about how that works on the file delivery page.

Step 3: Control who can open the files

Access control is where most "secure" sharing quietly fails. Many tools offer an option such as "anyone with the link". Google's own help page explains that with this setting, anyone who has the link can use the file without signing in (Google Drive Help). Links get pasted into chat tools, forwarded to vendors and saved in browser histories, so an open link can reach people you never intended.

Apply the security principle of least privilege, which NIST describes as restricting access to the minimum necessary to accomplish the task (NIST CSRC Glossary). In practice:

• Share with named people, not open links, for anything confidential, unreleased or under NDA.
• Give view or download access, not edit access, unless the client really needs to change the files.
• Set an expiry where your tool supports it. Google notes that access expiry is available for eligible work and school accounts, so check what your plan offers.
• Avoid sending the same link to a whole distribution list. Add the specific contacts who need the files.
• Remove access when the project closes, especially for former employees or contractors on the client side.

If your client needs a file for a third party, such as a printer, ask them to tell you who it is. Then share with that person directly rather than having the link forwarded.

Step 4: Send a clear delivery message

The message that goes with the files matters as much as the files. It should answer, in a few lines, what is being delivered, where it is, what to do with it and what happens next. Here is a template you can adapt:

Subject: Final files: Acme annual report (print and web), v3

Hi Dana,

The final files for the annual report are ready in your portal under "Annual report / Final".

• Print: acme-annual-report_print_v03.pdf (press-ready, with bleed)
• Web: acme-annual-report_web_v03.pdf (smaller file for your site)
• Images: a zip of the 24 photos used, in high resolution

The download link is private to you and Sam. Please download the files by October 25, and let me know if anything doesn't open.

Next step: once you confirm everything looks right, I'll send the handoff notes and close the project.

Notice what the template does. It names the version, says where the files live, explains which file is for what, mentions who has access and sets a clear next step.

Step 5: Confirm receipt and integrity

"Sent" is not the same as "received". Close the loop in two ways.

Confirm the download. If your tool shows download activity, check it. If not, ask the client to reply once they have the files. For important deliveries, put a short date in your message ("please download by October 25") so files don't sit unopened until a link expires.

Verify integrity for large or critical files. A checksum is a short fingerprint of a file's contents. If the checksum of the downloaded copy matches the one you published, the file is identical. Microsoft's documentation for the PowerShell Get-FileHash command explains that changing even a single character in a file changes its hash value, and that the command uses SHA-256 by default (Microsoft Learn). On macOS and Linux, shasum -a 256 filename does the same.

You don't need checksums for every logo file. They are worth it for multi-gigabyte archives, software builds, database exports and anything that will be printed or broadcast at cost.

Step 6: Archive the delivery and close access

When the client confirms receipt:

• Record what was delivered. File names, version numbers and the date. A delivery log or a dated project update is enough.
• Keep your own copy in your project archive, following your retention policy and contract.
• Revoke access you no longer need. Expire open links, remove external collaborators from shared folders and tidy up transfer services.
• Tell the client where the files will remain available and for how long, so they can save their own copies.

If a client comes back a year later asking for "the final logo", this step is what lets you answer in two minutes instead of two hours. Our project handoff checklist covers the rest of the closing process.

A pre-send checklist

Use this list before every significant delivery:

• Files exported in the formats the client needs
• File names include project, deliverable, version and date
• Working files, internal notes and unrelated material removed
• Large sets zipped or split into logical parts
• README included for complex packages
• Delivery method suits the size and sensitivity
• Access limited to named people, view or download only
• Expiry set, or a reminder to revoke access later
• Delivery message names the version, location, purpose and next step
• Checksum published for large or critical files
• Download confirmed and delivery recorded

Common mistakes to avoid

Sending a new link for every revision. The client ends up with five links in five emails. Keep one location per deliverable and add new versions there.

Putting passwords in the same email as the link. If a file is password-protected, share the password through a different channel, such as a password manager's sharing feature or a phone call.

Letting links expire before the client downloads. Short expiry is good for security, but combine it with a clear "please download by" date and a check-in.

Mixing clients in one shared folder. One misplaced file can expose another client's work. Keep each client separate.

Treating delivery as the end. Delivery is usually followed by review and sign-off. Agree on how the client will confirm the files are correct, and keep that confirmation with the files. If your assets are already a little scattered, our guide on how to organize client assets is a good next read.

Large files are a practical problem, but how you deliver them shapes how clients see your work. Prepare the package carefully, limit who can open it, explain it clearly and confirm it arrived. Do that every time and file delivery stops being a source of friction.