WebRTC Diagnostics & Peer-to-Peer Transfer Tools
Check WebRTC support, ICE candidates, STUN and TURN services, then move files, folders, and text between two browsers.
Choose a tool
Diagnose the connection first. A transfer only works where ICE already worked.
Two tools that belong in sequence. The checker tells you whether this browser and this network can establish a peer connection at all; the transfer tool uses that connection to move files, folders, and text directly between two browsers. When a transfer will not connect, the checker is what separates a browser that cannot from a network that will not.
Run the checker first, then the transfer
WebRTC Support, ICE Candidate, STUN & TURN Checker confirms that the browser exposes RTCPeerConnection and RTCDataChannel, gathers the ICE candidates visible from this machine, and tests each STUN or TURN service you enter. A STUN service has only really answered when a server-reflexive candidate appears; a host candidate on its own proves nothing about NAT traversal.
WebRTC Peer-to-Peer File & Text Transfer then connects two browsers and streams the payload over the encrypted data channel between them. Pair the devices with a room code, an invite link, or a QR code, or switch to manual codes and copy the offer and answer yourself when you would rather not involve a signalling mailbox at all.
Where the bytes go, and where they do not
File and message contents travel only over the direct data channel, which is encrypted with DTLS. They do not pass through this site. In room mode the server relays only the session description and ICE candidates, holds them in memory for at most ten minutes, and releases them once the channel is up; manual codes avoid that mailbox entirely.
STUN and TURN credentials stay in the browser and are sent only to the servers you configure. Bring your own TURN rather than borrowing one, because when both sides sit behind restrictive NAT the TURN server relays the whole encrypted stream, and whoever operates it is carrying your traffic even though they cannot read it.
Limits worth knowing before you rely on it
This is a live channel, not a mailbox. Both peers must be online at the same time, and there is no store-and-forward, so a transfer cannot be started now and collected tomorrow. Size is bounded by the receiving side: choose a receive folder to stream straight to disk, or the data is buffered in browser memory instead.
A successful diagnostic describes one browser on one network at one moment. Corporate firewalls that block UDP, captive portals, and symmetric NAT all change the outcome, so re-run the checks from the network the transfer will actually use rather than from the one where you tested it.
Before you rely on a result
- Confirm that RTCPeerConnection and RTCDataChannel exist before blaming STUN or TURN for a failure.
- Treat a STUN check as passing only when a server-reflexive candidate is returned, and a TURN check only when a relay candidate is.
- Test one STUN or TURN service at a time, with the credentials that service issued, so a failure points at something specific.
- Pick a receive folder before a large transfer so bytes stream to disk rather than accumulating in browser memory.
- Re-run the checks on the network the transfer will actually use, and verify the pairing code with the other person out of band.
Frequently asked questions
Do my files pass through your server?
No. Files, folders, and text move directly between the two browsers over the WebRTC data channel, encrypted with DTLS. In room mode the server relays only the short session-setup messages, and manual codes skip even that.
STUN worked, so why do I need TURN?
STUN only discovers your public address mapping, which is enough when at least one side is reachable through its NAT. When both networks block direct paths, nothing can connect without a relay, and that is what TURN provides. It is also why TURN requires credentials.
Can I send a file while the other side is offline?
No. The channel is peer to peer, so both browsers have to be open and connected at the same time. There is no queue, no server-side copy, and closing either tab ends the transfer.
Is the transfer really encrypted?
WebRTC data channels are encrypted with DTLS and this cannot be turned off. That secures the path, not the peer: encryption guarantees nobody in the middle reads the bytes, so confirm through another channel that the person on the other end is who you expect before sending anything sensitive.
Browse all developer tools or read the developer tool guides for worked examples.