What is peer-to-peer file transfer?

Last updated: 2026-08-07

"Peer-to-peer" gets used loosely, so here's what it actually means for a file transfer: your file goes straight from one device to the other, not up to a company's server and back down. No stop in the middle where a copy could sit.

That sounds simple, but routes differ in practice. This page first explains generic WebRTC/ICE, where TURN can be a fallback, then separates Relayium's actual choices: LAN browser WebRTC is direct, cross-network browser sessions use TURN by design, and the CLI is direct-only.

P2P vs. the usual way: cutting out the middle stop

Most "send a file" tools work by uploading: your file goes from your device up to the company's server, gets stored there, and the other person downloads it back down. That's two hops, and for a while, a full copy of your file sits on someone else's storage — even if it's deleted later.

Peer-to-peer transfer skips that stop. Once a connection is open between your device and the other person's, the file's bytes flow directly across that one hop and nowhere else. There's no server-side copy to store, to secure, or to eventually delete, because it was never uploaded in the first place.

Upload-based transfer: your device to a server to their device — two hops, a stored copy in between.
Peer-to-peer transfer: your device straight to their device — one hop, nothing stored.
Relayium's realtime browser mode has two paths: WebRTC is direct on the same LAN, while cross-network sessions use TURN by design to carry end-to-end encrypted ciphertext without keeping a server-side content copy or history.

How two devices actually find each other: STUN

Here's the part that isn't obvious: your device almost certainly doesn't know its own address as seen from the outside internet — it sits behind a home router or a mobile carrier's network address translation (NAT), which hides it behind a shared public IP and reassigns ports on the fly. The other device is in the same situation. Neither one can just "dial" the other directly without first figuring out what address would actually reach it.

That's what STUN (Session Traversal Utilities for NAT) is for. Each device briefly asks a small, lightweight STUN server one question: "what address and port do you see me coming from?" The answer tells it its own public-facing address — not the file, not any content, just enough network information to describe a path back to it. Both devices exchange this information (via a signaling step that only carries connection-setup details, never file bytes) and then try to open a direct path to each other's address. In a large share of real-world cases — especially two devices on the same Wi-Fi, or NATs that behave predictably — this works, and a fully direct connection opens.

STUN only ever learns and shares network addresses — never file contents, filenames, or encryption keys.
Relayium uses WebRTC directly for same-LAN browser sessions. Its cross-network browser path is deliberately relayed.
Relayium CLI send/receive and text are direct-only P2P: they never relay file or message bytes through TURN or any other Relayium server. If the two ends cannot establish a direct connection, the session fails rather than falling back to a relay.
Two devices on the same network (no code needed) typically connect the most directly of all, since there's often no NAT in the way at all.

When a direct path can't be found: the TURN relay

Sometimes STUN isn't enough. Some NATs — especially on stricter corporate networks or certain mobile carriers — are unpredictable enough that no direct path can be discovered from outside information alone. If both devices are behind that kind of NAT, a genuinely direct connection just isn't possible; something has to relay the traffic in between.

In a general WebRTC/ICE design, TURN (Traversal Using Relays around NAT) can be the fallback relay when a direct path fails. Relayium's browser app makes a more deliberate choice: same-LAN sessions use direct WebRTC, while every cross-network session uses TURN from the start. The file is encrypted end-to-end before reaching the relay, so it carries only ciphertext and cannot read or decrypt the content.

On the same network Relayium connects devices directly; across networks it uses the TURN relay by default, because a direct path so often can't be found there.
The relay forwards ciphertext only; it never has the decryption key and can't read file contents, filenames, or anything else about what's inside.
Relayium CLI send/receive and text are direct-only P2P: they never relay file or message bytes through TURN or any other Relayium server. If the two ends cannot establish a direct connection, the session fails rather than falling back to a relay.

Why this matters: privacy and speed

The privacy case is straightforward: when the file's bytes only ever cross one hop, straight between two devices, there's no server-side storage step where a copy could sit, get logged, or get accessed by anyone else — because it was never put there. That's a structurally different guarantee than "we promise to delete it eventually."

The speed case follows the same logic. An upload-then-download transfer has to cross the network twice — once up, once down — and often waits on the sending side to fully finish before the receiving side can start. A direct connection crosses the network once, and data can stream continuously between the two devices as fast as the slower connection allows, without a server in the middle limiting throughput or adding its own latency.

How Relayium puts this together

What you need to check this yourself

Two devices you can watch at the same time — a laptop and a phone is ideal.
A small file. This is about which path the connection takes, not about throughput.
A moment with both on the same Wi-Fi, and a moment with them on different networks — turning the phone's Wi-Fi off for mobile data is enough.

Open relayium.com on two devices on the same network and they typically find each other automatically — no account, no code, nothing to install; that's the LAN case where STUN often isn't even needed. Sending across the internet to someone on a different network uses a pairing code: the sender signs in, generates a code (or shares a link, with an optional QR code to scan), and once the other person joins, the transfer runs over an encrypted TURN relay — the reliable path across unpredictable NATs, and it only ever carries ciphertext — while the receiver never needs an account.

Once the realtime path is open, up to 1,000 files stream continuously over the selected route, each independently verified with a SHA-256 hash. Relayium keeps no server-side realtime content copy or transfer history. If the other person is offline, a zero-knowledge stored link is a genuinely different mode, not a realtime P2P session.

With both devices on the same Wi-Fi, open Relayium on each and send the file.
```
https://relayium.com/
```
Read the label the app puts on the connection. On one network it says LAN direct.
Now put the two devices on different networks and send again, this time using a pairing code.
```
https://relayium.com/cross-network
```
Read the label again. P2P direct means a direct path was found across the internet. Relayed means one could not be, and the encrypted relay carried the bytes instead.
Note which you got, and on which pair of networks. That is your own answer to the question this article opened with, rather than ours.

What the labels tell you

On one network you get LAN direct. Across networks you get either P2P direct or Relayed, and which one depends on the two networks rather than on anything you configured.

Relayed is not a failure. It is the fallback existing and doing its job, and the relay only ever carries ciphertext — it is the case this article's TURN section describes, seen from the inside.

When the label is not what you expected

Three things surprise people the first time they look. None of them is a fault to fix, but each is worth being able to name.

What you see, what to check, what it means

Across networks it always says Relayed, never P2P direct.

https://relayium.com/cross-network   # the path label reads the same on both ends

Check whether both ends are on mobile data or behind carrier-grade NAT, which is the usual reason no direct path exists. There is nothing to fix: this is the designed fallback, the relay carries ciphertext only, and same-network transfers between the same two devices still go direct and stay free.

On one Wi-Fi it never says LAN direct.

https://relayium.com/   # both devices on one Wi-Fi, and the path label never says LAN direct

Check whether the network isolates its clients — guest Wi-Fi, and many hotel and office networks, block device-to-device traffic outright. The two devices cannot see each other at all there, so use the cross-network pairing flow instead, which does not depend on them reaching each other locally.

There is no path label at all.

https://relayium.com/   # there is no path label until the two ends have connected

The label names a connection, so it appears once one exists. Before the two ends have found each other there is nothing to name, and a transfer that never starts is a different problem from a transfer that took an unexpected path.

Frequently asked questions

Is peer-to-peer the same as end-to-end encrypted?

They're related but not identical. P2P describes communication between endpoints, but it does not guarantee that every network hop is direct; TURN may carry the traffic. Encryption describes whether intermediaries can read it. Relayium uses direct WebRTC on the same LAN and end-to-end encrypted TURN across networks, where the relay cannot read or decrypt the content.

Does a P2P transfer ever touch a server at all?

A small signaling server helps the two devices find each other's address — but it only ever sees connection-setup information, never file bytes. Across networks in the browser, a TURN relay forwards the encrypted file data as a matter of design, but even then it only handles ciphertext it can't decrypt.

Why would a direct connection fail in the first place?

Some networks — often strict corporate firewalls or certain mobile carrier NATs — are built in a way that makes it impossible to discover a reachable address from outside information alone. Rather than spend twenty-odd seconds finding that out on every transfer, Relayium's browser app sends all cross-network transfers over the relay from the start — so a relay, not a failed direct attempt, is what carries them.

Is P2P transfer slower when it goes over a relay?

It can add some latency, since the relay is an extra hop the data passes through and it's a shared server rather than a dedicated one. But it's still generally faster than an upload-then-download flow, since there's no wait for the file to fully land on a server before the download side can start.

Do both people need an account for a P2P transfer?

Two devices on the same network need no account at all. Sending across networks by pairing code needs the sender to sign in, but the person receiving never needs an account either way.

Curious what it feels like? Open Relayium on two devices and start an encrypted realtime session.

Try Relayium now