Your file never touches our server
Most services say something like this and mean "we delete it afterwards". This one means the file goes from your browser to theirs and there is no copy in between to delete — not on a disk, not in a bucket, not for a moment.
A link, then a direct connection
You pick a file and get a link. When they open it, the two browsers negotiate a direct connection and the file streams across it in chunks. The messaging service is used to introduce the two of you and to carry the progress — never the contents.
- The transfer key lives in the hash of the link, not the query — a query string travels in Referer headers and server logs.
- The data channel is opened reliable and ordered. The library's default is neither, and a file sent over the default arrives the right size and the wrong content with nothing reporting an error.
- Sending pauses when the send buffer is deep and resumes when it drains, so a multi-gigabyte file does not queue itself into memory and kill the tab.
- The file is hashed before it leaves and again when it lands. A transfer that does not match is refused, not saved with a warning — otherwise the check is decoration.
Nadia Osei Photography
sent you a file
┌────────────────────────────────┐
│ 📄 site-photography-final.zip │
│ 840 MB · direct from them │
└────────────────────────────────┘
[ Receive file ]
Keep this tab open while it arrives.
─────────────────────────────────
Send files this privately, with
your name up there → Try Drop Pro
Free is useful; Pro is branded
The transfer engine is the same on both. What Pro buys is the size ceiling coming off and the download page carrying your name instead of nobody's.
Experimental direct transfer — what that means here
Drop Pro moves a file straight between two browsers. It is deliberately labelled experimental direct transfer rather than a general way to move materials around, and the reason is in the engine rather than the policy: a file being received is assembled in memory, and the digest that proves it arrived intact reads the whole thing at once. There is no streaming to disk and no resume — a connection that drops starts again from nothing.
So the ceiling is not a tier. The receiving side refuses anything over 1.5 GB before it starts, because the alternative is a tab that dies three quarters of the way through somebody's afternoon. Raising it is not a setting: it needs incremental hashing, disk-backed receiving, resume and multi-file manifests, and until those exist the durable path for files that matter is an ordinary attachment.
Where the plan is actually enforced — an honest note
Today the size ceiling is a check in the browser, and a check in the browser is a product decision rather than a security boundary: anyone can edit it in their own dev tools. That is fine for what it is — a line between two tiers of a tool, not a lock on somebody else's data — but it should not be described as more than it is.
Enforcing it properly means putting the quota on the API key in the messaging service, next to the rest of the metering. The transfer engine underneath does not know which plan is in force and does not need to, which is the right way round: the policy can move without the engine changing.
What it is not
Not a mailbox. Both browsers have to be open at the same time, because there is no copy waiting anywhere — that is the whole premise. If you want to leave something for somebody to collect tomorrow, that is a different shape and it exists: Dead Drop stores an encrypted blob in a channel for exactly that reason.
And it is one file at a time today. Folder transfer is on the Pro list and is not built yet; saying otherwise on a pricing page would be the easiest lie on this site to tell.
What it costs
Free — nothing is stored, so nothing costs us to keep
Free. Nothing is stored, so nothing costs us to keep — the channel introduces the two browsers and the bytes go straight between them.
The Free / Pro split on this page is a shape, not a price list: those numbers are suggested rather than market-tested, and nothing charges for them today.
The part that matters, in the open
The file is sliced in the browser and each slice goes straight down the data channel. No copy is uploaded anywhere.
var i = row.sent;
row.file.slice(i * CHUNK, (i + 1) * CHUNK).arrayBuffer().then(function (buf) {
try {
dc.send(buf);
} catch (e) {
self.s.emit('failed', { row: row, why: e.message });Taken from this app's source, not written for the page. Built on the Messaging Platform SDK.