Put several files into one private ZIP archive
Creates one standard ZIP from up to 200 selected files without uploading them. It can store the original bytes directly or compress them with DEFLATE, makes unsafe and duplicate names portable, and reports the exact source and archive sizes.
Up to 200 non-empty files, 50 MB each and 250 MB altogether. Their bytes stay in this tab.
How it works
What this creates
One portable ZIP containing the files selected together. The value is not necessarily a smaller byte count: a ZIP is also a container, so it can turn a set of documents, photos or exports into one named download even when those formats have already compressed their own contents.
Everything happens in the browser worker. The source bytes are not decoded, converted or submitted to an archive service. Store mode copies them into ZIP entries exactly; the three compression modes pass them through the standard DEFLATE algorithm before writing the same ZIP structure.
The method
A ZIP is read from two directions. Starting at the front, each file has a local header followed by its stored or compressed data and a descriptor containing its CRC-32 and sizes. Starting near the end, a central directory lists those entries again so an archive reader can find a named file without scanning every byte before it. The final end record says how many entries the directory has and where it begins.
This tool constructs those records incrementally. Each file is fed to the writer in 512 KB pieces. After every piece, the worker reports how many source bytes it has consumed and yields to its event loop. That yield is what lets a queued Cancel message run; a progress bar updated inside one uninterrupted 250 MB loop would move only after the work had already finished.
The four choices produce two ZIP methods:
| Choice | ZIP method | DEFLATE level | Best starting point |
|---|---|---|---|
| Store without recompressing | 0 | — | JPEG, MP4, ZIP, many PDFs, or fastest bundling |
| Fast compression | 8 | 1 | Text and data when speed matters most |
| Balanced compression | 8 | 6 | General mixed files |
| Smallest ZIP | 8 | 9 | Compressible data when a little more saving is worth more work |
The level is not a new archive format. Fast, Balanced and Smallest all create method 8 entries described by the ZIP specification and RFC 1951; the level only changes how hard the encoder searches for repeated material. A reader does not need to know which level made the stream.
Names are handled before any bytes enter the writer. Directory prefixes are
discarded, characters illegal in common filenames are replaced, control and
bidirectional formatting characters are removed, and names such as CON are
made safe for Windows. Names are compared case-insensitively, then numbered as
report.pdf, report (2).pdf and so on. That produces flat, predictable
extraction instead of trusting an embedded ../ path or letting one file hide
another after extraction.
Modification time is also deliberate. A source file’s original date is not needed to reconstruct its bytes and can disclose information about when it was made. Every entry receives the earliest ordinary DOS date representable in a ZIP, 1 January 1980. Together with fixed attributes and deterministic name handling, equivalent inputs and settings produce the same archive bytes.
A worked example
Select two files and choose Store:
| Entry | Contents | Source bytes |
|---|---|---|
notes.txt | alpha followed by a newline | 6 |
pixels.bin | hexadecimal 00 01 02 03 | 4 |
The source total is 10 bytes. The result contains two entries under those exact
names, reports zero renamed files and is 254 bytes long. Extracting notes.txt
returns the same six bytes; extracting pixels.bin returns 00 01 02 03.
The extra 244 bytes are archive structure: two local headers, two descriptors, two central-directory records, both UTF-8 filenames and the end record. That is why “Store” means no compression rather than no overhead. These exact entry names, contents, counts and the 254-byte result are asserted in the tool’s test so the example cannot drift away from the implementation.
Compression does not mean conversion
DEFLATE is lossless. It describes repeated byte sequences more compactly; it does not decode a JPEG, lower the quality of an MP4 or rewrite a PDF. Extraction recreates the original entry bytes, and the CRC-32 in the ZIP is checked against those recreated bytes.
But lossless does not mean useful on every input. JPEG and MP4 have already run specialised compression over their image and media data. ZIP files contain compressed streams already. Many PDFs compress images, fonts and page streams. For those, DEFLATE often finds little left to shorten, while its headers and block choices can add a few bytes. Store is the honest option when one container is the goal and another compression pass is not.
What this does not preserve
It does not import a folder tree. Every chosen file lands at the root under a safe basename, and source paths are not retained. It does not copy filesystem permissions, owner IDs, comments, hidden flags or source timestamps. The fixed metadata makes the output portable and avoids leaking local details, but it is not a backup format for filesystem metadata.
It does not encrypt or sign the result. CRC-32 lets an extractor notice a damaged entry; because anybody changing an entry can calculate a new CRC-32, it does not identify the archive’s author. Generate a file checksum for the final ZIP if two copies are supposed to remain byte-for-byte identical, and use a signature or authenticated encryption when the threat is deliberate change or disclosure.
How it is done
- Check that the selection contains 1 to 200 non-empty files, no file is larger than 50 MB, and their combined size is no more than 250 MB.
- Reduce every selected name to a flat basename, remove path separators and unsafe control characters, protect reserved Windows names, cap the UTF-8 name length, and number collisions without regard to letter case.
- Start one ZIP entry per file. Store mode copies the bytes with ZIP method 0; Fast, Balanced and Smallest use method 8 DEFLATE at levels 1, 6 and 9 respectively.
- Feed each source into the ZIP writer in 512 KB pieces. The writer calculates CRC-32, emits the entry records and reports progress while the worker yields between pieces so Cancel remains effective.
- Give every entry the fixed ZIP date 1 January 1980 and portable read/write attributes, then finish the central directory and offer the completed bytes as the requested .zip download.
What it assumes
- Selected files become flat entries at the root of the archive. Folder structure, source paths, comments and source modification times are intentionally not copied.
- Store mode preserves every source byte but does not promise that the ZIP itself will be smaller. ZIP headers, filenames, checksums and its central directory add overhead.
- Fast, Balanced and Smallest are three effort levels for the same standard DEFLATE method. A higher level can take longer without producing a meaningfully smaller archive, especially on JPEG, MP4, PDF, ZIP and other already-compressed formats.
- CRC-32 catches accidental corruption when an entry is extracted. It is not a cryptographic signature, authentication mechanism or defence against deliberate modification.
- This tool does not encrypt entries or add a password. The resulting archive is an ordinary unencrypted ZIP whose filenames and contents are available to anybody who has the file.
- Source bytes and the growing archive are held in the browser worker, which is why the per-file, combined-input and output limits are explicit.
Common questions
Are the files uploaded before the ZIP is made?
No. The selected File objects are read by a worker in this browser tab, and that worker writes the ZIP records locally. The page's browser test fails if using the tool sends a selected file in a network request.
Which compression setting should I use for JPEG, PDF or MP4 files?
Use Store without recompressing when the selection is mostly JPEG, MP4, ZIP, modern PDF or similarly compressed material. DEFLATE is unlikely to find much repetition left, so it usually spends more time for little or no saving and can make the archive slightly larger.
Does Store without recompressing change the files?
No. Method 0 places the exact source bytes inside each ZIP entry. The ZIP around them has its own headers, CRC-32 values and directory, but extracting an entry reproduces the original file bytes.
Can selected filenames create folders when the ZIP is extracted?
No. Each entry is reduced to a flat basename, path components are discarded and unsafe punctuation is replaced. If the resulting names collide, later entries receive suffixes such as report (2).pdf instead of creating a path or overwriting another file.
Can this ZIP creator password-protect or encrypt an archive?
No. It creates ordinary stored or DEFLATE entries and does not implement either legacy ZipCrypto or AES encryption. Use an archive application with authenticated encryption when confidentiality matters.
Does a successful CRC-32 check prove who created the ZIP?
No. CRC-32 is an error-detection value stored beside each entry, and an editor can replace both the data and that value. Compare a SHA-256 from a separately trusted source or verify a digital signature when origin and deliberate tampering matter.