How Peer-to-Peer File Transfer Works, Step by Step

By SRIFT maintainers · Published 8 October 2026

Reviewed by SRIFT maintainers · last reviewed 8 October 2026 against the SRIFT 4.3.2 source.

Short answer

A peer-to-peer (P2P) file transfer streams a file from the sender's device to the receiver's over a connection between the two, instead of uploading it to storage first. It happens in four stages: the devices exchange connection details through a signaling server, discover a working network path (ICE, using STUN and TURN), open an encrypted channel, and send the file in acknowledged chunks with flow control.

When no direct path exists, a well-designed tool falls back to a relay that forwards encrypted chunks. Either way, nothing is stored, and both sides must be online at the same time.

Needs a server?: Yes, for signaling; and a relay when no direct path works
Stores the file?: No: bytes stream from sender to receiver
Both online?: Yes, for the whole transfer
Browser technology: WebRTC data channels (SCTP over DTLS)

Key takeaways

“Peer-to-peer” still uses servers: one introduces the devices (signaling) and, when no direct path opens, one relays the traffic. What goes away is the stored copy.
A transfer has four stages: signaling, finding a path with ICE (STUN and TURN), opening an encrypted DTLS channel, and streaming the file in acknowledged chunks.
Large files work only when chunks fit the negotiated message size, the sender respects backpressure, and the receiver writes to disk as data arrives.
Both devices must stay online and speed is capped by the sender's upload; for someone who will download later, a storage service is the better tool.
In SRIFT a failed direct connection continues on an end-to-end sealed relay from the bytes already received, instead of restarting.

This guide follows a whole transfer, whatever the technology. The browser API details are in how WebRTC file transfer works; to send a file now, see peer-to-peer file transfer in your browser.

What changes compared with uploading a file

With a cloud service the transfer is two independent operations: the sender uploads to the provider's storage, and later the receiver downloads from it. The provider holds a copy for as long as its retention policy says, and the sender and receiver never need to be online together.

A P2P transfer is one continuous operation. Bytes leave the sender and arrive at the receiver within the same session, so there is no stored copy to delete, no storage quota, and no second copy of the data moving across the internet. The trade-off is availability: if the sender closes the laptop, the transfer stops. The P2P vs cloud comparison covers when each model is the better fit.

“Peer-to-peer” also does not mean “serverless”. Two devices on the internet cannot find each other without help: neither knows the other's address, and both are usually behind routers that block unsolicited incoming traffic. Every practical P2P system uses servers for introductions and for relaying when needed. The difference is that those servers do not keep the file.

The four stages of a transfer

Signaling introduces the peers; the file then flows over a direct channel, or through a relay that forwards ciphertext when no direct path opens.

1. Rendezvous and signaling

The two sides first need a shared meeting point: a session code, a link or a QR code. Each side connects to the signaling server with it, and the server forwards small control messages between them. In WebRTC these messages are the offer and answer, written in the Session Description Protocol (SDP), which describe the channel each side wants and the fingerprint of its encryption certificate.

Signaling is not standardised by WebRTC; any channel that can carry text works. SRIFT uses its own WebSocket connection, and when a network blocks WebSockets the browser switches that connection to plain HTTPS requests (a long-polling stream) so the session keeps working.

2. Finding a network path (ICE)

Each peer gathers candidates: addresses at which it might be reachable. Host candidates are its local network addresses; server-reflexive candidates are its public address as seen by a STUN server; relay candidates are addresses on a TURN server that will forward traffic for it. The peers exchange candidates over signaling and ICE tests pairs until one carries traffic in both directions. The process is defined in RFC 8445, and STUN vs TURN explains the candidate types in depth.

3. Opening an encrypted channel

Once a pair works, the peers run a DTLS handshake over it. WebRTC requires this encryption, and the certificate fingerprints exchanged during signaling are what each side checks. In a browser the result is an RTCDataChannel: a message pipe carried by SCTP inside DTLS, which can be reliable and ordered like TCP.

4. Streaming the file in chunks

A file is far too large to send as one message, so the sender reads it in slices and sends a sequence of chunks. Three details decide whether this works for a 50 GB file and not only for a 5 MB one:

Message size. Data channels have a maximum message size negotiated in SDP (RFC 8841). Chunks must fit within it.
Backpressure. send() never blocks; it queues data and increases bufferedAmount. A sender that ignores this will happily queue gigabytes in memory. The sender must pause above a high-water mark and resume on the bufferedamountlow event.
Where the receiver puts the data. Holding a large file in page memory crashes tabs. The receiver needs to write chunks to disk as they arrive and tell the sender to slow down when it falls behind.

How SRIFT implements each stage

SRIFT is open source, so the numbers below come from its code (version 4.3.2) rather than from a description of it. They are a useful reference for anyone building the same thing.

Transfer parameters in the SRIFT browser client, version 4.3.2.
Stage	What SRIFT does
Rendezvous	Session code of three letters and four digits, plus a join link and QR code. The host approves each person who asks to join.
Signaling	WebSocket to the SRIFT server; switches to an HTTPS long-poll stream if WebSockets cannot open.
Network path	Public STUN servers from several operators, plus short-lived TURN credentials minted per request (TURN over TLS on port 443 is tried first).
Transport choice	Tries a direct WebRTC data channel and gives it 3 seconds to open; otherwise the transfer runs over the encrypted relay. WebRTC is skipped when neither UDP nor TURN is available.
Chunking (direct)	Reliable, ordered data channel; messages sized from the negotiated maximum (16 KB to 256 KB, 64 KB by default); file read in 4 MB slices.
Backpressure	Sender pauses above 8 MB buffered and resumes at 2 MB; the receiver asks the sender to pause when more than 32 MB is waiting to be written.
Relay chunks	256 KB chunks, 16 in flight, each sealed with AES-256-GCM; unacknowledged chunks are re-sent after 8 seconds.
Receiving	Streams into the browser's Downloads through a service worker where that is reliable; otherwise writes to the browser's private file storage and saves when complete.

Two design decisions are worth copying. First, the relay continues from where the direct path stopped: if a WebRTC connection fails mid-transfer, the receiver reports the bytes it already holds and the relay sends only the rest. Second, the transfer does not switch back to WebRTC once it is on the relay, because switching transports mid-stream is where ordering bugs hide.

The same idea from the command line

P2P is not limited to two browsers. A command-line peer can keep an outbound connection to a relay and serve a file on demand, which works from servers and containers that accept no inbound connections. With SRIFT the receiver needs only a browser or curl:

Sender (any machine with outbound HTTPS)

srift quick-share ./dataset.parquet --encrypt --once
# prints https://srift.app/d/<token>#k=<key>

Receiver

srift get "https://srift.app/d/<token>#k=<key>"
# or open the link in a browser

Nothing is uploaded ahead of time: when the link is opened, the server asks the sender's process for the bytes and forwards them to the downloader as they arrive. With --encrypt the key travels in the part of the URL after #, which browsers never send to servers, so the relay only handles ciphertext. The link works while the sender's process is running.

Limitations and trade-offs

Both sides must be online. There is no stored copy to fall back on. For asynchronous delivery to someone who will download tomorrow, a storage service is the simpler tool.
Speed is capped by the sender's upload. Removing the server hop does not raise the slowest link in the path; on many home connections upload is a fraction of download. See why P2P transfers are slow.
Direct connections reveal IP addresses. To connect directly, each peer learns the other's network addresses. That is inherent to direct connections, not a bug in any one tool.
Some networks never allow a direct path. Strict firewalls, some carrier-grade NATs and UDP-blocking proxies force traffic through a relay. A tool without a relay simply fails on those networks.
One-to-many is expensive. Sending one file to ten people from one device means uploading it ten times, unless recipients also re-share pieces (as BitTorrent does).

Frequently asked questions

Is P2P file transfer the same as torrenting?

BitTorrent is one kind of P2P transfer, designed for distributing a file to many peers that each share pieces. Live P2P tools such as WebRTC-based transfers connect exactly two endpoints for one transfer, usually with a session code instead of a public swarm.

Does P2P file transfer work across different networks?

Yes. ICE tries local, public (STUN) and relayed (TURN) paths, so peers on different networks can connect. When no direct path works, a relay carries the traffic, which is slower but still works.

Is there a file size limit in P2P transfer?

The protocol has none, because the file is streamed. Practical limits come from the receiving side: a browser must be able to write the file to disk as it arrives rather than hold it in memory.

References

Try a direct transfer

Open a session in one browser, join it from another device, and send a file. No account, nothing to install on either side.