How to Read a Chrome Extension Manifest

Where to find manifest.json

Chrome requires manifest.json at the root of every extension, as its manifest reference explains. If you downloaded a ZIP source package, extract it and open that file as text. Don't edit your only copy.

Need the package first? Paste a public store URL into CRXFile and choose Download source .zip. Our source inspection guide covers extraction. CRXFile fetches currently available public packages; it doesn't provide a local file uploader, an online manifest viewer, or historical versions.

Check name against the listing you intended to download. If it contains a placeholder such as __MSG_extensionName__, look in _locales and use default_locale to find the default translation. Chrome's localization reference explains these placeholders. Keep the store URL and extension ID with it, because different publishers can use similar names.

A Chrome extension manifest example

This is the complete manifest from our original Source Review Demo ZIP. The sample saves the title of an example.com page and displays it in a popup. We put the annotations below the JSON so you can copy valid JSON without comments or trailing commas.

Chrome requires name alongside the two version fields. A Chrome Web Store submission also needs a description and icons. We left them out of this demo because it isn't a store submission.

{
  "manifest_version": 3,
  "name": "Source Review Demo",
  "version": "1.0.0",
  "permissions": [
    "storage"
  ],
  "background": {
    "service_worker": "worker.js"
  },
  "content_scripts": [
    {
      "matches": [
        "https://example.com/*"
      ],
      "js": [
        "content.js"
      ]
    }
  ],
  "action": {
    "default_popup": "popup.html"
  }
}

We checked this teaching sample's JSON and referenced files on October 18, 2026. This was a static file check, without installing it in Chrome.

manifest_version vs version

These fields answer different questions. manifest_version is a number identifying Chrome's manifest format. version is the extension's release string. An extension can use Manifest V3 and have version 12.4.0.

Save version in your review notes. Chrome accepts one to four dot-separated integers here, and uses them for update comparisons. An optional version_name such as 1.0 beta is a display label. See Chrome's version rules if a downloaded package and its store listing appear to disagree.

Read permissions alongside site access

Use our Chrome extension permissions guide for a field-by-field review table covering API access, host patterns, optional grants, and the questions to ask about each declaration.

Start with permissions. In the demo, storage matches the code that saves a page title. For another package, find each requested API in the scripts and ask which feature needs it.

Then check host_permissions and content_scripts.matches. API permissions and website access are separate parts of the review. A declared content script can run on its matching pages without a duplicate host_permissions entry. Our demo does exactly that.

Read the host patterns literally. Access to https://example.com/* is narrower than https://*/*. For broad patterns, write down the feature that needs them and follow the relevant code. Users can withhold site access, as the permissions API reference describes, so declared access and currently granted access may differ.

Optional access goes in optional_permissions or optional_host_permissions and requires a runtime grant. activeTab provides temporary access after a qualifying user action. Neither a short permission list nor broad access proves how an extension uses data. Chrome's permission guide and activeTab reference explain those distinctions.

Find the background service worker

Follow background.service_worker to its JavaScript file. In Manifest V3, this is an event handler that Chrome can start when needed and stop when idle. Don't assume it runs continuously.

Open worker.js in the demo and find the message listener and storage write. In a larger extension, follow imports and look for installation handlers, alarms, and network calls. A type value of module in the background object permits static JavaScript imports. Chrome documents worker registration and the worker lifecycle separately.

Check where content scripts run

Read each content_scripts entry as a rule connecting files to pages. Our https://example.com/* match covers HTTPS paths on that exact host. It doesn't include its subdomains or HTTP pages. Chrome's match pattern guide explains wildcards and <all_urls>.

Check js and css for the files to open. Then read run_at and all_frames. If omitted, the defaults are document_idle and false: injection after the DOM is complete, in the top frame. Extensions can also register or inject scripts programmatically, so search for chrome.scripting before treating this list as complete. The content script reference covers these settings.

To follow the code beyond these declarations, see how to trace an extension's content scripts, with a DOM example and a URL matching table.

Follow the remaining file paths

Open action.default_popup as text, then read the scripts that HTML file loads. Check options_ui.page and side_panel.default_path if present. Paths are relative to the extension root, so a missing file deserves a note.

Two less familiar fields also deserve attention. Web-accessible resources declare packaged files that matching web pages or extensions can access. Content security policy restricts resource loading and script execution in extension contexts. Neither field substitutes for reading the code.

Keep notes tied to the package

Record the extension ID, version, review date, and unresolved questions. Our package backup workflow includes a record template. For each question, name the manifest field and the file you need to read next. That makes a note like “Why this host?” useful to the next reviewer, even after the extension updates.