How it works
Three connection modes, a minimal signaling server, and peer-to-peer WebRTC transfers — explained plainly.
Three connection modes
Phone ⇅ Internet ⇅ Signaling Server ⇅ PC
Both devices connect to the internet. The signaling server brokers the WebRTC connection. File content travels peer-to-peer after that — the server only sees session metadata, not file content.
Phone ⇅ Wi-Fi / LAN ⇅ PC
Both devices are on the same Wi-Fi or LAN. WebRTC can establish a peer connection via local network addresses (mDNS or local ICE candidates). Ideal for college labs where internet may be restricted.
App cached in browser (PWA)
Once you have visited OnlineCopyPaste, the app shell is cached as a PWA (Progressive Web App). The UI loads from cache when offline. However, actual device-to-device transfer requires at least one communication path (internet, LAN, or hotspot). If no path exists, transfer is technically impossible — we say so clearly.
Session flow — step by step
- 1
PC visits onlinecopypaste.net
A temporary session is created: unique ID, 6-digit pair code, and a QR code pointing to /join/{pairCode}.
- 2
PC connects to WebSocket signaling server
The PC's browser opens a WebSocket connection and sends a "join" message with the session token and role=pc.
- 3
Phone scans QR or enters code
Phone visits /join/{code} and the browser sends a "join" message with role=phone.
- 4
Server broadcasts "paired" to both peers
The signaling server relays a "paired" message to both the PC and the phone. This is the only moment the server knows both peers are connected.
- 5
PC creates a WebRTC offer
The PC generates an SDP offer (session description) and sends it to the signaling server for relay to the phone.
- 6
Phone creates an answer
The phone responds with an SDP answer, relayed back to the PC via the signaling server.
- 7
ICE candidates exchanged
Both peers exchange ICE candidates (network address candidates) via the signaling server, selecting the best path (LAN, STUN, or TURN).
- 8
DataChannel opens — transfers begin
Once the RTCPeerConnection is established and the DataChannel is open, all content transfers go directly peer-to-peer. The signaling server is no longer involved.
- 9
Session destroyed
When the user clicks "Destroy Session" or the session expires, the server deletes the session record, disconnects all peers, and any temporary data is cleared.
Technical FAQ
- What does the signaling server actually see?
- The signaling server sees: session ID, pair code, your IP address, and the SDP offer/answer messages (which contain network metadata but not file content). It never sees the files, text, or code you transfer.
- Is WebRTC actually peer-to-peer?
- When both peers are on the same LAN or have compatible NAT, yes — data flows directly between devices with no intermediary. In cases where NAT prevents direct connection, a TURN relay server forwards the encrypted data. Even over TURN, the content is end-to-end encrypted with DTLS.
- What happens if the connection drops?
- The hook retries the WebSocket connection up to 3 times with exponential backoff. If the WebRTC DataChannel closes, the connection state is displayed and the user can manually reconnect using the same session code (if the session has not expired).
- Can someone intercept my transfer?
- WebRTC DataChannels use DTLS (similar to TLS) for encryption. An attacker on the same network cannot read the transfer content. However, if an attacker controls the signaling server, they could attempt a man-in-the-middle attack during the SDP exchange — use only trusted instances of this service.