How to Transfer Large Files Securely Without Email Attachments

Why File Size Changes the Problem

Small files succeed on the first try. Large files encounter partial success as a normal outcome — a network blip can corrupt a 500 MB download that would have been invisible on a 500 KB download. The engineering around large transfer therefore focuses on resumability (continue after interruption), integrity (prove the bytes are identical), and parallelism (use multiple connections or chunks to speed up and improve reliability).

The second complication is time. A 10 GB file over a 100 Mbps connection takes roughly 14 minutes under ideal conditions. In practice, residential and small-business connections rarely sustain their advertised rate. Plan for 25-50% of theoretical speed and budget time accordingly.

Email Attachment Limits

Published limits as of late 2026:

• Gmail: 25 MB per message (attachments larger than this are converted to a Google Drive link).
• Outlook.com and Microsoft 365 default: 25 MB; Exchange admins can lower it.
• Yahoo Mail: 25 MB.
• Many corporate Exchange deployments: 10 to 15 MB by default.

The sender's limit controls what can leave; the recipient's limit controls what can arrive. The lower of the two applies. A 20 MB attachment that leaves Gmail cleanly may be rejected by a stricter corporate mail server at the recipient.

Cloud Storage Link Transfer

For files up to roughly 10 GB, a cloud storage link is almost always the simplest option. Google Drive, OneDrive, and Dropbox all support files well beyond 10 GB — individual file limits are in the hundreds of GB — with resumable upload in their desktop clients and web uploaders.

The sender uploads the file to their cloud storage, generates a shared link scoped to the recipient (named recipient, authenticated, with expiry), and sends the link. The recipient downloads through their browser. The platform handles transport encryption, resumability of upload and download, and access logging.

This method covers the vast majority of large-file transfer in small business. For sensitive material, apply the same controls as any confidential share: named recipient, authentication, expiry, download audit. See the confidential sharing guide.

SFTP and Managed File Transfer

SFTP (SSH File Transfer Protocol) is the right primitive for scheduled machine-to-machine transfer. Both ends authenticate — typically with SSH keys — and the connection is encrypted. SFTP is reliable, scriptable, and widely supported across operating systems and cloud providers.

Managed file transfer (MFT) wraps SFTP (and other protocols) in orchestration: scheduled transfers, retry logic, chain-of-custody logging, encryption key management, and compliance reporting. For small businesses, MFT is overkill unless you have a recurring B2B flow that justifies the setup. For most ad-hoc transfer, cloud links win on simplicity.

Resumable and Multipart Uploads

A resumable upload breaks the file into chunks, uploads each separately, and resumes from the last successful chunk after an interruption. The desktop clients of Google Drive, OneDrive, and Dropbox implement this transparently. Browser uploaders also support it on modern platforms.

A multipart upload uploads chunks in parallel, which can meaningfully improve throughput on connections where single-stream performance is limited. S3-compatible APIs and most managed transfer tools support multipart as a standard pattern. For user-facing uploads through consumer products, the platform handles this automatically.

Transfer Integrity and Checksums

A cryptographic checksum is a fingerprint of the file. If the sender and recipient compute the same checksum, the file is identical bit-for-bit. If they differ, the file was corrupted or truncated in transit.

SHA-256 is the standard. Older algorithms (MD5, SHA-1) still appear in some tools but are not recommended for integrity verification of important files because of known collision weaknesses. Modern tools default to SHA-256 or stronger.

Verifying a SHA-256 Checksum

The output is a 64-character hexadecimal string. Send the hash in the cover message or publish it on a trusted channel; the recipient compares after download. Any difference means the file is not what the sender intended — re-transfer or investigate.

Recipient Authentication for Large Files

The same authentication principles apply as for smaller files, with one practical note: for very large downloads, requiring the recipient to log in or verify at each attempt can be frustrating if their network drops the connection partway through. Session-based authentication where re-starting the download does not re-trigger full re-verification is easier on both parties.

For sensitive content, link password plus email verification is a reasonable minimum. For B2B machine-to-machine transfer, SSH key authentication eliminates the password handling problem entirely.

Retention and Secure Deletion

Set a retention policy at the time of upload. For one-off deliveries, 7 to 14 days gives the recipient a window to retry if the first download failed and prevents the file from lingering. For scheduled transfers, retention should match the business process (e.g., 30 days for monthly batches, 90 days for quarterly reports).

Secure deletion from the sharing platform usually means moving to trash and then purging; most platforms retain deleted items for 30 days before permanent removal. For regulated content, document the retention and purge events in the compliance log.

For a broader look at how large-file transfer fits into an overall file-sharing security strategy, see the secure file sharing for business guide.

Decision Table by File Size and Recipient

Frequently Asked Questions