The video is on your phone and the editor is on your laptop. Or a folder of raw footage has to reach a colleague before the end of the day, just as your cloud drive runs out of space. The hard part of a large transfer is rarely finding a Send button. It is reaching 80 percent without a restart, avoiding an accidental mobile-data bill, and knowing that the file at the other end is complete.
A cable, an operating system’s nearby-sharing feature, cloud storage, and browser P2P all have a comfortable range. The right choice depends on whether both devices are online now, whether the file needs to remain available later, and whether the two devices belong to the same ecosystem.
Match the method to the situation
| Situation | Good first choice | What to check |
|---|---|---|
| Devices are beside each other; tens of gigabytes | Fast data cable or local-network transfer | The cable supports data and the expected speed |
| Different platforms; no installation wanted | Browser P2P | Both browsers stay online and preferably on Wi-Fi |
| The recipient will download later | Cloud storage or an object-storage link | Upload time, quota, expiry, and access control |
| Frequent transfers inside one device ecosystem | Built-in nearby sharing | Account and cross-brand compatibility |
If the file only needs to travel from A to B and both people are present, uploading it to a distant data center before downloading it again can be needless work. On the same home or office network, a direct local route can use the router’s internal capacity without consuming internet upload bandwidth. P2P is not a replacement for storage, though: if the recipient will not be online until tomorrow, a temporary hosted copy is exactly what is needed.
Estimate time using the slow direction
A “500 Mbps” internet plan may offer far less upload capacity. A remote transfer is constrained by the sender’s upload, the receiver’s download, and the path between them. Ten gigabytes at a sustained 100 Mbps takes roughly fourteen minutes before overhead. At 10 Mbps, the same job takes more than two hours.
Be careful with the speed shown in an interface. A one-second sample jumps around, so a moving average over several seconds is more useful. “Sent” can also mean placed in the sender’s local browser buffer, not written by the receiver. A trustworthy progress bar advances on peer acknowledgements and leaves a visible final stage for integrity verification.
Prevent an accidental cellular transfer
WebRTC can recover when a phone leaves Wi-Fi and joins 5G. That is helpful during a chat and potentially expensive during a 20 GB upload. Before starting, make sure the phone is still on Wi-Fi, check whether the operating system is allowed to use cellular data when Wi-Fi is weak, and watch for a route change in the transfer status.
A TURN relay changes the route too. The content remains protected by the WebRTC transport, but every byte crosses the relay’s public connection. When two devices are in the same building yet fall back to TURN, look for a VPN, guest-network client isolation, a strict firewall, or a browser policy before accepting the detour.
Large files need verifiable resume support
Restarting a 300 MB file is annoying. Restarting a 40 GB folder means the transfer protocol was not designed for the job. A resumable task records a transfer ID, expected size and digest, plus the chunk ranges confirmed by the receiver. On reconnect, the receiver reports gaps and the sender fills those ranges.
After the sender page refreshes, the browser usually cannot reopen the previously selected local file. Asking the person to select it again is a legitimate security boundary. The application should compare size and a SHA-256 digest before resuming. A filename alone is not an identity; two unrelated files can share one.
Four small preparations
- Plug in the laptop and prevent sleep from freezing the browser tab.
- Check free space on the receiving device, including room for temporary chunks.
- Bundle thousands of small files into one archive, even if compression is disabled.
- For sensitive material, verify the receiving device’s name and identity instead of trusting a generic nearby-device entry.
Already-compressed video and photos may not shrink inside another archive. Bundling still reduces filesystem and per-file handshake overhead. It also leaves one transfer to verify and one item to resume instead of a long list of partially completed files.
Send the file from a browser
Open the uCopy connection page on both devices. Use local discovery when they share a network exit, or a temporary connection code when they do not. The receiver approves first contact, then both sides enter the workspace and choose the file feature.
Check whether the route is direct or relayed. Let the task continue through receiving, missing-range repair, and digest verification; 100 percent of chunks is not yet the same as a verified file. A cancellation should stop both ends quickly, while a brief network interruption should retain acknowledged progress for recovery.
If performance is far from the estimate, note the route, file-size range, device platforms, and sustained speed. That information is useful in a support report; the filename and contents are not.
The simple recommendation
For two devices on the same desk and a truly huge folder, a good cable remains the baseline. For cross-platform transfer without an install, browser P2P is the lightest option. When the recipient cannot be online at the same time, use storage. Whichever method you choose, inspect the path, time estimate, resume behavior, and final verification before committing a large job.
Avoiding an unnecessary upload saves more than time. It also avoids leaving another durable copy on somebody else’s storage. Use hosting when you need hosting; use a direct path when you only need delivery.