Byte layout

Bytes 0-3 contain the ASCII string Cr24. Bytes 4-7 contain the version as a little-endian unsigned 32-bit integer. Bytes 8-11 contain the header length. The header begins at byte 12 and occupies the declared length. The ZIP begins immediately after it.

CRX3 does not use the older separate public-key and signature length fields from CRX2. Its header carries signed data, and the ZIP signature should appear where the length calculation says it will.

CRX3 header fields
OffsetSizeMeaning
04 bytesMagic: Cr24
44 bytesVersion: 3
84 bytesHeader length (little-endian)
12N bytesSigned CRX header
12 + NRemainingZIP archive payload

Related pages:unpack CRX without installingCRX package analyzer

Safety checks before extraction

A parser should reject truncated files, header lengths larger than the remaining buffer, and payloads that do not begin with a ZIP signature. It should also apply archive limits after locating the ZIP.

The analyzer performs these checks in sequence and never interprets the CRX header as executable code. If the structure is invalid, the scan stops with a clear error instead of guessing.

Related pages:CRX file analyzer onlinebrowser extension privacy checker

Signature versus safety

The signed header helps browsers associate the package with an extension identity and detect some tampering. It does not audit the JavaScript, permissions or data practices. A valid signature can sign a privacy-invasive extension.