Send files from phone to PC without an app
The QR pairing flow step by step, with no cable and nothing to install.
Real-Time WebRTC Peer Transfer
Send files directly
between devices.
No cloud hosting. No file data stored. Just pure, end-to-end encrypted peer-to-peer transfer.
Verifiable build·check the code yourselfCapabilities
Direct Transfer Highlights
01REAL-TIME
Direct WebRTC Stream
The receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device. It then streams over a direct WebRTC data channel between your devices, with no cloud storage in between.
Device-to-Device
02REAL-TIME
0 Bytes of Your File
Files move in real time and are never written to our storage. Larger ones go straight between the two devices; smaller ones and blocked connections pass through our relay as ciphertext we hold no key for.
No File Payload Stored
03REAL-TIME
Pair With a Short Code
The receiver opens Receive and gets a short room code and QR code. The sender scans it, or enters the code on the Send page, and pairing is instant — no account either side.
Instant Room Code
How It Works
Send a File in Three Steps
No app, no account, no upload. Two browsers, one short code.
STEP 1
Open Receive on the device that gets the file
It shows a short room code and a QR code. Nothing is uploaded, and no account or email is asked for on either side.
STEP 2
Pair from the sending device
Scan the QR code with a phone camera, or type the code into the Send page. The two browsers find each other in a second or two.
STEP 3
Approve, then the file streams across
The receiver sees the file name and size and approves it before a single byte moves. It is encrypted on the sending device and saved on the receiving one.
Under the Hood
Where Your File Actually Goes
What peer-to-peer means here
Most ways of sending a file make two journeys: up to someone's server, then back down to the recipient. A direct transfer makes one. The file goes from the browser on one device to the browser on the other, and is never written to storage along the way.
That changes three things at once. There is no upload to wait for before the other person can start receiving. There is no copy left sitting on a server after you are done. And there is no storage quota to run into, because nothing is stored.
Three routes, one layer of encryption
When the two devices can reach each other, larger files travel over a direct WebRTC data channel between them — the one route where your file data never touches our infrastructure at all. Setting that channel up takes a moment, so small files skip it and go through our socket relay instead: the setup would take longer than the transfer.
Corporate firewalls and some mobile carriers block a straight route between devices. Some peer connections cannot find a direct route and are relayed by our TURN server instead. It forwards packets that are already encrypted twice over — your AES-GCM ciphertext inside the connection's own DTLS — and holds no key for either layer.
If no peer connection can be made at all, the socket relay is the last resort. Chunks are relayed through our server when a direct connection is impossible, and for small transfers where negotiating one would take longer than sending the file — still as ciphertext we hold no key for. The relay is a bridge, not a reader.
Whichever route is taken, the encryption described below happens on the sending device before the data leaves it. The route decides how the bytes travel, not whether they are protected.
How the file is encrypted
The receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device.
The private key is generated inside the receiving browser, is non-extractable, and is destroyed when the tab closes. It is never transmitted.
Each chunk carries a GCM authentication tag with its sequence number authenticated alongside it, and a SHA-256 hash of the whole file is verified on arrival.
Checking you are sending to the right device
Both devices display a fingerprint of the public key each is actually using, as 8 emoji and 12 hex characters. Comparing them rules out a substituted key — the one attack encryption alone cannot prevent. If the codes on the two screens match, nobody has slipped their own key into the middle of the connection.
What this cannot promise
That holds as long as the code running in your browser is the code we describe. For the encryption itself you no longer have to take that on trust: it is served as a published build you can reproduce byte for byte and compare against what your browser loaded. What remains is the application around it, which is closed source — it is what hands your file and your password to that code, and nothing here proves it does not read them first.
The security page sets out the full architecture, including what you can check for yourself without trusting us.
Is It Right For You
When to Use a Direct Transfer
A good fit when…
- Moving files between your own devices. Phone to laptop, old PC to new one, tablet to desktop — whatever the operating systems.
- A large file for someone you are talking to now. They receive it as it sends, instead of waiting for an upload to finish first.
- Files you would rather not store anywhere. Contracts, ID scans and unreleased work leave nothing behind on a server afterwards.
- A borrowed or locked-down computer. It runs in the browser, so there is nothing to install and nothing to sign into.
Use something else when…
- The other person is not online right now. A direct transfer needs both browsers open at once. A link they can open later suits this better: Cloud Share
- Several people need the same file over days. Upload it once and share one link rather than running a transfer per person.
- One file is larger than 1 GB. Split it into parts first, or export a smaller copy for the transfer.
- You need someone to send a file to you. Give them a link they can upload to instead: File Requests
Compared
Direct Transfer vs the Usual Options
The common ways to move a file from one device to another, compared on what they store and what they ask of you.
| Direct transfer | Cloud link | Email attachment | USB cable | |
|---|---|---|---|---|
| Stored on a server | Never | Until the link expires | In both mailboxes, indefinitely | No |
| Largest file | Up to 1 GB | Per-upload limit, shown as you add files | Around 25 MB | Free space on the drive |
| Both people present | Yes, at the same time | No | No | Same room |
| Install or sign-up | Neither | Email verified once | An email account | A cable, sometimes drivers |
| Encryption | AES-256-GCM per chunk, key wrapped with RSA-2048 | Optional, with a password | Usually in transit only | None |
| Works across platforms | Any modern browser | Any modern browser | Yes | Often awkward, e.g. iPhone to Windows |
FAQ
Direct Transfer Questions
Open the Receive page on the device that should get the file and it shows a room code and a QR code. On the sending device, scan the code or type it into the Send page, choose the file, and the receiver approves it. The file then streams from one browser straight to the other, with no upload step and no copy left on a server.
It is as safe as its encryption and its pairing. Here, the receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device. The safety code shown on both screens lets you confirm you are connected to the right device.
Yes. Nothing is stored in between, so the file has nowhere to wait — both browsers need to be open until it finishes. If the other person will open it later, send a cloud link instead.
Sometimes, but only as ciphertext, and it is never written to storage. When the two devices can reach each other, larger files go straight between them and never touch our infrastructure. If a network blocks that route, the connection is relayed through our TURN server; small files, and connections that cannot be made at all, go through our socket relay. On every route the data is encrypted before it leaves the sending device, so anything passing through us is ciphertext we hold no key for.
Up to 1 GB per file. For anything larger, split it into parts or send a compressed copy.
No. A direct transfer works across different networks, including mobile data, and is usually just as fast as being on the same Wi-Fi — what actually matters is whether the two devices can connect directly at all. Mobile data and heavily restricted networks are the ones most likely to block that and fall back to our relay, which is slower.
Yes. It runs in any modern browser — Safari, Chrome, Edge or Firefox — so any pair of devices works, including combinations that AirDrop and Quick Share do not support.
Short interruptions are handled: both sides wait for the other to reconnect, and the receiver asks for any chunks it missed. If a tab is closed, the transfer ends and has to be started again.
The file's contents are never stored or logged. Non-content details are — the file name, size and type, timestamps, which route it took, and each side's IP address and browser — for rate limiting and abuse prevention. The privacy policy lists all of it.
Guides
Go Deeper
An AirDrop alternative for Android and Windows
Transfer between iPhone, Android, Windows and Mac in any combination.
Transfer files between two computers
Laptop to laptop without a USB drive, a network share or a cloud upload.
Send large video files at full quality
Why messaging apps shrink your video, and how to send the original.
How end-to-end encrypted transfer works
The key exchange, the cipher and the safety code, in plain English.
Share files without cloud storage
What zero-cloud transfer actually means, and where it falls short.
For the full cryptography behind direct transfers, see the security architecture page, or compare every mode on how it works.