Your file never reaches our servers
Most file-sharing services work in two hops: you upload to a company's
storage, then your recipient downloads from it. Your file sits on someone
else's disk in between — for minutes, or for years, depending on their
retention policy.
StreamSnatcher makes one hop. When both people have the session open,
their browsers negotiate a direct connection and the file moves across it
as a stream of chunks. Our server's only job is introduction: it passes
the two browsers the network details they need to find each other, then
stops being involved. There is no upload step because there is nowhere to
upload to. If we were served a demand for a file that moved through a
session, we would have nothing to hand over — not as a policy position,
but because no copy was ever made.
Encryption is not a feature bolted on top. WebRTC data channels are
encrypted with DTLS by specification, and a browser will not open one
that isn't. The keys are negotiated between the two browsers, so the
transfer is end-to-end encrypted by construction rather than by promise.
Sometimes a direct connection isn't possible
This is the honest limitation of peer-to-peer, and it is worth knowing
before you rely on it. Two browsers can usually find a path to each other
even through home routers. But some networks — corporate and campus
Wi-Fi, hotel connections, and mobile carriers using carrier-grade NAT —
are arranged so that no direct path exists at all. The technical name is
symmetric NAT, and retrying will not get through it.
When that happens the data has to travel through a relay server, which
costs real bandwidth to run and is the one part of this service that
isn't free. Before paying for it, the free fixes usually work: switch one
device to mobile data, put both devices on the same Wi-Fi, or try again
from a home connection. Any one of those typically restores a direct
path. We would rather tell you that than sell you a relay you didn't
need.
What "no storage" means day to day
The trade-off for storing nothing is that both people have to be present.
A transfer runs while both tabs are open; close one part-way and it
stops. There is nothing on a server to resume from, so it starts over
rather than picking up where it left off. A link you send today will not
deliver a file tomorrow unless you are both back at the same time.
That makes this a good fit for a large video you would rather not park in
someone's cloud, a document you don't want sitting in a third party's
retention window, or moving something between your own laptop and phone
without hunting for a cable. It is a poor fit for send-and-forget: if
your recipient is asleep in another timezone, use email or a cloud link
instead. Choosing the wrong tool for that case wastes your evening, and
we would rather you knew which one this is.
Practical notes before your first transfer
There is no file-size cap, because there is no storage quota to enforce.
What actually limits you is the slower of the two connections and, for
very large files, the receiving device's available memory — a phone with
little free space will struggle with a file a desktop handles easily.
Speed is your own upload rate, not a server's. Sending to two people at
once splits that rate between them, because the same file is being pushed
twice down one pipe. That is why adding peers makes each transfer slower
rather than faster.
Any current browser works — Chrome, Firefox, Safari and Edge all support
WebRTC data channels on desktop and mobile. No extension, no desktop
client, no account. If you want the protocol in more depth, our
guide to WebRTC file
transfer covers the mechanics, and
is WebRTC secure? works through the
threat model properly.