How to send large files to clients professionally

The professional way to send large files to a client is to choose the delivery method that fits that client's schedule, name and version the files so nobody can confuse them, include a checksum so either side can prove the files arrived intact, and keep your own backup until the job is truly closed. The method matters less than the system around it. A live peer-to-peer transfer, a hosted download link and a branded client portal can all look professional, or all look sloppy, depending on how the files are prepared and presented.

Step 1: Pick the delivery method for this client

There are three broad options, and each is the best choice in some situations.

Many freelancers use more than one: a portal for proofs and feedback, a hosted link for the final archive, and a live transfer when a client says "can you just send it to me now?" during a meeting. If you are weighing hosted services, our WeTransfer comparison explains when a hosted link is the stronger choice, and the large video files guide covers free options for footage.

Step 2: Name and version everything

Clients forward files, rename them, and come back months later asking for "the one from before". A consistent naming scheme answers most of those questions without an email thread.

A pattern that works for most creative work:

ClientOrProject_Deliverable_Version_Date.ext

• Hartwell_Wedding_Highlights_v03_2026-10-14.mp4
• Hartwell_Wedding_Highlights_FINAL_2026-10-20.mp4
• NorthBay_Logo_Primary_RGB_v02.svg

Rules that save trouble:

• Use ISO dates (year-month-day). They sort correctly and are unambiguous across countries.
• Pad version numbers (v01, v02 ... v10) so v10 does not sort before v2.
• Reserve "FINAL" for the approved deliverable, and never edit a file after calling it final. If changes are needed, issue a new dated final or a new version number.
• Avoid spaces, accents and symbols such as / \ : * ? " < > |. Some are illegal on Windows, and others cause trouble when files pass between Mac, Windows and cloud services. Our Mac-to-Windows guide covers cross-platform pitfalls.
• Include a short README or delivery note listing what is in the package, the formats, colour space or codec, and who to contact.

Step 3: Package the delivery

Group files the way the client will use them, for example 01_Web, 02_Print, 03_Social, rather than the way your project folder happens to be organised. For hundreds of photos, one ZIP per folder is easier to download than individual files. For a handful of multi-gigabyte video files, send them separately: a failed download then costs one file, not the whole set. Our guide to zipping files explains why compressing JPEGs and video saves almost no space, so archive for convenience, not size.

Check that you are sending full-quality files. Some messaging apps and default share options compress photos and video. The guide to sending photos and videos without compression lists which routes preserve the original.

Step 4: Create checksums

A checksum is a short fingerprint calculated from a file's exact contents. If even one byte changes, through a truncated download, a faulty drive or a bad copy, the SHA-256 value changes completely. Sending checksums with a delivery gives both sides a way to confirm that what arrived is exactly what left.

On Windows

In Command Prompt:

certutil -hashfile "Hartwell_Highlights_FINAL.mp4" SHA256

Always type SHA256 explicitly; Microsoft's documentation lists several algorithms that certutil supports. In PowerShell, Get-FileHash uses SHA-256 by default, according to Microsoft:

Get-FileHash .\Hartwell_Highlights_FINAL.mp4

To fingerprint every file in a folder at once: Get-FileHash .\* | Format-List.

On macOS (and Linux)

In Terminal:

shasum -a 256 Hartwell_Highlights_FINAL.mp4

To create a checksum list for the whole delivery folder: shasum -a 256 * > SHA256SUMS.txt. Anyone on a Mac or Linux machine can then check every file with shasum -a 256 -c SHA256SUMS.txt, which reports OK or FAILED for each one. On Linux, sha256sum does the same job.

Put the checksum file in the delivery and keep a copy with your project records. When a client says "the file won't open", ask them to run the same command. Matching values mean the file is intact and the issue is their software; different values mean the copy was damaged and you should resend.

Step 5: Separate proofs from finals

Proofs exist so the client can review and approve. Finals exist so the client can use the work. Mixing them causes disputes about payment, quality and usage.

Write down in your contract how many revision rounds are included, when finals are released, and how long download links stay live. Then the delivery itself is just following an agreement, not negotiating one.

Step 6: Send, then confirm receipt

A delivery message should be short and complete. Something like:

Hi Sam, the final edit is ready. You'll find the 4K master, a 1080p web version and the subtitles file (5.2 GB in total). The link works until 3 November. A SHA256SUMS.txt file is included if your team wants to verify the files. Could you reply once it's downloaded and plays correctly? I'll keep a copy on my side until 20 January 2027.

Asking for confirmation matters because many hosted links expire and many clients download only one file out of several. If you used a live transfer, confirm on the spot that the files open. Do not delete anything at your end until the client has confirmed in writing.

Step 7: Keep backups until the job is really closed

A transfer link is not a backup. Links expire, accounts close, and a peer-to-peer transfer leaves no server copy by design. Keep your own copies according to a simple rule of thumb many professionals use, often called 3-2-1: three copies of important data, on two different types of storage, with one kept off-site or in the cloud. For a freelancer that might be the working drive, an external archive drive, and a cloud backup.

Decide how long you will hold finals after delivery, write it into your terms, and tell the client in the delivery message. If the files contain personal data, such as identifiable people in photos or customer records, keeping them indefinitely may conflict with your data protection obligations, so retention should be a deliberate choice rather than an accident.

Etiquette checklist

• Ask the client how they prefer to receive files before the deadline, not on delivery day. Some corporate clients cannot open certain transfer services on their network.
• State the total size and file count up front so they can make space and plan the download.
• Avoid sending unexpected executable files, macro-enabled documents or disk images. They trigger security warnings and look suspicious; see our guide to receiving files safely for what clients are rightly wary of.
• Tell them in a separate message, or on the phone, when a link is on its way, so a genuine delivery is not mistaken for phishing.
• Send one complete package, not a trickle of corrections. If you must resend, increase the version number.
• Follow up once, politely, if you have not heard back within a few days.

Sources

• Microsoft Learn: Get-FileHash
• Microsoft Learn: certutil
• Frame.io Support: How do I share with others?
• Adobe: Frame.io