Transfer a Whole Folder and Keep Its Structure

By ShareDrop.org Engineering · Published 2026-09-20

A project folder with sources, assets and a build directory; a photo shoot sorted into days; a client's documents in numbered subfolders. Send it with most tools and the recipient gets a flat pile of files with the hierarchy gone, or, worse, gets files renamed to avoid collisions between two index.html. Keeping structure turns out to be a specific capability that only some paths have. Here are the two that work.

Why folders are hard for transfer tools

A file transfer moves bytes with a name. A folder is not bytes; it is a tree of names. To preserve it, the sending side must send each file's relative path (shoot/day-2/IMG_0412.HEIC, not just IMG_0412.HEIC), and the receiving side must be allowed to create directories and write into them. The second half is the problem: on the web, and on phones, an app generally cannot create folders on your behalf. It can hand you one file at a time, which the system drops into Downloads. The structure is lost at the last step.

Option 1: zip it first (works everywhere)

An archive turns the tree into one file, and one file travels through anything. Every desktop OS can create a ZIP from a right-click; on Android and iOS the Files app can compress a folder. Send the archive by whatever method you like; the recipient unzips and the hierarchy is exactly as it was.

Costs, stated plainly:

• Time and space to build the archive. Zipping 20 GB of video takes minutes and needs 20 GB free, and the video will not get smaller — it is already compressed. Use “store” (no compression) if the tool offers it.
• All or nothing. An interrupted archive transfer that cannot resume restarts from zero, and the recipient cannot open anything until all of it arrives.
• Size caps bite once. Many services cap a single file at 2–5 GB; a folder that would have passed as individual files may fail as one archive.
• Metadata varies. ZIP keeps names and modification times; it does not reliably keep permissions, symlinks or macOS extended attributes. For those, use tar on Unix-like systems.

Option 2: a transfer that writes folders as it goes

Modern desktop Chrome and Edge support the File System Access API, which lets a web page, after you pick a destination folder once, create subfolders and write files into them as data arrives. ShareDrop.org uses it: when you send a folder, each file carries its relative path, and the receiving browser recreates the tree under the folder you chose, streaming each file to disk as it lands.

1. On the receiving computer, open app.sharedrop.org in Chrome or Edge, click Receive, and when prompted choose a destination folder.
2. On the sending side, click Send → Files and pick a folder (desktop browsers) or select the files you want (mobile).
3. Approve, compare the safety code, and watch the tree appear on the receiving side.

Why this is better than an archive when it is available:

• No archive to build or unpack; no doubling of disk space.
• Each file is verified and usable as soon as it arrives, not after the last one.
• An interruption resumes from the last verified chunk of the current file; completed files stay complete (how streaming and resume work).
• No per-file size cap on the receiving side, because nothing is held in memory.

What each receiver can do

So the decision is simple. Receiving on a desktop in Chrome or Edge: send the folder as-is. Receiving anywhere else: zip first. And for a folder that must keep permissions and symlinks (a code repository, a Unix home directory), tar it and send the tarball; no transfer tool will preserve those on its own.

Zip, tar and 7z: what each preserves

For sending a folder to someone else, ZIP wins on compatibility. For a code repository, a home directory or anything where permissions and links matter, tar. 7z only when you need strong built-in encryption and know the recipient can open it.

Path sanitisation: what changes, and why it must

A receiver must never trust the paths a sender supplies. The classic attack is a file named ../../.ssh/authorized_keys: a naive tool that joins that to the destination folder writes outside it, into the recipient's home directory. So every competent receiver rewrites paths before use, and ShareDrop.org does the following:

• Removes any .. component and any leading slash or drive letter, so every path stays inside the chosen folder.
• Replaces characters the destination operating system forbids in names, on Windows < > : " | ? * and control characters, with an underscore.
• Renames files whose names are reserved on Windows (CON, PRN, AUX, NUL, COM1…), which cannot be created there at all.
• Trims trailing spaces and dots, which Windows silently drops and which would cause a name mismatch.

The result is that a folder made on a Mac or Linux machine may arrive on Windows with one or two names slightly changed. That is the price of not letting a sender write wherever they like, and a tool that skips it is a security problem, not a convenience.

Deep folders and long paths on Windows

Windows has a historical 260-character limit on a full path, and a project folder nested eight levels deep with descriptive names reaches it easily. When it does, the file cannot be created, and the error is often unhelpful. Two fixes: enable long paths (a Group Policy or registry setting on Windows 10 and later, after which most modern programs cope), or receive into a short top-level folder such as C:\rx\ rather than deep inside Documents. macOS and Linux have no practical limit here.

Checking that a folder arrived complete

Count files and total bytes on both sides and compare; the numbers should match exactly. On macOS or Linux, find . -type f | wc -l and du -sb .; on Windows PowerShell, (Get-ChildItem -Recurse -File | Measure-Object Length -Sum) gives both. A mismatch in the count with a matching total is nearly always a hidden file (a .DS_Store the Mac added, a Thumbs.db) rather than a missing one. For a folder where every byte matters, generate a list of per-file hashes on the source (sha256sum over find) and verify it on the destination with sha256sum -c: ShareDrop.org already verifies each file as it lands, so this is a belt for people who like braces.

Sending a folder from a phone

Phone pickers choose items, not folders, so a folder in the Files app cannot be sent as a tree from a browser or the mobile app; you get its files, flat. The workaround is the Files app itself: long-press the folder → Compress, and send the resulting ZIP, which unpacks with the structure intact on any receiver. Photos are a separate case (they live in a library, not folders, and albums are not folders either), so “send the album” means selecting its photos, and the receiver sorts them by date afterwards (the photo guide).

A note on collisions

When structure cannot be kept, two files with the same name in different subfolders would overwrite each other. ShareDrop.org prefixes the flattened name with its original path (shoot__day-2__IMG_0412.HEIC) so nothing is lost; other tools may silently keep only the last one. If a recipient ends up with fewer files than you sent, this is the first thing to suspect.