How to send a whole folder, not just files

Last updated: 2026-08-05

Sending a project isn't the same as sending a file — you have a folder full of subfolders, and copy-pasting each piece individually loses the structure that makes it useful. Zipping it first works, but it means a detour through a compression tool before you can even start.

Relayium lets you pick a folder and send it as-is on a realtime transfer. The browser walks the whole tree, keeps every relative path intact, and streams it live — direct over WebRTC on the same LAN, or as end-to-end ciphertext over TURN across networks — without a server-side realtime copy or history. A stored link you leave for later is the one route that does not carry a tree: archive the folder yourself and upload that single file instead.

Pick a folder, not a pile of files

What you need

A desktop browser on the sending side — Chrome, Edge or Firefox. Safari's file picker on iPhone and iPad cannot select a folder at all, only individual files, so a folder send starts from a computer.
A tree of at most 1,000 files. That cap is per batch rather than per session, so a larger tree goes over in several sends without reconnecting.
A decision about the receiving browser, because it decides the shape of what arrives: Chrome or Edge writes the tree into a folder the recipient picks, and every other browser produces one .zip instead.
Both sides online together for a realtime send, or — when the other person is not around — a signed-in sender plus an archive you made yourself, because a stored link uploads a flat list of files and carries no directory tree.

Instead of selecting files one by one, choose the folder itself. Relayium walks the directory tree in the browser and keeps every file's relative path — subfolders, nested subfolders, all of it — so what arrives on the other end has the same layout you started with.

This works today in desktop Chrome, Edge, and Firefox. It doesn't work on iOS: Safari's file picker on iPhone and iPad has no way to select a folder, only individual files, so folder sending is a desktop feature for now.

Open the transfer page on the sending computer — the same-network page if you are on one network, the realtime page if you need a pairing code.
```
https://relayium.com/
```
Drag the folder onto the page, or use the folder picker button. Relayium walks the tree in the browser and keeps each file's relative path, so nothing has to be zipped first.
On the same network, find the recipient under “Nearby devices” and press “Open workspace” on their card, then use the “Send a folder” attachment inside the workspace. Across networks it is the same one action: join the pairing-code room and press “Open workspace” on the peer card there. Either way, the request that arrives on the other side states the file count and the total size of the whole tree, not of one file.
On the receiving side, read the line under the request before accepting: in Chrome or Edge it says the browser will ask where to save, which is the path that reproduces the folder on disk. Then press “Accept”.
Watch the file counter climb through the tree on both screens. It counts files, so a folder of 300 files reaches File 300/300 rather than showing one progress bar for the batch.
```
File 300/300
```

What a finished folder send looks like

The counter ends on the last file of the batch, and each file arrived with its own SHA-256 hash checked end to end, so what landed matches what you sent byte for byte.

Then look at the result rather than the page, because it differs by browser: in Chrome or Edge the tree is inside the folder you picked, subfolders and all, and in Firefox or Safari there is a single .zip in the downloads list that unpacks to the same structure.

LAN direct
File 300/300

What the other person gets

How the folder arrives depends on the receiving browser. Chrome and Edge can write files straight into a directory the recipient chooses, so the folder shows up on disk exactly as it left — no extra step.

Firefox and Safari don't have that capability, so instead they receive one store-only .zip archive that unpacks to the exact same folder structure. It stays under 4 GiB (no ZIP64 support), which covers the vast majority of project folders and photo or document sets — for anything bigger, split into two sends.

Symptom, check, fix

There is no way to pick a folder on the sending device at all.

https://relayium.com/   # the picker offers a folder only where the browser supports one

You are almost certainly on iPhone or iPad, where Safari's picker exposes individual files and nothing else. Start the folder send from a desktop Chrome, Edge or Firefox, and use the phone as the receiving side instead.

The .zip that arrived is corrupt, or the download stopped near 4 GiB.

chrome://downloads   # compare the .zip size against the folder you sent

The archive path has no ZIP64, so both a single entry and the whole archive have to stay under 4 GiB. Split the tree into two sends, or have the recipient use Chrome or Edge, which writes the files into a chosen folder and never builds an archive at all.

The .zip is the same size as the folder, with no compression at all.

chrome://downloads   # the entry's size matches the folder's total, not less

That is expected: the archive is store-only, so it packages the tree without compressing it and stays byte-identical to what you sent. Compress the folder yourself before sending if size on the wire matters more than an exact copy.

The files arrived but they are all loose in one folder, with the subfolders gone.

chrome://downloads   # a browser without the directory picker hands over one .zip

Relative paths survive a realtime send, so this is what a .zip looks like before it is unpacked rather than a flattened transfer. Unpack the archive and the subfolders are there; to land the tree directly on disk, receive it in Chrome or Edge and pick a target folder when asked. A stored download link is the one route that really is flat — it uploads a plain list of files and drops the paths — which is why a folder meant for a link has to be archived first.

A folder of a few hundred files stops part way with one file missing.

https://relayium.com/   # the counter names the file it stopped on

A realtime send is one live session, and a temporary drop can pick up again from the last durable checkpoint as long as both pages stay open. Closing or reloading either one ends the session, and then there is nothing left to resume. Keep both tabs open and give it a moment before touching anything; only if the session is really gone, resend the batch from the file the counter named. For delivery with nobody on the other side, zip the folder yourself first and upload that one archive as a stored link, because a stored upload takes a flat file list.

Realtime, or a link for later

If you can both be online at the same time, send the folder in realtime. On the same LAN, WebRTC connects directly; across networks, the browser uses TURN by design to carry end-to-end encrypted ciphertext that the relay cannot read or decrypt. Relayium keeps no server-side realtime copy or transfer history. Same-network transfer needs no account; across networks the pairing-code creator signs in, while the person joining never needs an account.

If the other person isn't around right now, create a stored link instead — but archive the folder yourself first. A stored upload receives a flat list of files: the relative paths are dropped, so a tree uploaded directly arrives as loose files, and two same-named files from different subfolders collide. Make an ordinary .zip and upload that single file, and the structure travels inside the archive. Your browser encrypts whatever you upload with a random AES-256-GCM key that only ever lives in the link itself, so the server holds ciphertext it can't read. Creating a link needs the sender to sign in; set it to expire in 1 hour, 1 day, 3 days, 7 days, or up to 14 days depending on your plan, or make it burn after the first download.

Frequently asked questions

Can I send a folder from an iPhone or iPad?

Not as the sender — iOS's Safari has no folder picker, only individual files, so folder sending currently works from desktop Chrome, Edge, or Firefox. An iPhone or iPad can still receive a folder just fine, as a .zip.

Are subfolders and file structure preserved?

On a realtime send, yes: Relayium keeps every file's relative path, including nested subfolders, so the folder that arrives has the same layout as the one you picked. A stored download link is different — it uploads a flat list of files and drops the paths — so archive the folder yourself and upload the archive when the structure has to survive.

How many files can a folder send hold?

Up to 1,000 files in a single batch, each individually verified with a SHA-256 hash on arrival.

Does the recipient get an actual folder or a .zip?

It depends on their browser. Chrome and Edge write the files straight into a directory they choose. Firefox and Safari receive one store-only .zip (under 4 GiB) that unpacks into the same folder structure.

Do I need an account to send a folder?

Not on the same network. Sending across networks with a pairing code needs the sender to sign in, but the receiver never needs an account either way.

Pick a folder and send it exactly as it is — structure intact, every file verified.

Try Relayium now