Folder to ZIP — Upload a Folder

Folder to ZIP is for the moment you have a structured set of files on disk (nested subfolders, naming conventions, the lot) and you need it to arrive somewhere as a single archive with that structure intact. It reads the folder you pick (including subfolders) and writes one ZIP where each file keeps its original relative path, so a recipient who unzips it sees the same tree you started with rather than a flat pile of files.

This fits a handful of genuinely common situations. Developers zipping a project directory, a static site, or a set of assets for upload or handoff. Office and admin users bundling a client folder, a case folder, or a month's documents into one attachment. Students and researchers packaging a project folder with its data and write-up subfolders before submission. Designers or photographers sending a job folder where the subfolder layout (drafts, finals, source) actually carries meaning.

Because nesting is preserved, it suits any case where the folders themselves are part of the information: not just a convenient grouping. If you only have loose files and don't care about structure, the plain Files to ZIP tool covers that with less ceremony.

The flow is: add a folder, check the options, then create and download. Drag the folder from your file manager onto the page, or click to open the folder picker; either way the tool reads every file inside, including those in subfolders, and keeps each one's path. A button below lets you add individual files too. Everything runs locally in your browser via JSZip; the folder is read into memory, zipped, and offered as a download, with nothing sent to a server.

The ZIP is named after the folder unless you type another name. System files (.DS_Store, __MACOSX, ._ files, Thumbs.db and desktop.ini) are always left out, and the "Leave out hidden files and folders" option also skips anything whose name starts with a dot, such as .git, .env or .vscode. Keep that option off when the folder needs a hidden file like .htaccess.

What it does not do: it produces a standard ZIP only (not 7z, RAR, or tar), and password protection is handled by a separate tool, not this one. It also won't meaningfully re-compress files that are already compressed; images, video, PDFs, and existing archives go in close to their original size, and the tool flags this rather than promising savings.

The most frequent surprise is empty folders: the tool reads files, so a folder with nothing in it does not appear in the ZIP. If an empty folder matters to the recipient, put a small placeholder file in it first.

Size is the other real constraint. Everything is held in browser memory while zipping, so very large folders, deep trees, or thousands of files can be slow or strain a tab, especially on low-memory machines; the tool warns above about 300 MB. Expecting heavy shrinkage on a folder full of JPEGs or videos is another mistake; those are already compressed.

Smaller traps: on a phone you can usually choose files but not a folder, so do folder jobs on a computer; hidden files you actually need disappear if you tick the hidden-files option; and very long path names can be rejected by some upload forms or older unzip tools on the receiving end.

Before sending or archiving, open the finished ZIP and confirm the tree matches the source: subfolders nested correctly, and the file count the result screen reported close to what you expected. Spot-check that nothing important was dropped, particularly if you ticked the hidden-files option. Glance at the reported output size; a folder of documents should compress noticeably, while a media-heavy folder staying near its original size is expected, not a fault.

Open a couple of files from inside the archive to confirm they extract cleanly and aren't truncated, which is the quickest way to catch a folder that was too large for the tab to finish reliably.

For anything official, financial, or legal (submissions, evidence bundles, contract sets), do a manual verification: extract the ZIP to a fresh location and compare it against the original folder file-by-file rather than trusting the in-browser count alone. Confirm the extracted copies open and read correctly at the destination before you treat the archive as the record of truth.