Local file header: the per-entry ZIP record
The local file header is the per-entry record that immediately precedes each member’s compressed data inside a ZIP archive. Its signature is the bytes 50 4B 03 04. Where the central directory at the end of the file is the authoritative index of every entry, the local file header is the on-the-spot label attached to each entry’s bytes — telling a reader how this particular member is compressed, what its CRC32 is, and how to find the data that follows.
Every entry carries its own local file header, so a multi-file archive repeats the record once per member. For each one the header records the compression method, the general-purpose flags, the modification timestamp, the CRC, the compressed and uncompressed sizes, the file name, and an optional "extra field." After the header come the raw compressed bytes, and for streamed entries an optional trailing data descriptor.
What the local file header contains
After the four-byte signature 50 4B 03 04, the fixed part of the record holds: the version needed to extract the entry, the general-purpose bit flag (which encodes options like whether the name is UTF-8, or whether a trailing data descriptor follows), the compression method (0 for Stored, 8 for DEFLATE), the last-modified time and date, the CRC-32 of the uncompressed data, the compressed size, the uncompressed size, the file-name length, and the extra-field length. Those two lengths are followed by the variable-length file name and the extra field itself, and only then by the compressed payload.
Several of these fields duplicate what the central directory stores for the same entry — deliberately. A streaming writer can emit the local file header and data first and write the central directory once everything is known, while a reader that only needs one file can extract it from the local header plus the bytes that follow without ever consulting the index. The redundancy is a feature of the format, not a mistake.
When the local header and central directory disagree
Because the same metadata appears in two places, they can disagree — and the ZIP specification is explicit about which wins: the central directory is authoritative. If a local file header claims one compression method or one file name and the central-directory entry for that member claims another, a conformant extractor trusts the central directory. In practice the disagreement is rare in well-formed archives, but it is exactly the kind of thing a malformed or hand-edited archive gets wrong, and the rule keeps readers robust.
One specific case matters often: the sizes and CRC in the local header may be zero. That happens when the writer streamed the data and did not know those values up front. In that case general-purpose bit 3 is set, signaling that the real values follow the compressed data in a trailing data descriptor. A reader that ignores bit 3 and trusts the zeros will conclude the entry is empty when it is not.
The signature and the other ZIP signatures
50 4B 03 04 is the local file header signature. It belongs to a family of four-byte signatures, each of which names a distinct record type and lets a reader identify what it is looking at: 50 4B 03 04 for the local file header, 50 4B 01 02 for a central-directory entry, 50 4B 07 08 for the optional data descriptor, and 50 4B 05 06 for the EOCD at the very end. The leading 50 4B is readable as the ASCII PK, Phil Katz’s initials — a deliberate marker from the format’s origin in PKZIP.
Why this record matters for a viewer
A zip viewer that reads entries on demand uses the central directory to locate an entry and its local file header, then reads the header to learn how the following bytes are stored before inflating them. Because the method is per-entry (0 Stored, 8 DEFLATE, and so on), the header is what tells the parser which decoder to apply to each member. Everything in this flow runs in the browser when you preview an archive — the bytes are parsed locally, never uploaded.
Frequently asked questions
What is the local file header in a ZIP?
It is the fixed-signature record (signature 50 4B 03 04) that precedes every entry’s compressed data. Each entry has its own local file header carrying the compression method, general-purpose flags, modification time, CRC-32, compressed and uncompressed sizes, file name, and extra field, followed by that entry’s compressed bytes.
What is the signature 50 4B 03 04?
50 4B 03 04 is the four-byte signature of the ZIP local file header. The leading 50 4B is the ASCII characters "PK", Phil Katz’s initials, inherited from the format’s origin in PKZIP. Other records have their own signatures: 50 4B 01 02 for central-directory entries, 50 4B 07 08 for the data descriptor, and 50 4B 05 06 for the EOCD.
Why does the local file header duplicate the central directory?
The redundancy is deliberate. A streaming writer can emit each local header and its data as it goes, then write the central directory once at the end; and a reader that needs only one file can extract it from its local header plus the bytes that follow without scanning the whole index. When the two disagree, the ZIP spec says the central directory is authoritative.
Why are the sizes and CRC zero in a local file header?
They are zero when the writer streamed the data and could not know the compressed size, uncompressed size, or CRC at the time it wrote the header. In that case general-purpose bit 3 is set, signaling that the real values follow the compressed data in a trailing data descriptor. A reader must honor that flag or it will treat a non-empty entry as empty.
Where is the compression method stored?
In the local file header (and duplicated in the central-directory entry for that member). The field holds a numeric ID: 0 means Stored (no compression), 8 means DEFLATE, 9 means Deflate64, and so on. The reader uses this value to pick the correct decoder for the bytes that follow the header.