Send to Device
Move a file between your own devices over your WiFi. It goes straight from one to the other — never uploaded, never stored, no account.
How to send a file between your devices
- 1
Open this page on the device that will receive
It shows a code straight away — Receive is where it starts. This is usually the laptop, because it is the easier place to put a file once it arrives.
- 2
Point the other device's camera at that code
The normal camera app is enough. The code is an ordinary link, so it simply opens this page on that device — nothing to install, and no permission to grant.
- 3
Choose the file to send
That device lands on the Send tab with the invitation already accepted. Pick a file and it shows a code of its own — the reply that finishes the introduction.
- 4
Show that second code back to the first device
Use its camera, or paste the code across if it has none. The two connect directly, the transfer starts by itself, and each device names the other so you can see you found the right one.
The file never goes up and comes back down
The usual way to get a photo off a phone is to send it somewhere else first. Mail it to yourself, drop it in cloud storage, paste it into a chat with yourself, upload it to a file-sharing site that gives you a link. Every one of those routes takes the same shape: the file climbs all the way out to a server and then comes all the way back down to a machine sitting on the same desk.
That round trip is the slow part, and it is the part that creates a copy you did not ask for. The upload runs at your connection's upload speed, which on most home lines is several times slower than the download — and when it finishes, your file is sitting on somebody else's disk, subject to their retention policy, their breach history, and whatever their terms say about scanning it.
This tool takes the short way. The two devices find each other on the network they are both already on, open an encrypted connection directly between themselves, and the bytes cross your router and nothing else. It is faster because a local network is faster than the internet, and it is private because there is no third machine involved to be private from.
Why two codes, and what is in them
Two devices that have never met cannot simply start talking. Each has to learn where the other can be reached and agree on keys to encrypt what follows. Normally a signalling server sits in the middle and passes those introductions along — which works, and which means a server that knows both devices exist and when they connected.
The codes replace that server with your eyes. The first one contains this device's addresses on the local network and its half of the encryption handshake, wrapped in an ordinary link so a camera app can open it. The second carries the same in reverse. Once both halves have crossed, the devices connect to each other directly and the codes are worthless — they describe a connection that already exists.
One detail is worth stating plainly, because it decides what this tool can and cannot do. The connection is set up with no STUN or TURN servers whatsoever, so your browser only ever advertises addresses on your local network. Nothing asks a third party what your public address is, and no relay exists that could carry the file. The price is that both devices must be on the same network — this cannot reach across the internet, and that limitation is the same decision as the privacy guarantee, not a separate shortcoming.
Frequently asked questions
No, and this is not a policy — it is how the tool is built. The two devices open a direct connection to each other and the bytes travel over that connection across your own network. There is no server in the path that could hold the file, which is also why we cannot offer a "resume later" or a download link: nothing exists anywhere except on your two devices.
None from us, because we never touch the file. In practice the limit is patience and the receiving device's memory — the file is reassembled in the browser before you save it, so something in the tens of gigabytes may struggle on a phone. Over a decent WiFi network the transfer runs at network speed, which is usually far quicker than uploading somewhere and downloading again.
Because introducing two devices takes a word from each of them. The first code carries an invitation that describes how to reach this device; the reply carries the same information back the other way, plus the keys that encrypt the connection. Neither side can guess the other's, so both have to travel. The first leg is a plain link, so a normal camera app handles it — only the reply needs reading back.
Almost always because the network will not let them. Public, hotel and guest WiFi commonly enable client isolation, which stops devices on the same network from talking to each other at all — it is a sensible default for a network full of strangers, and it defeats this tool completely. A home network or a phone hotspot will work. The two devices also have to be on the same network: this cannot reach across the internet, by design.
Yes. The connection uses DTLS, the same family of encryption as HTTPS, and the keys are exchanged in the two codes rather than through any server. Someone watching your WiFi sees an encrypted stream between two devices and not the contents.
Neither, deliberately. The connection is configured with no ICE servers at all, so your browser only ever offers the addresses your device holds on the local network. That means no third party is asked where you are, and there is no relay the file could pass through. The cost of that choice is the honest one: it only works between devices on the same network.
If you are in the same room and on the same network, yes — the tool does not know or care whose devices they are. Across the internet, no. That is a different tool with different problems: it would need servers to relay the bytes, which means storing other people's files, which without a sign-up is an abuse magnet. We would rather do the local case properly.
Reading a code needs a QR decoder, and Safari and Firefox do not yet provide the one built into the browser that Chrome and Edge do. Rather than make everyone download a decoding library for one step, the tool falls back to pasting the code across — every screen that asks for a scan also accepts a paste. The sending device never needs a scanner at all, because the invitation is an ordinary link its camera app already understands.
No. The connection closes when you leave the page and nothing is written to storage on either device beyond the file you chose to save. Reload and there is no history, no list of past transfers and nothing to clear.
AirDrop is better when both devices are Apple ones — it is built in and needs no codes. This works between anything with a modern browser, so a phone to a Windows laptop, an Android to a Mac, a work machine you cannot install software on. It is the fallback for when the built-in option does not cover both ends.
The Zeal Promise
Non-negotiable, on every tool we ship.
- No sign-up — ever
- No watermarks on any output
- No ads near the download button
- Works fully on mobile
- Privacy-first: processing stays in your browser
- Open source (MIT) — audit it, contribute, self-host
- Zero runtime dependencies in tool logic