Someone tries to send you a 150 MB video clip. Gmail refuses. They text you "it's too big, how do I send it?" - and now two people are solving a logistics problem instead of working. Every solution to this either puts the burden on the sender (compress it, split it, go sign up somewhere) or on you (explain WeTransfer over the phone). The only version where nobody suffers is: you send a link, they drop the file on it.
Why the burden keeps landing on the sender
Email's ~25 MB cap (corporate systems often set 10) leaves the sender four bad options: compress and lose quality, split across several messages, upload to their own cloud and fight the permissions dialog, or give up and ask you. Notice all four make the least-equipped person - the one who just wanted to hand you a file - do the technical work. That asymmetry, not the megabytes, is the actual problem, and it is also why "just use Drive" fails: it assumes the sender has the account, the space and the patience.
An upload link flips the asymmetry. The person who cares about receiving the files - you - does the one-time setup; the sender gets a page where dragging a file is the entire job. No account on their side, nothing to install, works from a phone.
Resumable uploads are the part that actually matters
Big files fail on bad connections; that is a law of nature. What differs between tools is what happens next. On getfiles.app anything over 5 MB uploads in 2 MB chunks, and if the connection drops - hotel Wi-Fi, train, tethered phone - the upload resumes from the last received chunk instead of starting over.
Resume is the difference between "the progress bar hiccupped and continued" and "the client gave up after the third attempt at 80%". If your senders are ever on mobile connections, this one property outweighs every other feature.
The honest ceiling: 200 MB per file
An upload link is not infinite. The per-file cap here is 200 MB - comfortable for video clips, design exports, CAD drawings, photo batches, audio masters and scanned archives, and wrong for multi-gigabyte raw footage. One setup note: a new page defaults to 100 MB per file - if you are expecting big files, raise the limit to 200 MB when creating the page, or the sender hits a wall you built.
If your work is routinely measured in gigabytes per file - raw video production, disk images - you need a specialized transfer service or physical media, not an upload link. Know which side of that line your files are on before you send anyone a link, not after their upload dies at 100%.
Within the ceiling, files arrive uncompressed: what they upload is byte-for-byte what you download.
More than one sender? Same link.
The email-limit problem usually travels with a second one: several people sending files at once, each in their own thread, with no overview of who sent what. One upload page absorbs that too - every sender uses the same link, the dashboard shows per-person uploads in real time, and everything lands in a single ZIP. You stop being the person who reconciles attachments across threads.
Put a one-line naming request in the page description ("start the filename with your surname") and the ZIP arrives pre-sorted. Thirty seconds of setup, an hour of sorting saved.
Method comparison, without the marketing
| Method | Per-file limit | Sender needs account | Resumes after drop | You can request |
|---|---|---|---|---|
| ~25 MB | No | No | Yes | |
| WeTransfer free | 2 GB per transfer | No | No | No - sender initiates |
| Google Drive share | Your storage | Yes | Yes | Clumsy |
| Dropbox File Request | Your quota (2 GB free) | No | No | Yes |
| getfiles.app | 200 MB | No | Yes | Yes |
WeTransfer wins on raw size; it loses on direction - you cannot request, only receive what someone remembers to send - and on resume. Pick by which failure mode costs you more.
getfiles.app - create the upload page, send the link, get the ZIP. Free, no accounts for senders.