Understand the header before extracting

CRX2 and CRX3 use different headers. CRX3 stores a little-endian header length after the magic bytes and version, followed by a signed header and then the ZIP. CRX2 stores public-key and signature lengths. Cutting at the wrong offset produces a corrupt archive.

The analyzer validates these boundaries and checks that the remaining bytes begin with a ZIP signature. It also enforces entry and size limits before decompressing.

Related pages:CRX3 structureCRX package analyzer

Two safe ways to inspect the contents

The simplest method is to upload the CRX to this analyzer. It shows the manifest and findings in a readable report without installing anything. No command line or extension developer mode is required.

If you prefer local tools, use a script or archive utility that understands the CRX header, then inspect the extracted files with a text editor. Treat the extracted JavaScript as untrusted text and do not open HTML files in a browser with the extension's scripts.

  1. 1

    Obtain the CRX

    Download it from the store or get it from the publisher.

  2. 2

    Strip the header

    Parse the version-specific header and locate the ZIP signature.

  3. 3

    Extract the ZIP

    Use an isolated folder and avoid executing any extracted code.

  4. 4

    Inspect manifest and code

    Read permissions, scripts and domains, or use the analyzer report.

Related pages:CRX file analyzer online freeview manifest online

Safety rules for unpacking

Never run an extracted script to see what it does. Do not load the unpacked folder as an extension in developer mode unless you accept the risk. Keep archive extraction inside a dedicated folder and avoid opening files that could trigger a local handler.

If the package contains nested archives, the analyzer skips them. You should be equally cautious: nested content is not part of the reviewed manifest and can hide additional files.