Large file transfer

There is no standard threshold. Mailbox caps of 20 or 25 MB are common product limits, not a protocol rule. HTTP itself, in RFC 9110, does not set a maximum body size. Proxies, browsers, and application servers do.

What changes at that size is the failure mode. A 5 MB PDF either arrives or it does not. A 20 GB folder upload can run for hours, cross a network blip, and leave a partial object. The sender needs a resume, a multipart upload, or a job that retries. The recipient needs a link that outlives the download. Gartner's MFT definition treats large size and high volume as the reason managed jobs exist beside raw FTP.

An editor exports a 48 GB camera master. Email refuses it. A consumer chat app caps attachments at 2 GB. The editor uploads to object storage in 100 MB parts. Two parts fail on a Wi-Fi roam and are retried. The complete call runs only after all 480 parts are in. A link expiring in 2 hours is the wrong control: at 100 Mbps the download wants about 48 × 8 / 100 = 3.8 hours before overhead, and a residential up link on the way in was already slower. The working setup is a resumable upload, a checksum the recipient can recompute, and a link window longer than the expected download.

"Large" is also a pricing word. Plans advertise 2 GB, 10 GB, or unlimited. Those numbers are product caps. They are not definitions. A 1 GB file and a 100 GB file are the same mechanism with a longer window and a higher chance of a mid-transfer drop. Separate pages per size do not add a new operation.

Folder and batch transfers pile on packaging. Zipping 4,000 small files can take longer than sending them, and a single archive hides which file failed. The size problem is still the same: keep a completion check, and do not treat "link sent" as "file received."