ZIP Compress / Extract

ZIP is the format that won. It's been the universal file-bundle format since 1989 — older than most of the engineers reading this — and it remains the format every email client, web upload form, and operating system understands by default. When you want to send a folder of files, you ZIP them. When you want to download a code project, you get a ZIP. When you want to share photos with someone who doesn't use the same cloud storage as you, you ZIP and send.

This tool does the two operations everyone actually does with ZIPs: **bundle** (drop files, get a ZIP back) and **unpack** (drop a ZIP, get the files back). Both happen entirely in your browser using JSZip, the standard JavaScript ZIP library. No uploads, no temp folders on disk, no server round-trip.

The **bundle** path is straightforward. Drop one or more files. JSZip arranges them into a ZIP archive with deflate compression at level 6 (the default in the PKZIP spec and the level used by every mainstream OS tool). The result downloads as either `<filename>.zip` (for single-file bundles) or `archive.zip` (for multi-file). Filenames are preserved verbatim, including unicode characters. The compressed size depends entirely on what you're bundling — already-compressed formats (JPG, PNG, MP4, PDF) compress almost not at all because their internal compressors already squeezed the redundancy out; text files and uncompressed data (CSV, JSON, BMP) shrink dramatically.

The **unpack** path takes any standard ZIP and lists every file inside. Each entry shows its name and size with a Download button that produces just that file. JSZip handles directory entries correctly (folders appear as path prefixes; the download saves just the basename). Empty folders inside ZIPs are not surfaced (they have no downloadable bytes).

A few specific behaviors worth knowing:

**Compression level is fixed at 6.** This is the default for every mainstream OS tool — Windows Explorer, macOS Archive Utility, 7-Zip's default settings, `zip` on Linux. You can compress harder (level 9) for ~5% smaller files at 3–5× the CPU time; or compress lighter (level 1) for ~10% bigger files at much faster speed. Level 6 is the broadly-accepted right answer for general-purpose use. No need to expose a slider.

**Encryption is not supported.** JSZip doesn't implement ZIP encryption (the classic PKZip encryption is broken anyway, and AES-encrypted ZIPs aren't in the base JSZip distribution). If you need encrypted archives, use a desktop tool. If you need just confidentiality (not legal encryption), encrypt the source files with `age` or `gpg` *before* zipping — the resulting ZIP has encrypted bytes inside even though the ZIP itself is unencrypted, and the recipient unzips then decrypts.

**Extraction handles all standard ZIP variants.** Single-file ZIPs, multi-file ZIPs, ZIPs with directory structure, ZIPs created by 7-Zip / WinRAR / macOS / Linux `zip` — JSZip reads all of them. ZIP64 (for archives >4 GB or >65k entries) is supported. ZIPs with non-ASCII filenames (Korean, Japanese, emoji) usually work, with the caveat that some older ZIPs used the system codepage for filenames and JSZip assumes UTF-8 — names may render as garbage in that case but the bytes are still recoverable.

**Encrypted ZIP failures are clear.** If you drop a password-protected archive, the extraction fails with a clear error message explaining that this tool doesn't support encryption. Same for corrupt files: a truncated or damaged ZIP produces a specific error rather than crashing.

**Streaming vs whole-archive loading.** JSZip loads the entire archive into memory rather than streaming. For most archives this is invisible — a 100 MB ZIP unzips fine. For multi-GB archives the browser's per-tab memory limit becomes the binding constraint, which on most desktop browsers is around 2-4 GB. Beyond that, a desktop tool with disk-streaming is the right pick. In practice this matters only for backup archives and old game ROMs.

**Filename safety.** When extraction produces a file with a forward slash in its name (representing a folder structure inside the ZIP), the download button uses just the basename. So a ZIP containing `photos/2024/vacation/IMG_001.jpg` downloads as `IMG_001.jpg`. If you need the folder structure preserved, run the same extraction in a desktop tool that can write directories — the file paths inside the ZIP are correctly preserved in the archive metadata.

**Practical performance.** Compressing 100 MB of text-heavy data takes a couple of seconds; compressing 1 GB of pre-compressed media takes the time to read the bytes (which is the disk speed). Extraction is faster than compression by a factor of 3–10× because decompression is computationally cheap relative to compression. The thing you can't get around is browser tab memory: if you're processing a multi-GB archive, you want a desktop tool.

**Privacy.** Everything runs in your tab via JSZip's pure-JS implementation. There are no fetches, no uploads, no server-side processing. Verify in DevTools — drop a ZIP, watch the network panel stay flat. Your archive's contents are visible only to you, which is the entire point of how this site works.

**Edge cases handled:** ZIPs with non-ASCII filenames; ZIPs with deep nested directory trees; ZIPs containing zero-byte files; ZIPs without compression (stored mode); ZIPs created on different OSes (Windows CRLF line endings vs Unix LF — preserved verbatim); files with the same name in different directories inside the ZIP; very small (under 1 KB) and very large (multi-MB) individual entries.

**One thing the tool deliberately doesn't do**: preview file contents inside the ZIP. The list shows names, sizes, and download links, but to read a text file or view an image inside a ZIP you click Download and open it in the appropriate app. Building a universal file previewer would balloon the bundle size for marginal value — the existing tools on this site (JSON Formatter, image preview tools) can take the extracted files as input.