Store method: ZIP compression method 0
The Store method is the ZIP compression method with numeric ID 0, and it means exactly what the name suggests: the entry is written verbatim, with no compression. The bytes that follow the local file header are the original file’s bytes, byte for byte. Where DEFLATE (method 8) runs the data through LZ77 and Huffman coding to shrink it, Store simply copies it through.
Store is not a degenerate or lazy choice — it is the correct choice for data that does not compress. Already-compressed media (JPEG, PNG, MP4, MP3), other archives (a .zip inside a .zip), and encrypted payloads are all entropy-coded already; running them through DEFLATE wastes CPU and saves essentially nothing, sometimes even growing the output by a fraction of a percent. Store is also used when speed matters more than size, or when an entry must remain directly mappable without decompression.
How the method is recorded per entry
ZIP records the compression method per entry, not per archive. Each local file header and each central directory record carries a method field: 0 for Stored, 8 for DEFLATE, 9 for Deflate64, and so on. A single archive can freely mix methods — text files deflated, images stored — because the reader consults the method field for each entry to decide which decoder, if any, to apply.
For a Stored entry there is no decoder to apply: the compressed size equals the uncompressed size, the bytes are the original bytes, and the reader hands them through directly. The CRC-32 is still computed over the (identical) uncompressed data and checked on extraction, so integrity verification works exactly as it does for compressed entries.
When Store beats compression
The decision to store rather than compress comes down to whether the data still has exploitable redundancy. A few rules of thumb:
- Already-compressed media — JPEG, PNG, MP4, MP3, and other finished media files are already entropy-coded; DEFLATE finds almost nothing to remove and Store is effectively free.
- Nested archives — a
.zip,.jar, or.apkinside the archive is itself compressed; re-compressing it does nothing, so Store keeps the entry intact and parseable. - Encrypted data — ciphertext and well-compressed payloads look random to a compressor and will not shrink; Store avoids the wasted work.
- Small files or speed-critical paths — when the decompression cost matters more than a few percent of size, Store trades bytes for speed.
Why you cannot just "recompress" an entry in place
A common misconception is that you can open a ZIP and tell it to compress a Stored entry more aggressively, or swap a Stored entry to DEFLATE. The method is fixed in the local file header and central directory at write time, and the bytes that follow were laid out for that method. To change the method you must rewrite the entry — re-encode the data under the new method, update the header fields and sizes, and update the central directory and EOCD offsets. That is a full re-archive, not an edit.
This is why "zip a zip to make it smaller" is futile: the inner archive is already compressed, so the outer archive will Store it (or deflate it to no effect), and the total size is essentially unchanged. The compression ratio of already-compressed data is near zero.
Store and solid archives
Classic ZIP compresses each entry independently — so even when many text entries share repeated content, that redundancy is compressed entry-by-entry and not across files. Some formats (7z, RAR) instead compress the whole stream of files together as a solid archive, which captures cross-file redundancy and improves the compression ratio. ZIP’s per-entry Store/DEFLATE model is the opposite design: simpler, faster random access, and trivial single-file extraction, at the cost of some ratio on collections of similar files.
Frequently asked questions
What is the Store method in a ZIP file?
Store is ZIP compression method 0, meaning the entry is written verbatim with no compression — the stored bytes are identical to the original file. It is used for data that does not compress, such as already-compressed media or nested archives, or when decompression speed matters more than size.
What is ZIP compression method 0?
Method 0 is Stored — no compression. The entry’s compressed and uncompressed sizes are equal and the bytes are the original bytes. Method 8 is DEFLATE (the default), method 9 is Deflate64, and so on; the method is recorded per entry in the local file header and central directory.
Why are some ZIP files not compressed?
Because the writer chose the Store method for entries whose data would not shrink — images, video, audio, and other archives that are already entropy-coded. Compressing them wastes CPU and can even grow the output slightly. The archive still groups and indexes the files; it just does not re-encode their bytes.
Can I compress a Stored ZIP entry after the fact?
Not in place. The compression method is fixed in the local file header and central directory when the entry is written, and the bytes were laid out for that method. To change it you must re-encode the data, rewrite the entry, and update the header, central directory, and EOCD — effectively re-creating the archive.
Does zipping an already-compressed file make it smaller?
No. Already-compressed data — JPEGs, MP4s, or another ZIP inside the archive — has little to no remaining redundancy, so DEFLATE removes almost nothing and may even add overhead. The outer archive effectively Stores the file and the total size is essentially unchanged. This is why re-zipping a zip is futile.