How StreamSnatcher Works

Direct, encrypted, browser‑to‑browser file transfers using WebRTC data channels—no accounts, no server storage, and no detours through the cloud.

Quick start

1

Create a session

Open the homepage and create a session to generate a unique room code or QR that only invited participants can use.

Tips:

  • Share the room code or QR through a trusted channel to control access.
  • Keep the tab open while sending or receiving to maintain the connection.
2

Connect peers

Browsers exchange session data over signaling and then use STUN to discover public endpoints for a direct WebRTC connection.

What happens:

  • Session descriptions and ICE candidates are exchanged to negotiate connectivity.
  • If a direct path is blocked, a TURN relay may be used while traffic remains encrypted.
3

Transfer files

Files are split into chunks and streamed over encrypted WebRTC data channels, then reassembled on the recipient device with real‑time progress.

Good to know:

  • Transfers can be one‑to‑one or shared across a small room of peers.
  • Closing the session ends connectivity and discards temporary session data.

Technical flow

Signaling and negotiation

Session setup begins with signaling to exchange SDP offers/answers and ICE candidates, enabling peers to agree on codecs, transport, and candidate routes.

STUN/TURN connectivity

STUN helps peers discover their public addresses for NAT traversal, and when direct routes fail, a TURN relay may carry traffic while transport encryption remains active.

Data channels and chunking

WebRTC’s SCTP over DTLS data channels stream file chunks efficiently with congestion control and retransmission tuned for large payloads.

Reassembly on receive

Received chunks are buffered and reassembled into a Blob on the recipient side, preserving file integrity without writing to servers.

Security model

🔐

Encrypted in transit

All transfers occur over DTLS‑encrypted channels so contents are unreadable to intermediaries.

🗄️

No server file storage

Files are never uploaded to servers; transfers remain device‑to‑device for maximum privacy.

🧯

Minimal session data

Only essential, temporary metadata is used to establish connections and is discarded with the session lifecycle.

🧭

User control

Leaving the page ends the session and halts all transfers immediately by design.

See the Privacy Policy in the footer for detailed disclosures or visit the Contact page for questions about data handling.

Performance tips

  • Prefer stable Wi‑Fi or Ethernet; avoid captive portals and restricted enterprise networks.
  • Keep the browser tab active during large transfers to prevent throttling by background policies.
  • If a peer disconnects, rejoin the same session to continue handoffs with remaining participants.
  • Close unused heavy apps to free CPU and memory for smoother chunk processing.

Limits and compatibility

  • Designed for modern browsers that support WebRTC data channels and required encryption.
  • Room size is optimized for small groups to balance reliability and throughput.
  • Extremely restrictive firewalls may require a TURN relay, which can reduce peak speeds.

Troubleshooting

  • If peers cannot connect, refresh both tabs and ensure the session code matches exactly.
  • Disable aggressive tracker‑blocking extensions for the session if they interfere with signaling.
  • Switch networks if NAT or firewall rules block P2P; a mobile hotspot can confirm if the ISP is the constraint.
  • For persistent issues, describe the steps on the Contact page for targeted assistance.

For more guidance, check the FAQ in the navigation or open the Contact page to share details about your environment and browser versions.