How to Publish a Chrome Extension to the Chrome Web Store (2026 Guide)

You built a Manifest V3 extension. The next job is to publish a Chrome extension so real users can install it from the Chrome Web Store. That path is separate from your product backend: Google runs registration, review, listing assets, and distribution even when your SaaS billing lives on Stripe or Lemon Squeezy.

Google Search Console already sends turbostarter.dev hundreds of impressions for queries like "chrome web store developer dashboard" and "chrome extension developer dashboard," mostly to our Chrome publishing docs. This post is the broader, tool-agnostic walkthrough those docs complement. If you are shipping web, mobile, and extension from one monorepo, pair it with cross-platform SaaS architecture and versioning across surfaces.

Who this guide is for

You have a working extension build (popup, content scripts, or both) and you want it live on the public store, unlisted for beta testers, or private to trusted Google accounts. You do not need a separate backend guide here, though production extensions almost always talk to an API. TurboStarter's extension kit docs cover auth and deployment; this article focuses on Google's publishing pipeline.

Chrome Web Store developer account and dashboard

Register and pay the one-time fee

Before any upload, you must register as a Chrome Web Store developer and pay a one-time registration fee. Google's developer agreement describes the fee as an amount determined in Google's sole discretion (Developer Agreement); Google's extension release notes and dashboard onboarding describe a $5 registration fee for a new publisher account (What's New).

Pick a developer email you check often. Google sends rejections, takedowns, and policy warnings there. You cannot change the account email later without transferring items to a new account (register guide).

Registration opens at the Chrome Web Store Developer Dashboard. The first visit walks you through the developer agreement and payment. After that, the dashboard is your home for every extension you own.

Complete publisher profile settings

After payment, finish account details Google shows in the dashboard:

• Publisher name (shown under extension titles; verified publishers can display an official URL on listings).
• Verified contact email (required for new accounts; used for notifications).
• Physical address when you sell in-app purchases, subscriptions, or other paid functionality through the store (register guide).

Group publishers and team access

You do not need a separate Google Group anymore. Publisher members can be invited with roles (Viewer, Item Manager, Editor, Admin). Invited members can join without paying another registration fee (role expansion blog). Creating an additional publisher still requires a fully registered developer account.

Use the publisher switcher in the top-right of the Developer Dashboard if you belong to multiple publishers.

Prepare your extension package

Manifest V3 and manifest hygiene

New extensions on the Chrome Web Store use Manifest V3. Your uploaded zip must include manifest.json at the root, not inside a subfolder (prepare guide).

Before the first upload, double-check manifest fields you cannot edit later in the dashboard UI without shipping a new version:

Start with a low version such as 0.0.0.1 so you have room to iterate (prepare guide). JSON comments break uploads with "Cannot parse the manifest" errors.

Zip the build output

Zip only the packaged extension files (manifest, scripts, assets). Maximum package size is 2 GB; larger zips are rejected (publish guide).

If you use a bundler like WXT, run your production build first, then zip the output folder the tool documents. TurboStarter maps package.json version into the manifest on build (extension versioning recipe).

Permissions, single purpose, and remote code

Chrome reviewers read your Privacy practices tab alongside the manifest.

• Request the minimum permissions your feature needs (privacy fields).
• State a clear single purpose that matches what the extension actually does (Extension Quality Guidelines).
• Declare remote code honestly. Manifest V3 disallows remotely hosted executable code; extensions that execute remote code face longer review (privacy fields).

Broad host permissions (<all_urls>, *://*/*, https://*/*) are common rejection drivers because they enable wide data access (review process).

Privacy policy and data disclosures

You need a privacy policy URL on your developer account and consistent data use checkboxes in the Privacy tab (privacy fields). Disclosures must match what users see on the listing and what your extension collects.

Store listing graphic assets

The Store listing tab needs assets beyond manifest icons (listing guide):

Manifest icons and store icons serve different jobs. Ship crisp screenshots that show the popup or in-page UI, not just your logo.

Submit a Chrome extension step by step

Upload the zip

1. Open the Developer Dashboard.
2. Sign in with your developer account.
3. Click Add new item.
4. Choose your zip file and upload (publish guide).

If the manifest and zip validate, the new item appears in your dashboard list.

New publisher limit: first-time publishers are capped at two published extensions until they request an increase (publish guide). Themes are excluded from that cap.

Fill out dashboard tabs

Work through the left-hand sections (publish guide):

• Package: shows the uploaded bundle (read-only right after create).
• Store listing: description, category, language, graphics.
• Privacy practices: single purpose, permission justifications, remote code, data use.
• Distribution: visibility, regions, paid-item declaration.
• Test instructions: optional credentials for reviewers.

Visibility: public, unlisted, or private

On the Distribution tab (distribution guide):

Private trusted testers are email addresses tied to Google accounts, configured in account settings (distribution guide). All visibility modes go through the same review process.

Geographic distribution

Choose All regions or specific countries (distribution guide). You can also select all regions then exclude individual countries.

Deferred publishing and staged rollout

When you click Submit for review, a confirmation dialog lets you defer publishing so the item does not go live automatically after approval (publish guide). You can also pick Defer publish from the item menu later.

After review completes, you have up to 30 days to publish a deferred submission. After that, it reverts to draft and must be submitted again (publish guide).

Percentage rollout: if your item has more than 10,000 seven-day active users, the Chrome Web Store API supports setPublishedDeployPercentage to ramp visibility gradually.

Send to review

Click Submit for review when listing, privacy, and distribution tabs are complete. Track status in the dashboard (Published, Pending, Rejected, Taken Down) (Chrome publishing docs).

Chrome extension review time and rejections

How long review takes

Google's review process documentation states:

• For most extensions, review completes within a few days.
• It can take up to a few weeks.
• If an item stays pending more than three weeks, contact developer support.

Review load, permission breadth, code size, and prior rejections can lengthen queues. New developers, new extensions, dangerous permissions, and large code changes are called out as signals for closer inspection (review process).

Common rejection themes and fixes

Rejections email the publisher address with policy references (review process). Fix issues, increment version, upload a new zip, and submit again. See troubleshooting violations.

Update an existing Chrome extension

Every new upload needs a higher version in manifest.json than the last accepted build (prepare guide). Upload the zip on the same dashboard item, update listing or privacy fields if permissions changed, add release notes, and submit for review again.

TurboStarter's extension updates doc recommends bumping package.json version and following the same checklist you used for the first ship.

Breaking permission changes often require manual metadata updates even when CI uploads the bundle (Chrome publishing docs).

Automate publishing with the Chrome Web Store API

Manual first upload is still required so Google assigns an extension ID and you can complete listing metadata (Chrome publishing docs). After that, automate with the Chrome Web Store API:

1. Enable the Chrome Web Store API in Google Cloud.
2. Configure OAuth consent and create OAuth client credentials.
3. Obtain refresh and access tokens with scope https://www.googleapis.com/auth/chromewebstore.
4. Call REST endpoints with your publisher ID from Publisher settings in the dashboard.

Prerequisites from Google (using API):

• 2-Step Verification on the Google account that owns the items.
• Store listing and Privacy tabs completed before API publish.

Typical flow: upload a new package, then publish to submit for review. Use fetchStatus while uploads process, and cancelSubmission if you need to stop an in-flight review (using API).

CI example (GitHub Actions + WXT)

TurboStarter documents a .github/workflows/publish-extension.yml workflow that runs npx wxt submit with Chrome secrets (CHROME_EXTENSION_ID, CHROME_CLIENT_ID, CHROME_CLIENT_SECRET, CHROME_REFRESH_TOKEN) (Chrome publishing docs). Token setup guides such as Plasmo BMS Chrome tokens walk through OAuth refresh tokens.

Use --chrome-skip-submit-review when you only want upload without sending to review (Chrome publishing docs).

Also ship to Firefox and Microsoft Edge

Chromium stores share packaging concepts, but each marketplace has its own account and review:

Cross-browser builds are why TurboStarter uses WXT in the Core monorepo (WXT + Vite extension stack).

How TurboStarter fits in

TurboStarter Core is a production-ready SaaS starter kit across Next.js web, Expo mobile, and a WXT browser extension on one Better Auth backend. Publishing is not a separate product: you get build scripts that output store-ready zips, shared API types, and docs that mirror the steps in this article.

What the kit actually documents today:

• Manual and automated Chrome publishing, including the first-upload requirement and GitHub Actions secrets (Chrome Web Store).
• Pre-submission checklist covering database, API URL, assets, and store accounts (publishing checklist).
• Version bumps via package.json before each store upload (updates).
• Firefox and Edge parallel guides when you expand beyond Chrome.

Use this blog post for policy context and official links. Use /docs/extension/publishing/chrome when you are inside the repo running builds and workflows. If you are still evaluating kits, see Core pricing and the extension stack page.

FAQ

Takeaway

Publish a Chrome extension by treating the Chrome Web Store as its own release channel: register once, ship a clean MV3 zip, be precise about permissions and privacy, choose visibility and regions deliberately, and plan for review that may take days or weeks. Automate only after the first manual submission passes review. If you want the extension client already wired to your SaaS backend, TurboStarter Core ships the WXT app, store docs, and CI patterns so you can focus on the product inside the popup, not on rediscovering Google's dashboard labels every release.