Send files from your browser

Open floe.one in any modern browser, pick your files, and send someone the link. There is nothing to install and no account to make. Your files go straight to the other device; they never sit on a server.

​

The short version

Drop your files on the card at floe.one, click Create secure link, and send that link to one person. The files start moving on their own once that person opens it. Keep the tab open until the status reads “All Files Sent!”. There is no Cancel button: to stop, close the tab.

​

Add your files

Drop files onto the dashed area inside the card, or click it to open the file picker. You can add one file or many, of any type. Drop them on the dashed area itself. A file dropped anywhere else, the rest of the card included, is refused, so your browser never opens it in place of Floe. Once something is queued, the large drop area shrinks to an Add more files strip above the list, and each row gets an X to remove it. A file added again is listed only once and sent only once. The strip and the X buttons disappear the moment you create the link, so settle on the list first. To change it afterward, reload the page and start again. The header above the list shows the count and the total size, such as “3 · 8.02 MB”. Floe sets no size limit on a direct connection, one that goes straight from your device to theirs. See File size limits for when a cap applies, and for what a browser on the receiving end can hold.

​

Drop a folder

This page has no folder picker, but you can drop a folder on it. Floe reads every file inside and lists each one by its path, such as photos/day1/b.txt. While it reads, Create secure link is off. Floe Desktop or the CLI on the other side rebuilds the folder, and a browser rebuilds it only inside Download ZIP. A drop with a folder in it is added whole or not at all:

• More than 10,000 files: “This drop has more than 10,000 files. Zip them first.”
• A file Floe cannot read: “Some files in this folder could not be read. Nothing was added.”
• A path too long to announce: “A file name or folder path is too long to send. Shorten it or zip it first.” See Limits.
• Empty folders are left out, and the page says “Empty folders are not sent.”

A browser that cannot read a folder’s contents refuses it at the drop with “This browser cannot send a folder. Add the files inside it, or zip it first.” Zip the folder first, or send it from Floe Desktop or the CLI. The page a request link opens takes folders too, with a folder picker: see Sending through a request link.

​

Decide whether the relay is allowed

Once at least one file is queued, a Network relay fallback checkbox appears above the send button. It lets Floe use a relay, a server that passes the encrypted data along, when the two devices cannot connect directly. Leave it on unless you have a specific reason not to.

• On, the default: Floe tries a direct connection first, and falls back to the encrypted relay only if that fails.
• Off: only a direct connection is accepted. If no direct path exists, the transfer fails.

Unchecking it shows an amber warning: “Relay fallback is disabled. Transfers may fail if either device is on mobile data or a restricted network and a direct connection cannot be established.” Turn it off only when you do not want Floe to use a relay, for compliance reasons for example. Your page then offers no relay of its own. If the connection still comes up relayed through the other side, your page closes it before any file moves and says “Connection failed. This link was made with Network relay fallback off. Reload the page, add the files again, leave it on, and share the new link.” It is not a guarantee: when your page cannot read which route the connection took, it lets the transfer go ahead. You do not need to turn it off to send more than 2 GB. The cap applies only when the connection actually ends up relayed, so leaving fallback on costs a direct transfer nothing. The checkbox disappears when you create the link, so set it before you click. The choice applies to this page only. It is not saved, so it is back on after a reload.

​

Create the link

Click Create secure link. The button carries the count, so it reads “Create secure link (3 files)”. The card reads “Creating secure link…” while Floe prepares the link. It appears as soon as Floe’s server, which only introduces the two devices, has your page in place, or after 3 seconds at most. If the badge at the top of the card says Offline at that moment, wait for it to read Ready before you share the link: nobody can reach you through it until then. The panel offers three ways to hand the transfer over:

• Copy puts the link on your clipboard. It turns into a green “Copied” for 2 seconds when the copy worked. If it does not change, the browser blocked the copy: select the link and copy it by hand.
• Show QR reveals a QR code captioned “Scan to receive files”. Point a phone camera at it to open the link there. Hide QR collapses it again. The page draws the code itself, so showing it sends the link nowhere.
• Share opens your device’s own share sheet, the menu of apps you can share to. It appears only in browsers that offer one. If the share sheet fails for any reason other than you closing it, the page copies the link instead.

Always share the whole link: it is what lets the other person in. It looks like https://www.floe.one/?s=8262e1b4#k=<link key>&room=<room id>. The room id is a long random code, and the link key is another that the other side uses to check your page. Your browser makes both, and they sit after the #. A browser leaves that part out when it requests a page, so they stay out of the web host’s logs and out of the address passed on to the next site you visit. Floe’s server does receive the room id, because joining the room is how the two devices find each other. It never receives the link key. The ?s= value is 8 random characters, digits and the letters a to f, that carry no information. They only make each link a distinct page, so a phone that already has Floe open does not reuse a stale tab. One link, one recipient at a time. While someone is connected, anyone else who opens the same link gets a “Link Invalid” card, so create a fresh link for each person. Opening a link does not use it up: a recipient who drops off can open it again from the same network. See How a transfer works. The link works for as long as this page stays open and connected to Floe’s server. See How long a code and a link last. The link is all that protects the transfer. Whoever opens it first gets the files, and this page does not ask you to approve them, so send it over a channel you trust. See Known limitations. The link key lets a receiver check your page. It does not let this page hold the receiver to it. This page stops on a proof that is wrong, and goes on when no proof comes, because floe receive before 1.12 and Floe Desktop before 1.1 have none to give. So a server that plays such a receiver gets the whole file, this page says the files were sent, and that server’s report can turn the check mark green. See What the link key checks.

​

Watch the connection

The top of the card shows the badge, a dot and a label. On the sending side only, a live ping sits beside it. Read the label, not just the dot. Two of the four states are green. Until someone connects, the badge only shows that your page can reach Floe’s server, so a green Ready does not mean anyone has joined. The status line under the share link is what tells you that: it reads “Waiting for peer”, then “Peer joined. Starting transfer”. When the other device disconnects, the badge goes back to Ready, whether the transfer finished or not. The ping is the time in milliseconds for a message to reach Floe’s server and come back, measured every 2 seconds. It is not the time to the other device. It reads -- while the page is not connected to the server. Hover or tap the info icon beside Direct or Relay for a short explanation of that route. The other two labels have no icon. On the home page, the Floe button in the top bar carries a small dot in the same color as the badge. Hover over it to read “Direct peer connection”, “Relay connection”, “Connected” or “Not connected”.

​

While it transfers

The transfer begins on its own as soon as the two devices actually connect. On a fast network that is a moment after they open the link. On a slow or relayed one the connection itself takes longer. If you turned relay fallback off or queued more than 2 GB, the route decides whether the transfer may start, so it begins about 2 seconds after the connection instead. There is nothing to click. Before it sends anything, Floe checks whether the connection is direct or relayed. Two results stop the transfer before any file moves:

• You turned relay fallback off, and the only path is relayed. The card’s message begins Connection failed. This link was made with Network relay fallback off. and the connection is closed.
• The route is relayed, and your files total more than 2 GB. The status line reads Transfer blocked. Relay limit exceeded. and an amber notice explains the cap. The header above the list adds the cap, such as “3 · 2.5 GB / 2 GB”, in amber.

Either way, reload the page and add your files again. For the cap, send 2 GB or less, or send from a network that allows a direct connection. Once it is running, three things show progress:

• The status line under the link reads “Sending:” and the name of the current file.
• A progress row reads, for example, “Sending file 2 of 3…”, then the speed and time left, such as “4.2 MB/s · 1m 12s”, then a percentage. The percentage is for the current file only, so it starts again at 0 for each file.
• Each file row gets a green check once that file has left your browser, and a spinner while it is the one moving.

Three things can stop a running transfer from your side:

• A file you queued can no longer be read, because it was moved, renamed, or on a drive that went away. Floe stops at that file and names it. See Troubleshooting.
• The other side does not accept a file within 2 minutes. The card shows Transfer timed out waiting for receiver. Please try again.
• The other side’s proof of the link key is wrong. The card shows “Floe couldn’t confirm the person who opened your link, so nothing was sent. Make a new link and send it again.” The link stops working, and the message stays until you reload.

When your page stops by itself, it tells the other side why and closes the connection. The rows before the file that stopped keep their checks, so you can see which files still have to go. There is no Cancel or Stop button. To stop a transfer, close or reload the tab. The other side then sees the transfer end, with no reason given. Once the link exists, the line at the foot of the card turns amber and reads “Keep this tab open and in front. Closing it cancels the transfer.” Chrome and Edge can unload a tab in the background to save memory, and that ends the send as closing it would. For as long as your browser would ask before you leave, the page does not reload by itself either. When Floe’s web app is updated while you send, the page keeps the version it loaded until the send ends. See The page reloaded by itself. A link from floe or Floe Desktop opened in this tab gets your browser’s question about leaving if you have clicked on the page. If you have not, the page opens it once the send ends. From the moment the other person joins until the send ends, the page asks your browser to keep the screen on, where the browser supports it. Browsers let go of that whenever the tab is hidden, and the page asks again when you come back. On mobile, the browser may also give a tab in the background less time to run, which slows the transfer down. Keeping the screen on does not keep a laptop awake. Closing its lid usually puts it to sleep, and that ends the send. See A device that sleeps ends the transfer for what each side sees and what to do.

​

When it finishes

The status line under the link gets a gray check mark and reads “All Files Sent!”. That means every byte has left this browser. It is not the other side’s confirmation, because a browser sender does not wait for one. The check mark and the status turn green when the receiving app reports that every file matched (the SHA-256 matched mark). That report usually lands a moment after “All Files Sent!”. The match is against the SHA-256 your browser worked out for each file, a fingerprint of its contents. The floe CLI, Floe Desktop and a receiving browser all send that report, so the check mark can turn green when you send to another browser too, and that page shows its own. A check mark that stays gray means the receiver did not report a match for every file, for example an older app that checks sizes only. See File checks. After the other side disconnects, the status may change to “Transfer complete”, which is the same result. If their device drops off the network without closing the connection, the status can change to “Connection interrupted” instead, although every byte had already left this browser. Either way the file rows keep their check marks, and the progress row still reads “Sent 3 files” with your own number. “Transfer complete” keeps the check mark the status had. “Connection interrupted” has no check mark, so a green one goes with the status it was beside, although the receiver’s report still stands. This is what the web app at floe.one shows. A web app that someone hosts themselves can run an older version, where a few of these lines read differently: see What an older web app shows. If the receiving side discards a file because it did not match, the status reads “Transfer failed”, even when “All Files Sent!” was already showing. The card says “The other side discarded a file that did not match what was sent. Try sending again.” See Troubleshooting. If the other side is floe receive and the person there answers no at its Accept? [Y/n] prompt, the status reads “Transfer failed” and the card says “receiver declined the transfer”. floe receive 1.11.0 and earlier close the connection without a reason instead. The file list stays locked after a transfer, and the link stays on screen. After a finished transfer the link can still be used. If the recipient closes their page and opens the link again from the same network, Floe sends every file again, and the check marks clear and come back as it does. If your own device slept or lost its network partway through, do not count on the link: see A device that sleeps ends the transfer. To send to someone else, or to be sure the link works, reload the page and create a new link. The old link stops working, with no message on this page, if the page lost its connection to Floe’s server after the transfer and reconnected. A browser that opens it then reads “The sender is not connected”: see Troubleshooting.

​

What the other person sees

What happens on their side depends on what they open the link with:

• A browser: the page joins by itself, and the files arrive with a download button on each row. They save the files from there. See Receive files in your browser.
• Floe Desktop: they paste the link into the Receive tab, and the files are saved straight to the folder they chose. See Receive files in the desktop app.
• The floe CLI: floe receive asks them to accept first, unless they passed -y. If they answer no, nothing is sent and your page shows an error. See floe receive.

When your page stops a transfer by itself, their page or app shows the reason. For example, a browser receiver reads “The sender stopped: a file could not be read on their device. Ask them to check it and send again.”

​

Room codes are not a browser feature

The web app never makes a room code, the three words such as olive-tiger-castle that floe send and Floe Desktop show. It has no field to type one into either, so a browser recipient always needs the full link or the QR code. If you want a code, send from the terminal or from Floe Desktop. See Mixing them.

​

If something goes wrong

• The status stays on “Waiting for peer” after they opened the link: see The transfer never starts.
• The status reads “Reconnecting to your link”: see Reconnecting to your link.
• “The connection closed before the transfer finished.”: see Troubleshooting.
• “Floe couldn’t confirm the person who opened your link”, “The other side couldn’t confirm this link”, or “This browser can’t check this link”: see Troubleshooting.