ZIP Builder for Deployments

Creating a ZIP is not the problem. Having the platform reject it afterwards is. This tool strips system junk, checks the archive root, and warns about limits before you upload - entirely in the browser.

Open in a new tab

Download offline package (ZIP)

The real problem is three small ones, not one big one

Anyone who uploads a static site by hand rather than through a repository knows the sequence: zip, upload, error, guess. It is almost always one of three.

System junk in the archive. macOS Finder puts __MACOSX/ and .DS_Store into the ZIP. You never see it, and it still gets rejected or served.

One level too deep. You zip the folder instead of its contents - and index.html ends up at dist/index.html instead of the root. The upload succeeds, the site is blank, and nothing tells you why.

Limits that only surface during upload. Maximum file size and file count become apparent the moment the upload aborts - after the wait, not before it.

The value is in the checking, not the zipping

Every operating system can compress. What it cannot do:

  • Strip system junk - __MACOSX/, .DS_Store, Thumbs.db, .git/, node_modules/
  • Check the root - “Your index.html sits in dist/. Remove that level?”
  • Report limits up front - file size and file count checked against the target before anything is transferred
  • Restructure folders - move files into subdirectories by drag and drop, without rearranging things in the file manager
  • Proofread configuration - check _headers and _redirects for syntax errors while they can still be changed

Targets

The checks differ per target, so there are presets rather than one generic pass:

TargetWhat is checked in particular
Cloudflare Pages and Workersroot level, file size, file count, _headers and _redirects
Chrome Web Store, Firefox Add-onsmanifest.json must sit at the root - the single most common beginner mistake
WordPress: plugin and themedirectory name and the header comment of the main file
Shopify themes, Moodle packagesexpected directory structure

Why in the browser

A deployment archive is the complete source state of a site, often before it goes public. You do not upload that to a third party just to get rid of system files. Here no file leaves the browser - there is no server for it to go to.

Runs entirely in your browser

The tool itself loads nothing and sends nothing. Your data is processed in the browser and never leaves the device - verifiable in your browser's network tab.

Let's talk

Free initial consultation - no sales pitch, just an honest assessment.

Request a consultation →