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.
Pick what to send, then pair the other device.
Drop files or a folder here, or browse
Any file type, any size — they never leave your device until the other side accepts
Scan this
Scan it with the other device
Type this code
at tools.aliontechstudio.com/file-transfer
Or scan the sender's QR code with your camera — it opens this page with the code already filled in. You can also paste the whole link here.
Incoming transfer
Chrome won't let a website save straight into Desktop, Downloads or Documents themselves — pick or create a folder inside one. A ZIP can be saved anywhere.
Received files
On a phone, Save to gallery opens your share sheet — pick “Save Image” or “Save Video” to put it in Photos.
🔒 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 disk — one file to wherever you save it, several files either into a folder you pick or as a single ZIP you can save anywhere — so free space is the only limit. Firefox, Safari and Chrome on Android stream it to the browser's own on-disk storage instead and hand you the finished file at the end — also limited by free space, not by memory. Only a browser with neither falls back to holding the transfer in RAM, and that is the one case where a size warning still appears.
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.
Yes — drag the folder onto the box. It's packed into a single .zip as it sends, so the other side gets one file with the folder structure intact. Nothing is zipped up front: the archive is built while it streams, so a folder is no harder on memory than a single large file.
Not a meaningful one. The archive is written in Zip64 format, which drops the old 4 GB and 65,535-file ceilings a plain zip has — individual files inside can be larger than 4 GB and the finished archive can be any size. The only cap left is 200,000 files in one folder, which is about where the browser itself starts to struggle rather than anything to do with the zip.
Yes. Paste anything the sending device gave you into the code box — the full https://…/file-transfer/#r=ABC123 link, the link without the scheme, or just the six characters — and the code is pulled out of it. Spaces and dashes are ignored too, so ABC 123 and ABC-123 both work. Scanning the QR code opens this page with the code already filled in.
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.
Not yet — you start the transfer again. It is worth knowing that this is not a connection fault: the link was working, which is how the bytes that did arrive got there. A closed lid, a locked phone, a tab swiped away or a walk out of Wi-Fi range all end the session the same way, and none of them mean anything is wrong with your network, so changing Wi-Fi will not help. Because the bytes travel directly between the two browsers, there is no half-finished copy sitting on a server to resume from — the partial file on the receiving side is discarded rather than left looking complete. Keep both tabs open and both screens awake for large transfers; on a phone, that means not letting it lock.