How StreamSnatcher Works
A detailed look at the technology and process behind direct, encrypted, browser‑to‑browser file transfers — from creating a session to receiving your files.
Quick Start Guide
StreamSnatcher is designed so that you can start transferring files within seconds, without creating an account or installing any software. Here's the step-by-step process:
Create a session
Open the StreamSnatcher homepage and click the Start Transfer button. This generates a unique room code and a scannable QR code. The room code is a random, cryptographically secure token — it cannot be guessed or brute-forced. Share the code or QR with your intended recipient through any trusted communication channel (messaging app, email, in person).
Tips:
- Only people with your exact room code can join the session. Share it carefully.
- Keep the browser tab open and in the foreground — closing it ends the session.
- Sessions support up to 2 peers for optimal transfer performance.
Connect peers
When the recipient opens the session link or scans the QR code, both browsers begin an automatic connection process. This happens behind the scenes in milliseconds: the browsers exchange SDP (Session Description Protocol) offers and answers through StreamSnatcher's signaling server, describing each browser's capabilities and network configuration.
Simultaneously, ICE (Interactive Connectivity Establishment) candidates are gathered. These are potential network paths the browsers can use to reach each other. STUN servers help each browser discover its public-facing IP address for NAT traversal. Once a viable path is found, a direct, encrypted WebRTC connection is established.
What happens behind the scenes:
- SDP offers and ICE candidates are exchanged via the signaling server (WebSocket).
- STUN servers help discover public endpoints when peers are behind NATs.
- If direct connectivity fails (restrictive firewalls), traffic routes through a TURN relay while remaining end-to-end encrypted.
Transfer files
Drag and drop files into the upload zone, or use the file picker to select them. StreamSnatcher reads each file using the browser's File API, splits it into manageable chunks, and streams those chunks through the encrypted WebRTC data channel directly to the recipient's browser. Progress is shown in real time with per-file status indicators.
Good to know:
- Files are sent bit-for-bit — no compression, transcoding, or quality loss occurs.
- Any file type can be transferred: documents, images, videos, archives, executables, and more.
- You can queue multiple files and they'll be sent sequentially.
- Closing the tab ends the session and all active transfers immediately.
Download received files
On the receiving end, the browser buffers incoming chunks and reassembles them into the original file as a Blob object. Once complete, the file is ready for download. The reconstructed file is byte-identical to the original — no data is lost, modified, or compressed during the transfer process.
Tips:
- Downloaded files go to your browser's default download directory.
- For very large files, ensure you have sufficient free disk space before starting the transfer.
Technical Deep Dive
This section is for those who want to understand the underlying protocols and mechanisms in more detail. For most users, the Quick Start Guide above is all you need.
Signaling: The Connection Handshake
Before two browsers can exchange file data, they need to discover each other and agree on communication parameters. This process is called signaling, and it's the only part of the transfer where StreamSnatcher's server is involved.
When a session creator and a joiner are both connected, their browsers generate SDP (Session Description Protocol) descriptions. The SDP offer from the initiator contains information about supported codecs, encryption methods, and network capabilities. The joiner responds with an SDP answer confirming compatible parameters. These messages are relayed through StreamSnatcher's WebSocket signaling server — the server sees only the session metadata (not file content), and its role ends once the connection is established.
ICE, STUN, and TURN: Finding a Path
Most devices don't have directly reachable public IP addresses — they sit behind NAT (Network Address Translation) routers. ICE (Interactive Connectivity Establishment) is the process by which WebRTC systematically tries different network paths to establish connectivity:
- Host candidates — the device's local IP addresses (e.g., 192.168.x.x). These work when both peers are on the same local network.
- Server reflexive candidates — the public-facing IP and port discovered via a STUN server. This is the most common successful path for home and mobile networks.
- Relay candidates — traffic routed through a TURN server when direct paths are blocked by symmetric NATs or corporate firewalls. The TURN server sees encrypted packets but cannot decrypt them.
ICE tests these candidates in priority order and selects the most direct available path. On well-connected home networks, a direct peer-to-peer connection is typically established in under one second.
Data Channels: SCTP over DTLS
Once connected, file data flows through a WebRTC data channel built on SCTP (Stream Control Transmission Protocol) running over DTLS (Datagram Transport Layer Security). This combination provides:
- Encryption — DTLS encrypts all data in transit using keys negotiated directly between the two peers. Even StreamSnatcher's signaling server cannot decrypt the data.
- Reliable, ordered delivery — SCTP provides TCP-like reliability (retransmission of lost packets, in-order delivery) while running over UDP, which avoids TCP's head-of-line blocking problem.
- Congestion control — built-in algorithms prevent the data channel from overwhelming slower network links, adapting throughput dynamically based on available bandwidth and packet loss.
File Chunking and Reassembly
Browsers have a maximum message size for WebRTC data channels (typically 256 KB or less depending on implementation). StreamSnatcher handles this by splitting files into chunks before sending. On the sending side, the File API reads file data as ArrayBuffer slices, which are sent sequentially through the data channel. On the receiving side, chunks are buffered in memory and reassembled into a complete Blob object once all chunks have arrived. The resulting Blob is then made available for download through a dynamically generated object URL.
This chunking approach allows transfers of files much larger than what would fit in a single WebRTC message, limited only by available device memory and storage space rather than protocol constraints.
WebRTC vs. Traditional File Transfer
Traditional file-sharing services use a store-and-forward model: the sender uploads a file to a server, and the recipient downloads it from that server. This model has been the default for decades (email attachments, cloud drives, file-hosting services), but it introduces inherent tradeoffs:
| Aspect | WebRTC (StreamSnatcher) | Traditional Cloud Transfer |
|---|---|---|
| Speed | Direct peer-to-peer; limited only by network bandwidth between the two devices | Upload, wait, then download — two separate transfers, each bottlenecked by the server |
| Privacy | Files never leave the peers' devices; encrypted in transit with DTLS | Files stored on third-party servers with varying encryption and retention policies |
| Size limits | No artificial limits; constrained only by device memory and storage | Typically capped at 2 GB – 15 GB on free tiers; email limited to 25 MB |
| Account required | No — instant use with zero registration | Usually requires an account with email verification |
| Data retention | Zero — sessions are ephemeral, no data persists after closing the tab | Files may be retained for days, months, or indefinitely on provider servers |
| Availability | Requires both peers to be online simultaneously | Asynchronous — recipient can download later |
Both models have valid use cases. WebRTC peer-to-peer excels when speed, privacy, and large file size matter. Cloud services are better when asynchronous access or long-term storage is needed. StreamSnatcher is purpose-built for the former scenario.
Security Model
Security in StreamSnatcher is a byproduct of the peer-to-peer architecture rather than an add-on feature. Here's what protects your data at each layer:
Encrypted in transit
All file data travels through DTLS-encrypted WebRTC data channels. Encryption keys are negotiated directly between the two peers — StreamSnatcher, your ISP, and any network intermediaries see only encrypted bytes.
No server file storage
Files never touch StreamSnatcher's servers. The server facilitates signaling only — exchanging SDP offers and ICE candidates. Once the peer connection is established, the server is not involved in the data flow.
Minimal session metadata
The only data StreamSnatcher processes is connection metadata (session IDs, ICE candidates) and short-lived diagnostic logs. File names, file sizes, and file contents are never seen or recorded by the platform.
Ephemeral sessions
Sessions exist only while peers are connected. Closing the browser tab immediately terminates the session and discards all associated connection data. There's no way to "reopen" a closed session.
For complete details on our data practices, see the Privacy Policy.
Browser Compatibility
StreamSnatcher relies on WebRTC data channels, which are natively supported by all major modern browsers. Here's a compatibility overview:
| Browser | Desktop | Mobile | Notes |
|---|---|---|---|
| Chrome | ✅ v56+ | ✅ Android & iOS | Best overall performance and compatibility |
| Firefox | ✅ v52+ | ✅ Android | Full support; strong privacy features |
| Edge | ✅ Chromium-based | ✅ Android & iOS | Same engine as Chrome; fully compatible |
| Safari | ✅ v11+ | ✅ iOS 11+ | Supported; keep browser tab in foreground on iOS |
| Opera | ✅ v43+ | ✅ Android | Chromium-based; fully compatible |
| Brave | ✅ All versions | ✅ Android & iOS | May need WebRTC whitelisted in Shields settings |
| Internet Explorer | ❌ Not supported | N/A | IE does not implement WebRTC |
Performance Tips
While StreamSnatcher handles the technical complexity automatically, you can optimize transfer speed and reliability with these practices:
- Use a stable connection — Wi-Fi or Ethernet is significantly more reliable than cellular data. Avoid captive portals (hotel, café Wi-Fi) which may block WebRTC.
- Keep the tab in the foreground — modern browsers throttle background tabs to save CPU and battery. During large transfers, keep the StreamSnatcher tab active and visible.
- Close heavy applications — free up CPU, RAM, and network bandwidth by closing video streaming, cloud sync, or other bandwidth-intensive applications during transfers.
- Disable interfering extensions — privacy-focused browser extensions that block WebRTC (for IP leak prevention) may prevent connections. Whitelist streamsnatcher.com if needed.
- For mobile: prevent sleep — disable auto-lock or keep the screen on during transfers to prevent the OS from suspending the browser process.
Troubleshooting
If you encounter issues, try these solutions in order:
- Peers can't connect — refresh both browser tabs and verify the room code matches exactly. Check that no browser extensions are blocking WebRTC connections.
- Connection established but no transfer — ensure both peers have the tab in the foreground and that the sender has dragged files into the upload zone.
- Slow transfer speeds — the connection may be routing through a TURN relay. Try switching to a less restrictive network (e.g., mobile hotspot) to establish a direct peer connection.
- Transfer interrupted — if a peer disconnects mid-transfer, the file will need to be resent from the beginning. Use a stable wired connection for large transfers.
- Network-specific issues — corporate, university, and some public networks actively block WebRTC traffic. If you consistently fail from one network, try a different connection.
If none of these steps resolve your issue, visit the Contact page and describe your browser version, operating system, network type, and the steps to reproduce the problem. You can also check the FAQ for answers to common questions.