Device to device, no cloud copy
Bytes travel over an encrypted WebRTC data channel straight to the other browser. There is no upload step and no BurnTlk bucket holding your files.
How BurnDrop works
Files go device to device.
Then they’re gone.
BurnDrop streams files browser to browser over an encrypted connection. Nothing is uploaded to a cloud bucket, both sides watch the same progress, and Burn wipes it all when you are done.
Peer to peer. No cloud. Files disappear.
Three steps
Send something in under a minute
- Step 1
Pick your files
Open the Send tab, then drop files anywhere on the page or tap to browse. On desktop and tablet you can add a whole folder — its structure comes along.
- Step 2
Share the code, link, or QR
Every drop gets a 5-character transfer code and a link. Read the code aloud, send the link, show the QR, or tap a device that is already on your network.
- Step 3
Watch it land, then Burn
Files stream device to device with per-file progress. When you are done, Burn ends the session for both sides and wipes what the browsers were holding.
Either side can start
Have files? Want files? Both work.
Send tab — you have the files
Add files and BurnDrop hosts a room with a transfer code. Share the code, the link, or the QR under Share invite. The other person enters the code on the Receive tab or opens the link, and the queue starts moving the moment they connect.
Or share a transfer code
Receive tab — you want the files
Open the Receive tab and BurnDrop makes a receive link for your browser. Send it to whoever has the files; when they open it they see a drop zone and their files stream straight to you. The same tab also takes a sender’s code if they started first.
Everything Drop can do
Small app. Stubborn about finishing.
Code, link, QR — or a receive link
Senders share a code. Receivers can flip it: the Receive tab mints a receive link, and whoever opens it drops files straight into your browser.
Nearby on the same network
Two BurnDrop tabs behind the same public IP see each other by a throwaway name. Tap, accept, connected — no code to type.
Direct or Relayed, shown honestly
Each moving file says whether it found a direct path or is going through a relay. Same WiFi is usually Direct; some networks force a relay.
Multi-file queue
Queue as many files as you like. Each row has its own progress and ✕ to cancel just that file; a summary line tracks the whole batch.
Folders with their paths
Add folder (or drag one in) keeps relative paths, so the receiver sees where each file belongs. Browsers cannot save a folder in one go, so files save one at a time.
Resume — even after a reload
A blip pauses the row instead of failing it. Reload or lose the tab and the partial download is kept; reconnect with the same code and it picks up where it stopped.
Built for phones and Safari
The screen stays awake while files move, and if your device paused the tab you get a plain-language note about how to resume.
Notices when the other side vanished
A killed tab sends no goodbye. BurnDrop spots the silence, pauses the transfer, keeps the room code, and welcomes the same device back.
What you’ll see
The screens, before you need them
A queue, one row per file
Folder paths sit above the name. The ✕ cancels one file without touching the rest; the line on top sums up the batch.
Paused, not failed
After a reload the receiver keeps its partial file and offers Reconnect & resume. Only the missing part is sent again.
Direct or Relayed
The path label lives in each file’s meta line, so you know why a transfer feels the way it does.
Nearby, no code needed
Names are made up per tab and forgotten when it closes. Nothing moves until someone accepts and drops a file.
Connected header on a phone
While bytes move, BurnDrop asks the browser to keep the screen on and says so. Burn is one tap and ends the session on both devices.
Good to know
The honest fine print
Speed is your network’s speed.
There is no server in the middle to slow you down, but there is none to speed you up either. Same WiFi is usually the fastest path; relayed transfers are slower.
Both tabs need to stay open and in front.
Browsers pause background tabs within seconds. The wake lock keeps your screen on; it does not run a transfer in the background.
What our servers see.
A signaling server helps the two browsers find each other. When a direct path fails, a relay forwards the encrypted packets — it cannot read them. File bytes are never stored on either.
Where a partial download lives.
Unfinished downloads sit in your browser’s private storage for this site so a reload can resume them. Burn or Remove deletes them; anything older than 12 hours is cleared on the next visit.
Receive links are role markers, not passwords.
The #s= part of a receive link tells BurnDrop who is sending and never leaves your browser. Share codes and links only with people you want to receive from.
No file-size quota, but no magic.
There is no upload cap because there is no upload. Very large files still depend on your connection holding and on free storage on the receiving device.
Looking for the chat? See how BurnTlk works