Transfer flow

The file path from room code to download

Follow the actual browser workflow: a live room pairs two tabs, signaling negotiates the route, an encrypted WebRTC data channel carries file chunks, and the receiver saves the result locally.

Send files

Room code

pairs two live browser tabs

Signaling

coordinates connection setup only

Data channel

carries encrypted file chunks

Open a live transfer room

The sender opens the transfer tool and gets a short room code plus a QR code. The receiver joins that live room from another browser before the session is abandoned.

The room code is a temporary pairing handle, not a file link.
QR scan and manual code entry lead to the same room.
Both tabs need to stay open while the route is being built.

Negotiate the route without sending file bytes

The signaling service passes the WebRTC coordination messages that browsers need to discover each other. Those messages describe how to connect; they are not the transferred files.

The server can see connection attempts and temporary peer identifiers.
It does not receive file chunks or act as a file mailbox.
If the network blocks the peer route, the room cannot become a transfer.

Send chunks through the WebRTC data channel

When the channel opens, files are streamed in chunks between the two browsers. The page tracks progress, speed, queue state, cancellation, and retry options locally.

Transfer speed follows the peer route the browsers can establish.
Multiple files are scheduled so small files do not wait behind one large file forever.
Progress belongs to the current live session, not to an account on the server.

Confirm the download before closing anything

The receiver saves the completed file through the browser. Keep the original file and both tabs alive until the recipient confirms the download is complete.

Closing either tab ends the browser-to-browser route.
Mobile browsers may pause transfers when backgrounded or locked.
A fresh room is cleaner than trying to revive a fully disconnected session.