How Pasa File moves a file between two devices
Most "send a file" services work by uploading your file to a server and giving the other person a link to download it. Pasa File does not do that. The two browsers open a direct connection to each other and the file crosses your own network. This page explains exactly what happens, including the parts that are genuinely a limitation.
The short version
Two browsers cannot find each other on their own, so they need an introduction. Pasa File's server is that introduction service and nothing more. Once the two devices have swapped enough information to reach each other directly, they build a peer-to-peer connection and the server has no further part in the transfer. Your file goes device to device across the local network.
Step by step
-
1. Open a room on the sending device
Go to the home page and choose "Create room". You get a six-character code, plus a QR code once you are inside the room. Add a password first if you are on a network you share with people you do not know.
-
2. Join that room from the other device
On the second device, open the same site and enter the six-character code, or point its camera at the QR code shown in the room. Both devices are now in the same room and can see each other listed.
-
3. Pick the files and send them
Drag files onto the drop zone or use the file picker, choose which device in the room should receive them, and send. A progress bar tracks each transfer on both ends.
-
4. Save the file on the receiving device
The receiving browser reassembles the file, verifies a checksum, and offers it as a normal download. Close the tab when you are done — nothing is retained.
What the server does and does not see
The technical name for the introduction step is signaling. The two browsers exchange a session description (what codecs and transport they support) and a set of candidate network addresses, so that each one knows how to reach the other. Pasa File relays those small text messages over a WebSocket. That is the entire server-side involvement in a transfer.
| Goes through the server | Never touches the server |
|---|---|
| The room code and, if you set one, the room password | The contents of every file you send |
| Connection details: session descriptions and network candidates | File names, sizes, and types |
| A temporary per-device id and the "joined"/"left" notices for the room | Any record of what was transferred, or that a transfer happened at all |
| — | Any text shared in the room's text box |
Those network candidates are worth naming plainly: they include your devices' local network addresses, and they are seen by the other device in the room and by the server relaying them. That is inherent to how any WebRTC connection is established.
What happens on the wire
Once the peer connection is up, the sending browser reads the file in 64 KB chunks and writes each one to the data channel as raw binary, preceded by a tiny message saying which transfer and which chunk index it belongs to. The receiving browser puts the chunks back in order, and both sides compute a rolling checksum as they go. When the last chunk arrives the checksums are compared: if they match, the file is offered as a download; if they do not, the transfer is reported as failed rather than handing you a silently corrupted file.
The data channel is encrypted with DTLS. That is not a feature that was added — WebRTC has no unencrypted mode, so every transfer is encrypted in transit whether or not you set a room password.
The room's text box uses the same data channel, sent as a single message to everyone connected rather than chunked like a file. It is one-shot: sending it pushes the current text to every device in the room at that moment, not a live document that updates as you type. It is not saved anywhere either, so a device that joins afterward will not see text shared before it connected.
The honest limitations
-
Both devices need internet access
The file crosses your local network, but the introduction happens through this site. Two devices on an air-gapped network cannot use the hosted version of Pasa File at all.
-
Same network, in practice
Connections are negotiated using public STUN servers, and no relay (TURN) server is configured. Two devices on different networks, or behind a strict NAT, will frequently fail to connect. Same Wi-Fi is the supported case.
-
Large files are limited by memory
The receiving browser holds the whole file in memory before writing it out. Multi-gigabyte files are fine on a desktop with free RAM; on a phone they can exhaust the tab and fail.
-
No resume
If the connection drops part-way, that file starts over. There is no chunk-level resume.
-
The room code is the access control
Anyone on the internet who knows a live six-character code can join that room unless you set a password. Codes are short by design so they are easy to read out loud — set a password on a shared network.