How local network file sharing works

When you drop a file into FreeAirShare and someone on the same WiFi downloads it, the file travels from one browser to another without touching any server. Here is exactly what happens at each step.

The problem with "normal" sharing

Most file sharing works by uploading to a cloud service and then downloading from it. Your file travels from your device to a data centre somewhere, then back from that data centre to your friend's device — even if you're both sitting at the same desk on the same WiFi network. For small files this is fine. For a 2 GB video, you're waiting for an upload that might top out at 10 Mbps, when the WiFi between your two devices could move the same data at 200 Mbps or faster.

What WebRTC adds

Browsers have shipped a technology called WebRTC (Web Real-Time Communication) for over a decade, mostly known for powering video calls. WebRTC can also open a raw data channel between two browsers — no server in the middle. Once that channel is open, data flows directly between the two endpoints using whatever network path is available. If both browsers are on the same WiFi, the data moves entirely on your local network.

The signalling step

Before two browsers can talk directly, they need to exchange some technical information: network addresses, firewall settings, and what codecs and protocols each side supports. This exchange is called "signalling" and it does require a server, but only briefly and only for small text messages — not file data.

FreeAirShare uses PeerJS, a library that wraps WebRTC and provides a simple signalling server. When you open FreeAirShare, your browser connects to PeerJS and gets assigned a random peer ID (something like bf3a0ec2-1822-44d3). When a downloader clicks on your share, their browser sends their connection details to yours via PeerJS. Your browser responds. PeerJS passes the messages back and forth until both sides have enough information to talk directly — then PeerJS is no longer involved.

Discovery: how devices find each other

WebRTC handles the transfer, but it does not solve discovery — how does the downloader know there are files available at all? FreeAirShare uses a small server-side registry for this. When you start sharing, your browser posts a brief record to the server: your peer ID, the number of files, total size, and a title. The server reads the first three octets of your IP address (e.g. 192.168.1) to derive a subnet ID, and stores the record tagged with that ID.

When someone opens the Discover tab, their browser asks the server for all active shares on their subnet. The server returns the list — peer IDs and metadata only, no file content. The downloader's browser then uses those peer IDs to initiate WebRTC connections. Once connected, the requesting browser sends a request-file message directly to the sharing browser, which reads the file from local memory and sends it in 64 KB chunks over the data channel.

What the file data path looks like

Chunking and reassembly

WebRTC data channels have practical limits on how much data you can push at once. To handle files of any size, FreeAirShare splits the file into 64 KB chunks on the sender side and sends them in sequence, with a small pause every 10 chunks to avoid overwhelming the channel buffer. The receiver collects each chunk in order and combines them into a complete Blob in browser memory. When the last chunk arrives, the browser triggers a download.

If the connection drops mid-transfer, FreeAirShare tracks how many chunks were received and, on reconnect, asks the sender to resume from that chunk index — so a large file does not have to restart from zero after a brief interruption.

Why it only works on the same network

WebRTC can in theory work across different networks using a relay server called a TURN server. FreeAirShare does not configure a TURN server, so if the direct peer connection cannot be established — which it typically cannot across different networks — the transfer fails. This is intentional: the whole point of the tool is fast local transfers, and adding a relay would make the tool dependent on maintaining server infrastructure, which would cost money and introduce the kind of delay that motivates using a cloud service in the first place.

Text sharing is different

The Text tab does not use WebRTC. Short messages are stored in the server's memory and polled by devices every few seconds. This is simpler and more reliable for small text payloads because it does not require establishing a peer connection. Messages expire automatically after 10 minutes of inactivity.