Data descriptor: ZIP’s trailing size and CRC block
The data descriptor is an optional block that follows an entry’s compressed data inside a ZIP archive, holding the entry’s CRC-32, compressed size, and uncompressed size. Its signature is the bytes 50 4B 07 08. It exists for one reason: a streaming writer that emits data as it produces it often cannot know the sizes or the CRC until after the last byte has been compressed, so it leaves those fields empty in the local file header and records them afterward in the descriptor.
In other words, the data descriptor is the format’s accommodation for "I had to start writing before I knew the answer." The central directory at the end of the file always carries the authoritative values, so a reader has a reliable fallback; the descriptor exists so the local header can stay honest about being incomplete rather than guessing.
When a data descriptor appears
A writer signals the use of a data descriptor by setting general-purpose bit 3 in the entry’s local file header. When that bit is set, the CRC-32, compressed-size, and uncompressed-size fields in the local header are understood to be zero or placeholder, and the real values follow the compressed data in a data descriptor block. When the bit is clear, those fields in the local header hold the final values and no descriptor is present.
This pattern is the norm for output piped straight to a stream — writing a large archive directly to a network socket or a pipe, for example, where seeking back to patch the header is impossible. It is less common when writing to a seekable file, because a writer with random access can simply record the correct sizes in the local header up front and skip the descriptor entirely.
What the descriptor contains
The data descriptor carries three values: the CRC-32 of the uncompressed data, the compressed size, and the uncompressed size. The leading signature 50 4B 07 08 is, strictly, optional in older revisions of the specification — a reader can in principle walk the compressed stream to its end and read the fields that follow — but in practice nearly all writers emit it, and most readers expect it, so treating it as present is the safe assumption.
Because the descriptor follows variable-length compressed data, a reader that wants it without a signature would have to fully decode the compressed stream first. The signature makes the block findable directly, which is why it became conventional despite the spec leaving it optional. The EOCD and central directory ultimately provide the same numbers regardless, so the descriptor is never the sole source of truth.
Why the central directory is still authoritative
A reader locating an entry through the central directory — the normal path — gets the entry’s offset, sizes, and CRC straight from the authoritative index and may never read the data descriptor at all. The descriptor matters most for the degenerate case of an archive whose central directory is damaged or absent, where a reader is forced to recover entries by walking local file headers and their trailing descriptors from the front of the file.
That recovery path is exactly why the redundancy exists: even in a degraded archive, the data descriptor lets a reader reconstruct enough to extract an entry whose local header was streamed. It is one more instance of the ZIP format storing the same information in two places so that different failure modes remain recoverable.
Common confusion: zero sizes
A frequent surprise when inspecting a ZIP is finding an entry whose local header reports a size of zero even though the entry is plainly not empty. That is the data-descriptor case: bit 3 is set, the local header’s size fields are placeholders, and the true size lives in the trailing descriptor (and in the central directory). It is not corruption. Tools that display the central-directory view show the correct size; tools that trust only the local header can be fooled into calling the entry empty.
Frequently asked questions
What is the data descriptor in a ZIP file?
The data descriptor is an optional block that follows an entry’s compressed data and holds that entry’s CRC-32, compressed size, and uncompressed size. Its signature is 50 4B 07 08. It is used when a writer streams output and cannot know those values when it writes the local file header, so it leaves them empty there and records them afterward in the descriptor.
What is the signature 50 4B 07 08?
50 4B 07 08 is the four-byte signature of the ZIP data descriptor. Like the other ZIP signatures it begins with 50 4B (ASCII "PK"). Strictly the signature is optional in older revisions of the specification, but virtually all writers emit it and most readers expect it, so in practice it marks the start of every data descriptor block.
How do I know if a ZIP entry has a data descriptor?
General-purpose bit 3 in the entry’s local file header is set. When it is set, the local header’s CRC-32, compressed-size, and uncompressed-size fields are treated as placeholders and the real values follow the compressed data in a trailing data descriptor. When the bit is clear, the local header holds the final values and no descriptor is present.
Why does my ZIP entry show a size of zero when it is not empty?
Most likely the entry uses a data descriptor: bit 3 is set, so the size and CRC fields in the local file header are placeholders set to zero, and the true values live in the trailing descriptor and in the central directory. It is not corruption — a tool that reads the central directory will show the correct size.
Is the data descriptor or the central directory authoritative?
The central directory is authoritative. It always carries the entry’s final sizes and CRC, and readers normally read entries through it, often without consulting the data descriptor at all. The descriptor exists as a recovery path for streamed writes and for archives whose central directory is damaged, so the same information is available in two places.