Send Files Between Devices — Peer-to-Peer, No Upload
Move a file from your phone to your laptop, or between two people, without it landing on anyone's server first. One device creates a room and shows a six-character code plus a QR; the other joins, and the file streams directly between the two browsers over an encrypted WebRTC data channel. Files are read in 64 KB chunks so size is limited by disk, not memory, and both ends compute a checksum so you can see the transfer arrived intact.
Your file bytes go device-to-device over an encrypted WebRTC channel — never uploaded, never stored, no copy on orangebot.ai. To connect the two devices, signaling metadata only (a room id and network addresses, including your IP) passes through the public PeerJS broker; if no direct path exists, its TURN relay may forward the still-encrypted stream.
How to send a file between two devices
- Open this page on the sending device. Choose "Send files". You get a six-character room code, a QR code, and an invite link. The code is live only while that tab stays open.
- Join from the other device. Scan the QR, open the invite link, or type the code into "Receive files" on the second device. The code uses no 0, 1, I, L, or O, so there is nothing ambiguous to mistype.
- Pick your files and send. Once both sides show "Peer connected", choose or drop files on the sending device. Each one streams across in 64 KB chunks with a live progress bar, transfer rate, and time remaining on both ends.
- Save and check the checksum. Each finished file gets a Save button on the receiving device. A green "checksum matches" means the bytes that arrived are identical to the bytes that were read — if it ever disagrees, send the file again.
Use Cases
Frequently Asked Questions
Is my file uploaded to a server?
No. The file bytes travel directly between the two browsers over a WebRTC data channel, encrypted end-to-end by DTLS. There is no copy on orangebot.ai — we run no server in this path, receive nothing, and have nothing to delete. What does leave your device is connection metadata: to find each other, the two browsers exchange a room id and network candidate addresses (which include your IP) through the free public PeerJS broker at 0.peerjs.com. That broker sees no file name and no file content. If the two devices cannot open a direct path — some corporate and mobile networks block it — PeerJS's public TURN relay may forward the encrypted stream instead, so the bytes are relayed but still unreadable in transit.
How big a file can I send?
There is no fixed limit. Files are read and sent in 64 KB chunks with backpressure, so the sender never holds the whole file in memory. The practical ceiling is on the receiving side, which assembles the finished file once before offering the download — a few hundred megabytes is comfortable on a desktop, less on an older phone.
Do both devices need to be on the same Wi-Fi?
No. Same network is the fastest case because the data never leaves your LAN, but the connection works across the internet too. Both tabs simply have to be open at the same time — this is a live link, not a drop box, so there is nothing to collect later.
What does "checksum matches" actually verify?
Both ends hash every 64 KB chunk with SHA-256 and then hash the sequence of those chunk digests. A match proves the received bytes are identical to the sent bytes. Note this is a chunk-tree digest rather than the plain SHA-256 of the whole file, so it will not equal what `shasum -a 256` prints — it is an integrity check between the two devices, not a published file hash.
The code did not work — what went wrong?
Usually the sending tab was closed or reloaded, which releases the code immediately. Codes are not reserved and do not expire on a timer; they exist only while the sender's tab is open. Ask for a fresh code, and check the sending device still shows "Waiting for the other device to join".
What happens if the connection drops mid-transfer?
The receiving side discards the partial file rather than handing you a truncated download that looks fine in your file manager, and both ends show the transfer as failed. Reconnect with a new code and send it again. Files already completed and saved are unaffected.
How this compares to the other ways to move a file
Peer-to-peer transfer is not always the right answer. It wins on privacy and on large files; it loses whenever the two devices cannot be online at the same moment.
| Method | Where the bytes sit | Best for |
|---|---|---|
| This tool (WebRTC P2P) | Nowhere — direct between browsers, or a TURN relay that cannot read them | Large or private files, both devices online now, no account |
| AirDrop / Quick Share | Nowhere — direct over local radio | Same-ecosystem devices within a few metres |
| Cloud drive link | The provider's servers, until you delete it | Recipients who will collect it later, or many recipients |
| Email attachment | Both mail providers, indefinitely | Small files that need a paper trail |
| USB stick | The stick | No network at all, or very large archives |
- Same-network transfers are dramatically faster because the data stays on your LAN and never touches your internet uplink — phone to laptop on the same Wi-Fi is usually the quickest option here.
- Restrictive corporate firewalls and some mobile carriers block direct peer connections. When that happens the transfer still works via relay, just slower, because every byte makes a round trip through a third-party server (still encrypted).
- Because this is a live link, it is a poor fit for "send it and they will grab it tomorrow". Use a cloud link for that; use this when both people are at their devices right now.