How Fast Is a Browser-to-Browser Transfer, Really?
"No size limit" is true and it is not the whole story. The honest answer involves your upload speed, your recipient's memory, and an unintuitive rule about sending to two people at once.
The ceiling is your upload, not our servers
When you upload to a cloud service, two separate transfers happen: you push the file to their storage, and later your recipient pulls it down. Each side runs at whatever speed it can manage, and the two are independent. You can close your laptop the moment the upload finishes.
A peer-to-peer transfer is one continuous stream from your device to theirs. There is no midpoint, so there is nothing to decouple the two ends. The transfer runs at the slower of your upload speed and their download speed — and in practice that is almost always your upload.
This catches people out because consumer broadband is deliberately asymmetric. A connection sold as "300 Mbps" is describing download. The upload on the same line is frequently a tenth of that, and on older cable and DSL connections it can be far worse. You have spent years experiencing your download speed and almost never noticing your upload, and a P2P transfer is the moment the number you never look at becomes the only one that matters.
If you want a realistic estimate before starting, run a speed test and read the upload figure. Divide the file size by that, and you have your answer to within a rough margin. Nothing we do can beat it, and no service can — a cloud upload is bound by exactly the same number, it just hides the second half of the journey from you.
Two recipients means half the speed each
This is the most counterintuitive property of peer-to-peer transfer, and the one worth internalising if you use it regularly.
When you send the same file to two people simultaneously, your browser opens two independent connections and sends the file twice. Not once to a server that fans it out — twice, in full, from your device. Both streams leave through the same upload pipe, so they divide it. Three recipients divide it three ways.
A cloud service behaves in the opposite way, and this is a genuine advantage it has: you upload once, and a hundred people can download simultaneously without slowing each other down, because the provider's outbound capacity is enormous and shared. That is what you are paying for when you pay for hosting.
So for a large file going to several people, a cloud link is the faster tool and we would rather say so. Peer-to-peer wins when the file is going to one place, or when you would rather not leave a copy on someone else's infrastructure. Sending a 4 GB video to five colleagues at once is not the case it is good at.
What "no file size limit" actually means
The claim is true in a specific and honest sense: there is no quota, because there is no storage to impose one on. Nobody is paying for a disk that holds your file, so nobody has a reason to cap it at 2 GB and sell you a tier that raises it.
What genuinely constrains a very large transfer is the receiving device. File data arrives in chunks and has to be assembled somewhere before it becomes a file on disk. Browsers handle this far better than they used to — streaming a download to storage as it arrives rather than accumulating the whole thing in memory — but the receiving device still needs enough free space, and a phone with 3 GB free is not going to accept a 20 GB file no matter how good the connection is.
The practical guidance: for anything above a few gigabytes, prefer a laptop or desktop on the receiving end. Sender-side memory is rarely the issue, because the file is read from disk in pieces as it is sent rather than loaded whole.
Relayed transfers are slower, and by more than you would guess
When no direct path exists between two networks — the symmetric NAT case — traffic has to travel through a relay server instead. That is strictly slower for two reasons, one obvious and one not.
The obvious one is the extra hop. Your data goes to the relay and then to your recipient, so it travels a longer path and picks up the latency of both legs.
The less obvious one is that relay operators cap throughput on purpose. A relay forwards bytes it has to pay for, so an uncapped relay is an unbounded bill. Self-hosted TURN servers expose a per-session bandwidth ceiling for exactly this reason, and managed providers price per gigabyte.
Here is a number from our own measurements that surprised us. We had sized our relay credential lifetimes against a documented 1 MB/s per-session ceiling, assuming transfers would run at roughly that rate. Observed throughput came in around three times worse than the ceiling implied. The cap was not the binding constraint; real-world conditions were. We had built a timeout around a theoretical maximum rather than a measured one, and the result was that a paid transfer could stall partway through when its allocation expired — a bug a user would find by paying for it.
The fix was to renew credentials mid-transfer rather than to extend their lifetime, but the lesson generalises well beyond our code: if you are setting a timeout based on a vendor's stated capacity, measure the real thing first. Our planning figure is a deliberately pessimistic ~2 MB/s, chosen because our users are largely on Indian mobile and home connections, and a limit tuned for a fast office link would strand exactly the people most likely to need a relay in the first place.
When it is faster than the cloud
One case beats a cloud service outright, and it is more common than people realise: both devices on the same network.
If your laptop and your phone are on the same Wi-Fi, the connection is often established locally and the data never leaves the building. It runs at LAN speed — frequently several times your internet upload — and your broadband is not involved at all. Moving a large video from a phone to a desktop in the same room is the case where peer-to-peer is dramatically faster than any upload and download round trip could be.
The other case is simple arithmetic. A cloud transfer is an upload followed by a download; a direct transfer is one leg. Even when both legs run at the same speed, you finish sooner, and your recipient starts receiving immediately rather than after your upload completes.
Rough expectations
Assuming a direct connection and a typical home upload of around 10 Mbps — roughly 1.25 MB/s in the units file sizes are quoted in:
- 100 MB — a little over a minute
- 1 GB — around fifteen minutes
- 10 GB — a couple of hours
Scale those by your actual upload speed. On fibre with 100 Mbps up, divide by ten. On a relayed connection, expect meaningfully worse than the direct figure for the reasons above. And on the same Wi-Fi network, expect all of these to be wrong in the good direction.
One last practical point: both tabs must stay open. There is no server holding a partial copy, so a transfer that is interrupted restarts rather than resuming. For a multi-hour transfer, that is worth knowing before you start it on a laptop that sleeps after fifteen minutes.