LAN File Transfer
Transfer files and text directly between devices on the same local network via WebRTC - no server required
What is LAN File Transfer?
LAN File Transfer uses WebRTC peer-to-peer communication to send files and text between two devices on the same local network. After the connection is established, data can move directly between the browsers instead of being uploaded to an external storage service first. That direct path suits office computers, test devices, home networks, classrooms, labs, and quick handoffs where USB drives, cloud folders, or chat attachments would be slower or more awkward. Transfer speed depends on the local network, browser support, and device performance. For sensitive files, users should verify the receiving device and close temporary sessions when the exchange is finished.
How to Use
How to use
- On one device, click "Create Connection" - the system will generate a QR code containing connection information
- Scan the QR code with another device - the page will automatically open and generate a response code
- Scan the response code with the first device - the WebRTC connection will be established
- Once connected, both parties can exchange text messages and any type of files
Transfer Tips
- Keep both devices awake and on a reachable network while transferring files; closing the tab or sleeping the device will interrupt the WebRTC session.
- For very large or critical files, verify the downloaded file after transfer because browser memory, network quality, and device limits can affect reliability.
Use Cases
Technical Principle
LAN File Transfer is built on WebRTC (Web Real-Time Communication), the W3C/IETF standard defined in RFC 8825-8835, originally designed for browser-based real-time audio and video. The same peer-to-peer machinery supports the RTCDataChannel API, which carries arbitrary binary payloads between two browsers without any relay server in the data path. The signalling that opens the channel is what the QR-code handshake does: the offerer creates an SDP (Session Description Protocol, RFC 8866) blob describing its media and data capabilities, encodes it in a URL or QR code, and the answerer returns a counter SDP. Once both sides have applied the remote description, ICE (Interactive Connectivity Establishment, RFC 8445) gathers candidate transport addresses. Each candidate is a (IP, port, protocol) tuple plus a priority: host candidates (the device's own LAN IP) usually win on the same network, but srflx (server-reflexive, learned from a STUN binding request) and relay (TURN-relayed, RFC 8656) candidates are tried in priority order. Connectivity checks send STUN binding requests between candidates; the first pair that succeeds becomes the selected candidate pair. Once ICE reaches the connected state, DTLS (Datagram Transport Layer Security, RFC 6347, the UDP-friendly cousin of TLS 1.2/1.3 in RFC 5246/8446) fingerprints both peers using the certificate hashes in the SDP, performing a one-RTT handshake. The DTLS session keys then protect every SCTP (Stream Control Transmission Protocol, RFC 4960/RFC 9260) packet on top, and each DataChannel is a pair of SCTP streams running over that single DTLS association. Large files are sent in chunks over the DataChannel. The browser's SCTP layer fragments each message into ~16 KB records (the default SCTP MTU minus the DTLS + SCTP + Chunk Header overhead, and tunable per implementation, often 16 KB or 64 KB depending on the engine), and the receiver reassembles them in order. Flow and congestion control (RFC 4960 §6) prevent the sender from flooding the receiver: cwnd grows additively on ACK and shrinks multiplicatively on loss, the same shape as TCP's AIMD but applied per SCTP association. On a gigabit LAN, end-to-end throughput is usually capped at 200-400 MB/s by the browser's main-thread encoding cost (turning each chunk into an ArrayBuffer view and pushing it into the SCTP stack), not by the wire speed. The page reassembles incoming chunks into a single Blob and offers it as a download so the user can decide where the bytes land, which keeps the receiver from holding gigabytes in memory at peak. Because data flows peer-to-peer over DTLS-SRTP-style encryption, intermediate routers and any relay servers only see ciphertext; the operator of the page never sees the plaintext, and there is no upload step. The trade-off is the signalling server needed to exchange SDP — this page uses QR codes and copy-paste links as a manual, serverless signalling channel, which is why two scans are required.
- WebRTC is a W3C/IETF standard (RFC 8825-8835) that bundles three engines: SDP for negotiation, ICE for candidate gathering, and DTLS-SRTP / DTLS-SCTP for transport security.
- The QR-code handshake is serverless signalling: the offerer publishes an SDP offer, the answerer returns an SDP answer, and no central server ever sees the data path.
- ICE (RFC 8445) collects host, srflx (STUN-reflexive), prflx (peer-reflexive), and relay (TURN, RFC 8656) candidates; the highest-priority pair that passes connectivity checks becomes the selected transport.
- DTLS (RFC 6347) does a one-RTT fingerprint-verified handshake using the certificate hashes pinned in the SDP, then encrypts every byte on the wire — no plain HTTP or WebSocket fallback.
- DataChannel runs on SCTP-over-DTLS, not raw UDP: SCTP provides ordered, reliable, message-oriented streams with congestion control (RFC 4960 §6) on top of a UDP socket.
- Chunk size is roughly 16 KB by default (browser-specific, sometimes 64 KB): the receiver reassembles chunks into a single Blob and triggers a download to avoid holding the whole file in memory.
- Browser memory is the real ceiling: a 1 GB file means ~1 GB of ArrayBuffer churn, so on phones the practical limit is usually 200-500 MB per transfer, not the network's speed.
- WebRTC NAT traversal needs a STUN/TURN server for cross-network peers; this page assumes a same-LAN topology, so host candidates (LAN IPs) usually win and no STUN server is consulted.
Examples
Send Photos from Phone to Computer
1. On the computer, click "Create Connection" to generate a QR code
2. Scan it with the phone; the page opens and produces a response code
3. Scan the response code on the computer to complete the handshake
4. Select the photos you want to send and click SendSend Files from Computer to Phone
After the connection is up, click "Send File" on the computer and pick a document, archive, or video.
The phone receives a prompt and saves the file with a single tap.Exchange Text Messages
Once connected, both sides can type in the input box and send.
No extra app required - it is a simple two-way chat in the browser.FAQ
How does file transfer work?
Two devices on the same local network connect via WebRTC peer-to-peer. After signalling sets up the connection, files travel directly between browsers - they don't pass through any intermediate server. Speed depends on your local network (Wi-Fi or Ethernet); typical Wi-Fi delivers 30-150 Mbps.
Do my files leave the local network?
Once the WebRTC connection is established, no - file bytes flow only between the two devices. A small signalling step (exchanging session descriptions) happens through a coordination server before the connection is up; that exchange is metadata, not file content.
Why won't the two devices connect?
Both devices must be on the same Wi-Fi network or LAN segment. Corporate networks often block peer-to-peer connections; guest Wi-Fi often isolates clients from each other ('client isolation'). Try a personal Wi-Fi or hotspot. VPNs on either device can also block direct peer connection.
Is there a file size limit?
WebRTC has no protocol limit, but practical limits are browser memory and tab uptime. Multi-GB transfers usually work on desktops; mobile browsers may suspend the tab and break the transfer. Keep both tabs in the foreground during large transfers.
Are transferred files encrypted?
Yes. WebRTC data channels use DTLS-SRTP encryption end-to-end; even an attacker on the same Wi-Fi can't read the file content. The signalling step uses HTTPS to the coordination server. Treat the transfer as private as long as both endpoints are trusted.
Does it work for non-tech users?
Yes - share the room code/URL with the other person; they open it in their browser and the connection forms automatically. No app install. The interface looks like AirDrop without the platform restriction. Works between iOS Safari, Android Chrome, Windows Edge, macOS Firefox, etc.
Can I send to multiple devices at once?
Most builds support a one-to-one room. To send to multiple receivers, repeat the transfer or use a multicast tool. Group transfer over WebRTC is implementable but uses N times the upload bandwidth.