Backup ZIP Creator

Backup ZIP Creator is for moments when you want a single, clearly labelled archive of a project's current state before you change it. The most natural fit is the periodic snapshot: a designer or developer packaging a project folder before a refactor, a content overhaul, or a risky dependency bump, so there is always a known-good copy to fall back to. The archive is named with today's date by default, for example backup-2026-01-15.zip, which keeps a stack of snapshots sortable and self-explaining.

It also suits handover and archiving: freelancers wrapping up client deliverables, office users closing out a quarter, or students keeping a finished thesis folder, each as one clearly labelled ZIP with a record of what went in.

It does not sync, schedule or track changes; it is a deliberate "freeze this, now" snapshot you run by hand.

Drop in individual files or whole folders, check the name (backup- and today's date, to which you can add a project name), and click Create ZIP. Folder paths are kept, system files such as .DS_Store, __MACOSX, Thumbs.db and desktop.ini are left out, and files that would land on the same path are numbered instead of overwriting each other. Processing happens entirely in your browser; nothing is uploaded, and nothing persists once the tab is closed.

With the manifest option on (the default), two more files go into the ZIP. MANIFEST.txt lists every file with its SHA-256 checksum, its size in bytes, its last-modified time and its path, which is a readable record of what the backup holds. SHA256SUMS holds the same checksums in the standard format that sha256sum -c on Linux and shasum -a 256 -c on macOS read, so after extracting you can prove in one command that every file is present and unchanged.

If one of your own files is already called MANIFEST.txt or SHA256SUMS, the tool numbers its own copies rather than overwriting yours. The tool also flags when your input is mostly already-compressed media (JPEG, PNG, MP4, PDF, existing archives), since the backup will not be much smaller than the originals.

The biggest constraint is memory. Everything is held and zipped in the browser tab, and with the manifest on every file is read once more to compute its checksum, so very large backups (many gigabytes of video, for instance) can stall or fail depending on your device and available RAM. For heavy folders, split the job or use a desktop archiver instead. There is no incremental mode either: every run builds a full archive from scratch, so ten snapshots of a slowly-changing project means ten complete copies, not deltas.

A common mistake is expecting smaller output than you get. Compression mainly helps text, code, and documents; if your folder is mostly photos, audio, or video, the backup will be close to the size of the originals. Another is reusing a name: two backups made on the same day get the same default name, so add a time or a note if you make more than one.

Finally, remember what the checksums prove. They show that the files have not changed since the backup was made; they cannot tell you whether a file was already damaged, or the wrong version, when you added it.

Before relying on a backup, open the finished ZIP and confirm it actually contains what you intended: the expected folders, a file count matching the result screen, and a total size in the range you'd expect rather than suspiciously small. Read MANIFEST.txt to see the list the tool recorded.

The strongest check is to extract the archive to a temporary folder and run sha256sum -c SHA256SUMS there (or shasum -a 256 -c SHA256SUMS on a Mac): every file should report OK. Keep the ZIP's own checksum too, using the Checksum tool, if you want to confirm later that the backup file itself has not been damaged in storage.

For records that matter, open key documents and keep an independent copy; a self-check proves the files are unchanged, not that they are the right ones.