file transfer
Send a file straight from one device to another. It goes browser to browser, so it is never uploaded, never stored, and there is nothing to delete afterwards.
- Read the codeSix digits and a QR square, on screen when the page loads.
- Enter it on the other deviceThe two browsers connect straight to each other.
- Drop the filesThey cross directly. Nothing passes through a server.
Enter this code on the other device
000 000
Open floi.dev/file-transfer/ there, or scan the square.
Waiting for the other device
or join with a code
Six digits from the device you want to reach.
Getting a code
One moment
Four digits derived from the connection keys. They should be the same on both devices.
Nothing sent yet
Drop a file anywhere here, or say something. Nothing you send passes through a server.
That did not work
How to send a file from one device to another
Open the page and read the code
It shows a six digit code and a QR square as soon as it loads. There is nothing to pick or set up first.
Enter that code on the other device
Scan the square with a phone camera, or open floi.dev/file-transfer/ there and type the six digits. The two browsers find each other and connect directly.
Drop the files
They cross straight between you and land in a conversation, with photos, audio and video shown in place. Either side can send, and the same box takes a message, an emoji or a recorded voice note.
What actually reaches a server, and what does not
Every other tool on floi runs start to finish inside your tab. This one cannot, and saying otherwise would be a lie the code does not support. So here is the exact shape of it.
Two browsers that have never met cannot open a connection to each other out of nothing. They have to swap a session description first: a few kilobytes listing the network addresses each one can be reached on and the public half of the keys the connection will be encrypted with. There is no browser feature that skips this step.
The six digit code opens a room that does exactly that swap. It holds two connections, copies one message to the other, and is destroyed when you both leave or after ten minutes. It does not read what it copies. It never receives a filename, a byte of a file, or a message, because those travel on the direct channel the handshake sets up, which the room is not part of.
Everything else on this site still runs with no server at all. The privacy page describes both cases and which pages are which.
Why it works when the same-network tools do not
The well known browser drop tools discover each other by noticing two devices arriving from the same public address. That is neat when it works, and it fails the moment your laptop is on the office Wi-Fi and your phone has fallen back to cellular, which is exactly when you reach for one.
Pairing on a typed code instead removes the assumption. The two browsers exchange every route they can be reached on and take whichever one works, so the devices do not need to share a network, a router, or an account.
The honest limit is that some networks refuse direct connections between machines outright. A relay server would fix that by carrying the file bytes itself, which is the single thing this tool promises not to do, so there is not one. When no direct path exists the tool says so and names the two things that work: put both devices on the same Wi-Fi, or turn on a phone hotspot and join it from the other device.
The safety code, and why nothing else shows you one
A six digit code is one guess. Whoever types it first is who you are connected to, and no amount of rate limiting changes that, because a single correct guess is already the whole compromise. What helps is making a wrong guess loud rather than rationing guesses, which is why a room here accepts exactly one second device and is then spent.
The other half is the four digits both screens show once you are connected. They are derived from the fingerprints of the certificates the connection is genuinely encrypted with. If the number on the phone matches the number on the laptop, the encrypted channel on one is the encrypted channel on the other. If they do not match, something is wrong and a fresh code costs you five seconds.
Size, and the difference between browsers
A transfer has to put the incoming bytes somewhere. Small files simply arrive, because asking twice to send a photo between your own two devices is the friction that sends people back to emailing themselves. Anything over 25 MB asks first. Over 256 MB the tool also asks where to save it, which is the only moment it can ask, because a browser opens a save dialog during a click and at no other time. From there Chrome and Edge write to disk as the data arrives, so the file never exists in memory as a whole and there is no practical ceiling.
Safari and Firefox have no equivalent, so a transfer there accumulates in memory and is saved when it completes. That is fine for a photo or a document and it will eventually kill the tab on a large video. The tool works out which of the two your browser is doing when the page loads and prints it under the drop area, rather than letting you find out at 90%.
Both pages have to stay open for the whole transfer, because the two tabs are the two ends of the connection. Nothing continues in the background, which is the trade for the file never being on a server in the first place.
Frequently asked questions
Does my file pass through a floi server?
No. The file goes straight from one browser to the other over an encrypted connection the two devices negotiate between themselves. It is not copied to a server on the way, and there is nothing to delete afterwards because nothing was ever kept.
One thing does reach a floi server, and it is worth naming precisely: the handshake. Before two browsers can talk directly they have to swap a few kilobytes describing their network addresses and their encryption keys. A short-lived room passes those two blobs between you and then closes. It never sees a filename, a byte of a file, or a message.
What is the largest file I can send?
On Chrome and Edge there is no limit we impose. The receiving browser writes each chunk straight to disk as it arrives, so a 50 GB file uses no more memory than a 50 MB one.
Safari and Firefox have no way to write to disk mid-transfer, so a file there is held in memory until it is complete. That works fine up to a gigabyte or two and then the tab runs out. The tool detects which of the two it is doing and says so on screen before you start.
It says this network will not allow a direct connection. Now what?
Two things fix it. Put both devices on the same Wi-Fi, or turn on a hotspot from one phone and join it from the other device. Either gives the two browsers a route to each other that the blocked network was refusing.
What has happened is that your network drops direct connections between machines, which corporate and university networks often do. Most tools would relay your file through a server at that point. This one will not, because that server would then have your file, so it stops and tells you instead.
What is the safety code for?
It tells you who you actually connected to. The room code is six digits, and whoever enters it first is who you are paired with, so in principle a very lucky guess could land on your transfer.
After connecting, both devices show the same four digits, derived from the encryption keys the connection is really using. If the number on your laptop matches the number on your phone, the encrypted channel on one screen is the encrypted channel on the other, and nobody is in the middle. If they differ, stop and start again with a new code.
Can I send more than one file, or send in both directions?
Yes to both. Drop as many files as you like and they queue up with their own progress bars. Once the link is up it is symmetric: whichever device you are looking at can send to the other, so you do not have to decide who the sender is before you start.
There is also a box for text, which is the fastest way to get a link or a snippet from a laptop onto a phone without emailing it to yourself.
Can I see a photo without downloading it first?
Yes. Anything the browser can render is rendered in the conversation: photos appear as photos, audio and video get a player, and a text or code file shows its first lines. Tap a photo to open it full size, and there is a Save button on everything.
Files over 256 MB are the exception. Those stream straight to disk as they arrive rather than being held in the page, which is what removes the size limit, and a file on disk is not something the conversation can show you.
Does it have a full screen mode?
Yes. The button in the top right of the conversation gives it the whole viewport, which is what you want once there is more than a couple of things in it. Escape, the Done button and the browser Back button all leave again, and nothing is lost either way because the connection is not touched.
How long does a code last?
Ten minutes, and it works once. As soon as a second device joins, the room is sealed and no third device can enter it. The room is destroyed when you both leave or when the ten minutes run out, whichever comes first.
That one-use rule is deliberate. A six digit code is only safe if a wrong guess burns it, because a correct guess would already be a full compromise. Rationing guesses instead would protect nothing.
Does the transfer keep going if I close the tab?
No. Both pages have to stay open, because the two tabs are the two ends of the connection. There is no copy on a server continuing in the background, which is the trade for the file never being on one.
If you need a file to arrive later, when the other person is not sitting there, this is the wrong tool and something that stores the file is the right one.
Is the transfer encrypted?
Yes. WebRTC data channels are encrypted with DTLS and that is not optional, so there is no unencrypted mode to accidentally end up in. The keys are generated by the two browsers and never leave them.
The safety code above is how you check that the keys in use are the ones you think they are.