Planning guide
Before you send a very large file
A browser can stream a file without uploading it, but receiving is the harder half. The browser must put every arriving byte somewhere while respecting storage permissions, quotas, memory limits, and mobile tab lifecycles.
Best setup for a large transfer
- Use a current desktop Chromium-based browser on the receiver when possible.
- Choose a destination with substantially more free space than the file size.
- Keep both tabs visible and both devices awake.
- Use stable Wi-Fi or a personal hotspot; avoid roaming between networks.
- Keep the original until the saved copy opens and matches the expected size.
Sending does not require loading the whole file
A browser File object is a permission-scoped reference, not necessarily a copy held in JavaScript memory. ADrop reads slices of 64 KiB and sends them in order. It also limits the queued WebRTC data to avoid reading from disk much faster than the network can transmit. This design makes the sender's memory use largely independent of total file size.
The receiver has three possible storage paths
| Path | Behavior | Practical consequence |
|---|---|---|
| Direct destination | Chunks are written to a user-selected file or directory. | Best for very large files; requires a supporting browser and permission. |
| Origin-private storage | Chunks go to browser-managed disk storage, then become a download. | Avoids one giant memory buffer, but site quota and cleanup still matter. |
| Memory fallback | Chunks remain available to assemble a downloadable Blob. | Suitable only when the file fits comfortably in available memory. |
ADrop attempts these paths in that order according to browser capability. A phone with 100 GB free does not guarantee that a tab may allocate or privately store a 20 GB file. Operating systems and browsers impose separate limits, sometimes dynamically.
Free space needs a safety margin
The destination needs room for the completed file, and an indirect storage path can temporarily require browser-managed space as well. Other tabs, applications, system updates, and automatic cache eviction compete for the same device resources. Avoid starting when free space is only barely larger than the transfer.
Screen lock is a transfer condition
Desktop browsers generally keep a foreground transfer active, but phones aggressively suspend background tabs to save battery. ADrop requests a screen wake lock while a transfer is connecting or active where the browser supports it. The operating system can still deny or release that lock. Leave the transfer page visible, connect power for a long run, and do not assume audio playback or another app will keep the browser alive.
Estimate duration using the local link
An internet speed test measures a path to a remote test server and may not describe device-to-device Wi-Fi performance. ADrop's file path is local when the browsers can connect directly. Distance, band, access-point load, device radios, and interference matter more. For a rough optimistic estimate, divide file size in bits by observed bits per second, then allow extra time for protocol overhead and rate variation.
For example, 10 GB is roughly 80 gigabits. At a sustained 100 megabits per second the mathematical minimum is about 800 seconds, or 13 minutes 20 seconds; real completion will take longer. This is an illustration, not an ADrop speed guarantee.
Understand what resume can and cannot recover
A brief WebRTC interruption can resume while the sending page still owns the original file reference and the receiving page still owns its partial output. ADrop records the receiver's current file and offset, reconnects, and asks the sender to continue there. The partial state is session-scoped.
Closing or refreshing either page, rebooting, browser eviction, revoking a file permission, or waiting beyond the recovery window can require a complete restart. This is not cloud storage: there is no server copy from which a new session can continue tomorrow.
Verify the result
Wait for Completed, confirm the saved byte size, and open the received file with its normal application. For critical data, compare a cryptographic checksum using a trusted operating-system tool. ADrop currently reports transport completion but does not present an end-to-end checksum in the interface, so it should not be treated as a backup verification system.
For irreplaceable files, preserve the source and use a second verified backup. A convenient transfer is not the same thing as durable storage.