CRX File Documentation

Summary

A CRX (Chrome Extension Package) file is a packaged browser extension for Chrome and other Chromium browsers (Edge, Brave, Opera): a ZIP archive of the extension’s code and assets, prefixed with a signed Cr24 header that verifies the publisher. Its MIME type is application/x-chrome-extension. Normally extensions install from the Chrome Web Store, but modern Chrome blocks manual .crx installs for security. To inspect or sideload one, rename it to .zip, extract it, and use “Load unpacked” in Developer mode.

Technical details

FeatureValue
Full nameChrome Extension Package
File extension.crx
MIME typeapplication/x-chrome-extension
Format typeSigned ZIP archive with a CRX header (binary)
DeveloperGoogle (Chromium project)
Introduced2010 (CRX2); CRX3 mandatory since Chrome 75, June 2019
Current versionCRX3 (protobuf-based signed header)
Open standardPartial — format documented in the Chromium source
Base formatZIP (payload after the header)
Byte orderLittle-endian (header length fields)
Magic number43 72 32 34 (“Cr24”) at offset 0
Version bytes03 00 00 00 (CRX3) or 02 00 00 00 (CRX2) at offset 4
SigningEmbedded public key + cryptographic signature over the archive
Key manifest filemanifest.json (name, version, permissions, scripts)
Installs viaChrome Web Store; or unzip + “Load unpacked” in Developer mode
Security riskHigh — runs with broad access to your browsing when installed
Related extensions.zip, .xpi, .nex, .pem
Specificationchromium.googlesource.com/.../crx_file/
File signature (magic bytes)
43 72 32 34 03 00 00 00

Offset 0. Bytes 0–3 are the ASCII magic Cr24 (“Chrome” + 24). Bytes 4–7 are the little-endian format version: 03 00 00 00 for CRX3, 02 00 00 00 for the legacy CRX2. A signed header (a public key and a signature over the ZIP) follows, and only after it comes the ordinary ZIP archive (50 4B 03 04). So a CRX is a ZIP with a signed prefix, not a bare ZIP at offset 0, which is why archive tools sometimes warn about the leading bytes.

What is a CRX file?

CRX is the package format for extensions in Google Chrome and other Chromium-based browsers — Microsoft Edge, Brave, Opera and Vivaldi. Technically a .crx is a ZIP archive of the extension’s files (a manifest.json plus HTML, CSS, JavaScript and icons) with a binary header bolted onto the front: the magic bytes Cr24, a format version, and a cryptographic signature carrying the developer’s public key. Google introduced the format in 2010; the original CRX2 was replaced by CRX3, which Chrome has required since Chrome 75 in June 2019.

In normal use a CRX is invisible. When you click “Add to Chrome” in the Chrome Web Store, the browser downloads the CRX, verifies its signature and installs it automatically — you never see the file. People meet a standalone .crx only when they download an extension from outside the store: a GitHub release, a private or enterprise extension, a backup, or an extension pulled from the store before it was removed. Installing those has been made deliberately difficult, which is the source of nearly every CRX question. The rest of this page is about what is actually inside the file and why Chrome treats it the way it does.

The Cr24 header: magic, version and signature

Every CRX begins with a fixed prefix before any ZIP data. The first eight bytes are constant in structure: a four-byte magic number and a four-byte little-endian version.

CRX3 file layout (offsets from start)
  0   magic number       4 bytes   "Cr24"  (43 72 32 34)
  4   version            4 bytes   03 00 00 00   (CRX3)
  8   header_size        4 bytes   length of the signed header that follows
 12   signed header      N bytes   protobuf: public key(s) + signature(s)
 12+N ZIP archive        to EOF    the extension's files (manifest.json, code, assets)

In CRX3 the signed header is a Protocol Buffers (protobuf) message. It holds one or more public keys and their signatures computed over the ZIP payload, and it binds the package to a stable extension ID: the ID is derived from the developer’s public key, so a given key always produces the same 32-character ID. That binding is what lets Chrome recognise updates as coming from the same publisher and reject a tampered package whose contents no longer match the signature. CRX2, the older format, used a simpler fixed header (public key length, signature length, then the raw RSA key and signature) rather than protobuf; Chrome 75 dropped support for it.

A CRX is a signed ZIP: renaming and unpacking

Past the header, a CRX is an ordinary ZIP file. Its local file header starts with the usual ZIP signature 50 4B 03 04, just not at offset 0. That single fact drives the practical advice for inspecting one: rename file.crx to file.zip and open it with 7-Zip, WinRAR, The Unarchiver or the operating system’s built-in unzip. Most archive tools skip the leading Cr24 header and extract the entries cleanly; a few warn about the extra bytes at the front, but the contents still come out.

Inside the archive the important file is manifest.json, which declares the extension’s name, version, the scripts it runs, and — critically — its permissions. Alongside it are the background and content scripts (the extension’s JavaScript), popup and options HTML pages, icons, and often a _metadata/ folder with verified-contents data added by Web Store packaging. Reading manifest.json before running anything is the honest way to judge what an extension does.

Why Chrome blocks CRX installs, and how to load one anyway

Since around 2018 Chrome refuses to install CRX files that did not come from the Web Store. Drag a .crx onto chrome://extensions and it is rejected with an error like CRX_REQUIRED_PROOF_MISSING, or the extension is silently disabled. This is intentional: sideloaded extensions bypass Google’s review and malware scanning, and drive-by CRX installs were a real malware vector.

The supported workaround is to unpack and load the extension as an unpacked folder rather than as a packaged CRX:

1. Rename  extension.crx  →  extension.zip
2. Extract it to a folder
3. Open  chrome://extensions
4. Turn on "Developer mode" (top-right toggle)
5. Click "Load unpacked" and select the extracted folder

Enterprises take a different route: they deploy CRX files through Group Policy force-install, giving Chrome the extension’s update URL so the browser fetches and verifies it automatically under policy. There is no way to make a casual double-click install a standalone CRX on current Chrome, and that is by design.

Security: extension code runs with broad access

A CRX is not passive data. Once installed it is executable browser code that runs inside your browser session, and depending on the permissions it requests it can read the pages you visit, your cookies, your browsing history, and data you type into forms. An extension with the <all_urls> host permission and a content script can observe and modify every page you open, which is exactly the access a password stealer or ad injector needs.

The concrete attack path is sideloading. Installing a CRX from outside the Web Store skips Google’s automated review, so a malicious package can request sweeping permissions and act on them the moment it loads. Before running any CRX from an untrusted source, rename it to .zip, open manifest.json, and read the permissions and host_permissions arrays: entries like "tabs", "cookies", "webRequest" and broad host matches are the ones that grant real reach. Treat “free premium extension” CRX downloads from random sites the way you would treat a sideloaded app, because many are adware or data-stealers. The safe default is to install from the Chrome Web Store, where the signature and review pipeline apply.

CRX versus XPI: why you cannot just convert one

Firefox packages its extensions as XPI files, which are also signed ZIP archives, so a natural question is whether a CRX converts to an XPI. It does not, at least not by repackaging. Chrome and Firefox both implement the WebExtensions standard, but they differ in available APIs, in manifest details, and in signing: a Firefox add-on must be signed by Mozilla to install. Turning a Chrome extension into a working Firefox one means re-authoring the parts that use Chrome-specific APIs and re-signing through Mozilla, not renaming a file. Likewise a CRX cannot become a Windows .exe or an Android .apk: a browser extension has no standalone entry point and only runs inside Chromium. The only real “conversion” is CRX to ZIP, which is just stripping the header to inspect the contents.

Frequently asked questions

Why won’t Chrome let me install my CRX file?

For security, modern Chrome only auto-installs extensions from the Web Store and rejects standalone CRX files (CRX_REQUIRED_PROOF_MISSING, or it disables them). Unzip the CRX and use “Load unpacked” from chrome://extensions in Developer mode, or install the extension from the Web Store if it is listed there.

How do I open a CRX to see what is inside?

A CRX is a ZIP with a signed header. Rename it to .zip and open it with 7-Zip, WinRAR or your operating system’s unzip, then read manifest.json to see the extension’s permissions and scripts before you consider loading it.

What is the difference between a CRX and a ZIP?

A CRX is a ZIP of the extension’s files plus a Cr24 header containing the developer’s public key and a signature, which lets Chrome verify the package and derive a stable extension ID. Ignore that header and it is an ordinary ZIP.

References