Zip File Glossary: Archive Terms Explained

A zip file is not a black box. It is a well-specified binary format with distinct, named parts: a compression algorithm, a trailing index of its contents, a checksum per entry, and metadata that records how each member is stored. This zip file glossary defines the terms you meet when reading a spec, an error message, or the output of an archive tool.

Knowing the vocabulary pays off in practice. When an extraction fails with a CRC mismatch, that points to corruption detected by CRC32. When a tool warns about the compression method, that points to DEFLATE or the store method. When a reader complains it cannot find the central directory, the archive's trailing index is missing or truncated. The definitions below give you enough to read error messages, choose compression settings, and understand what an unzip tool actually does.

Core terms

These are the load-bearing concepts of the format. Each links to a full term page with byte-level detail, where the value sits in the structure, and how tools read it.

[DEFLATE](/glossary/deflate) — the default lossless compression algorithm used by zip. A combination of LZ77 sliding-window matching and Huffman coding, specified in RFC 1951. Every conformant zip reader must support it.
[ZIP central directory](/glossary/central-directory) — the trailing index at the very end of an archive that lists every entry with its name, offset, sizes, and flags. It sits just before the EOCD record, which points to it. Readers locate files by reading this index first rather than scanning from the front.
[CRC32](/glossary/crc32) — a 32-bit cyclic redundancy check computed over an entry's uncompressed data and verified on extraction. It detects accidental corruption (bit flips, truncation); it is not a security primitive and is not collision-resistant against intentional tampering.
[Compression ratio](/glossary/compression-ratio) — the relationship between an archive's compressed and uncompressed size, usually expressed as a percentage or an x:1 factor. It depends heavily on data type: text compresses well, already-compressed media barely at all, and re-zipping an existing zip does essentially nothing.

Additional archive terms

These entries round out the vocabulary. They appear constantly in specs and tool output but are short enough to define inline without a dedicated page.

EOCD (End of Central Directory record) — the fixed-signature record, signature bytes 50 4B 05 06, that sits at the very tail of a zip, after the central directory, and points the reader to the start of it. A missing or truncated EOCD is a common reason an archive will not open.
Store method — the compression method with numeric ID 0, meaning the entry is written verbatim with no compression. Used for data that does not shrink (images, video, already-compressed files) or when speed matters more than size.
ZIP64 — the set of extensions that lifts the classic 4 GB archive and 65,535-entry limits by using 64-bit fields. A reader must check the version-needed-to-extract field and follow ZIP64 pointers, or it will misreport sizes on large archives.
Local file header — the per-entry header, signature 50 4B 03 04, that precedes each member's compressed data. It duplicates some central-directory fields; the central directory is authoritative when they disagree.
Data descriptor — an optional trailing block, signature 50 4B 07 08, that holds an entry's CRC32 and sizes after its compressed data. Used when a writer streams output and cannot know the sizes up front.

Related concepts

Two safety-relevant terms are defined on the security and privacy page rather than here, since they describe attacks rather than format internals.

[Zip bomb](/security-and-privacy) — a malicious archive that decompresses to an enormous size from a tiny payload (the classic 42.zip expands to roughly 4.5 petabytes). It is a denial-of-service risk for naive extractors, not a format feature.
[Zip Slip](/security-and-privacy) — a path-traversal vulnerability where an entry name like ../../etc/cron/x escapes the extraction directory. It is a bug in the extracting software, not in the zip format itself.

Use the glossary

These definitions describe what a zip tool parses under the hood. ZipTool reads all of it in your browser, so you can browse an archive's tree and preview files without uploading anything.

Frequently asked questions

What does DEFLATE mean?

DEFLATE is the default lossless compression algorithm used by zip, defined in RFC 1951. It combines LZ77 (a sliding-window matcher that replaces repeated byte sequences with distance/length references) with Huffman coding (variable-length codes that favor common symbols). It is the method almost every zip entry uses, and every conformant reader must support it. See DEFLATE for the full breakdown.

What is the ZIP central directory?

The central directory is the trailing index at the end of a zip archive that records every entry's name, file offset, compressed and uncompressed sizes, flags, and CRC. Readers find it via the EOCD record, which sits after it at the very tail of the file, then jump straight to any entry by offset rather than scanning linearly. If the central directory or EOCD is missing or corrupt, the archive is effectively unreadable even if the member data is intact. See central directory.

What is CRC32 used for in a zip?

Each entry stores a 32-bit CRC of its uncompressed data. On extraction, the reader recomputes the CRC over the decompressed bytes and compares it to the stored value; a mismatch means the data was corrupted in storage or transit, or the decompression went wrong. CRC32 detects accidental damage reliably but is not a cryptographic hash and must not be treated as tamper protection. See CRC32.

What is a good compression ratio?

There is no universal good ratio because it depends entirely on the data. Text, source code, and spreadsheets often compress to 30-50 percent of their original size (roughly 2:1 to 3:1); JSON and logs can exceed 5:1. Already-compressed formats like JPEG, MP4, and ZIP files barely shrink, often under 5 percent, because their payloads are already entropy-coded, so re-zipping a zip does essentially nothing. Measure on your own data rather than chasing a benchmark. See compression ratio.