Originally published on ExtensionLaunch.

To publish a Chrome extension, you need more than working code: the Chrome Web Store reviews your manifest, your permissions and your privacy answers before anyone can install it. Most first submissions that stall do so for avoidable reasons.

Below are the six steps from developer account to first update, plus the checklist I'd run before pressing Submit.

What to have ready before you open the dashboard

Gather these first so you aren't hunting for assets mid-form:

  • A Google account (for anything beyond a hobby project, use a dedicated or Google Workspace account)
  • An extension built on Manifest V3 (new Manifest V2 submissions are no longer accepted)
  • A 128x128 PNG icon
  • At least one screenshot at 1280x800 or 640x400
  • A one-line summary, a longer description and a category
  • A privacy policy URL if you handle user data (most extensions do)
  • $5 for the one-time registration fee

Steps 1 to 3: account, manifest, package

1. Register as a developer. Sign in to the Chrome Web Store Developer Dashboard, pay the one-time $5 USD fee and verify your contact email. If you publish under a brand, set up a group publisher. You'll also have to declare whether you're a trader or a non-trader.

2. Tighten your manifest. Reviewers check your package against manifest.json, and two fields matter most: version and permissions. Over-broad permissions are the most common reason a first submission stalls.

  • Request only the permissions your code actually calls
  • Scope host permissions to specific domains instead of <all_urls>
  • Use activeTab when you only need page access after the user clicks

A lean MV3 manifest looks something like this:

{ "manifest_version": 3, "name": "My Extension", "version": "1.0.0", "description": "One clear sentence about what it does.", "icons": { "16": "icon16.png", "48": "icon48.png", "128": "icon128.png" }, "action": { "default_popup": "popup.html" }, "permissions": ["storage"], "host_permissions": ["https://*.example.com/*"] }

3. Zip the right folder. manifest.json must sit at the root of the ZIP, not inside a parent folder. If you use a bundler, zip the build output, not your source. From inside the output directory:

zip -r ../my-extension.zip . -x "*.git*" "node_modules/*"

Steps 4 and 5: listing, privacy and visibility

4. Fill in all three tabs. After uploading the ZIP, the dashboard asks for:

Tab What it wants
Store listing Name, summary, detailed description, category, language, icon, screenshots
Privacy Single purpose, a justification per permission, data-use disclosures, privacy policy URL
Distribution Visibility, regions, pricing

The Privacy tab is where vague answers hurt. State one clear purpose, explain each permission in plain language and make your data disclosures match what the code and the privacy policy say. If your extension needs a login, fill in the Test instructions tab so the reviewer can actually use it.

5. Pick visibility, then submit.

  • Public: shows up in search and category pages
  • Unlisted: only reachable by direct link, good for a soft launch or beta
  • Private: limited to named testers or your Workspace organization

A new extension usually clears review in a few hours to a few days. Sensitive permissions or a large codebase can stretch that, and there's no way to speed it up, so submit well before any announced launch date.

Step 6: ship updates without new trouble

The update loop is simple: bump version, re-zip, upload the new package and submit. Users get the update automatically over the following hours.

Three rules keep it painless:

  1. Never reuse a version number. Chrome rejects any package whose version isn't higher than the published one.
  2. Keep permissions stable. Adding a sensitive one can trigger a fresh, slower review and re-prompt existing users.
  3. Write real release notes. They build trust with users and show reviewers what changed.

The pre-submit checklist

  • [ ] Manifest V3 with an accurate name and description, and a version higher than the last one
  • [ ] Only permissions you use, each justified in plain language
  • [ ] 128x128 icon and at least one correctly sized screenshot
  • [ ] Privacy policy URL is live and matches your data disclosures
  • [ ] ZIP built from compiled output, with manifest.json at the root

Key takeaways

  • Narrow permissions are the biggest lever for a smooth first review.
  • Zip the build output with manifest.json at the root.
  • Your Privacy tab answers, your code and your privacy policy must agree.
  • Budget hours to days for review and never schedule a launch the same day you submit.
  • Every update needs a higher version number; avoid adding sensitive permissions casually.

Approval is only the starting line. The full step-by-step guide to publishing a Chrome extension on the Chrome Web Store goes deeper on each step, and once you're live you can list it on ExtensionLaunch, a launch platform for browser extensions, to get early installs and feedback.

What was the slowest or most confusing part of your first Chrome Web Store submission, and how did you get past it?