Send files straight from one device to another — phone to laptop, laptop to phone, across the room or across the world. Scan a QR code or type a six-character code, and the file goes direct. No upload, no size limit, no account.
Drop files here or browse
Any file type, any size — they never leave your device until the other side accepts
Scan with the other device's camera
Or enter this code at tools.aliontechstudio.com/file-transfer
Scanning the sender's QR code with your camera opens this page with the code already filled in.
Incoming transfer
Received files
🔒 Files go directly between the two devices over an encrypted connection. We never receive them — our server only passes the two devices a few kilobytes of connection details, and is told nothing but how many files and how many bytes.
Move a video off your phone without a cable, an app, or emailing it to yourself. Scan, accept, done.
No 25 MB attachment ceiling and no upload quota, because nothing is stored anywhere along the way.
Contracts, medical scans, ID photos, raw footage — the bytes go device to device and never sit on anyone's server.
Most "send a big file" services are storage lockers. Your file is uploaded to a server, parked there for a few days, and the recipient downloads a copy. That model is why they have size caps, expiry dates, paid tiers and privacy policies — storing and moving other people's data costs real money, so it has to be rationed.
This tool does something different. It opens a direct connection between the two browsers using WebRTC, the same technology behind video calls, and pushes the file down that connection as a stream of chunks. There is no copy on a server because there is no server in the path at all.
What our side does provide is introduction. Two browsers cannot find each other on the open internet unaided — each needs to learn the other's network address and encryption parameters. So the sender writes a small description of itself into a temporary pairing room, and the receiver, armed with the six-character code, reads it and writes back its own. That exchange is a few kilobytes of connection metadata. The moment the two are talking directly, the room is deleted.
Because the connection is live, both devices have to be present at the same time. This is the one real trade-off of the peer-to-peer approach, and it is worth being plain about: you cannot queue a file up on Monday for someone to collect on Wednesday. There is nowhere for it to wait.
So expiry here means something narrower than it does on an upload service. It is the pairing code that expires, after ten minutes, not a stored file. The code also stops working the instant somebody uses it, which closes the window in which a guessed code could be redeemed. Six characters drawn from a 32-symbol alphabet gives just over a billion combinations, and a given code is alive for only a few minutes.
Keeping the sending tab open is the other requirement. Closing it tears down the connection mid-stream, which is why the page warns you before you navigate away.
Two devices behind ordinary home routers can almost always reach each other, using a technique called hole punching: both make outbound connections that their routers then allow replies through. A helper server known as STUN tells each device what its address looks like from outside, which is all the information the technique needs.
Some networks defeat this. Symmetric NAT, which assigns a different external port for every destination, makes the address unpredictable. Strict corporate and university firewalls sometimes block the traffic outright, as do a few mobile carriers. In those cases the usual industry fix is a TURN relay — a server that both devices connect to, which forwards the data between them.
We deliberately do not do that, because a relay would carry every byte of your file through somebody else's machine, which is exactly the thing this tool exists to avoid. A failed connection here is an honest failure rather than a quiet upload. The reliable workaround is to put both devices on the same Wi-Fi network, where a direct connection nearly always succeeds. If you only need a small file moved and the network refuses to cooperate, encoding it another way — as a Base64 string, or into a QR code — is sometimes the quicker route.
No. They travel directly between the two browsers over an encrypted connection. Our server only helps the devices find each other, and all it ever sees is a file count and a byte total — never a filename, never any content.
No. On Chrome and Edge the file is streamed straight to your disk as it arrives, so free space is the only limit. Firefox and Safari hold it in memory instead, which is comfortable up to roughly a gigabyte.
Yes — this is a live connection, not a storage locker. The sending tab has to stay open until the transfer finishes.
Ten minutes, and it stops working as soon as it's used. If nobody connects in time, just create a new one.
Yes. WebRTC data channels use DTLS encryption negotiated directly between the two browsers, so nobody in between can read the bytes.
Some corporate, university and mobile-carrier networks block direct device-to-device connections. We don't fall back to relaying your file through a server, because that would mean uploading it after all. Putting both devices on the same Wi-Fi almost always fixes it.
Select multiple files and they're sent one after another. On Chrome and Edge you'll be asked to pick a destination folder, and each file is written into it as it arrives.
Yes. Any two modern browsers can pair — Android to Windows, iPhone to Mac, Linux to anything. There's nothing to install on either side.
Once the two devices connect, both show a four-character safety code derived from the encryption keys the browsers negotiated with each other. If the codes match, the two screens really are the two ends of the same encrypted connection and nobody has slipped in between. It's the same idea as a safety number in a messaging app — worth a glance when you're sending something sensitive.