Publishing to the Chrome Web Store: The Full Workflow of Registration, Packaging, and Submission for Review

Goal in one sentence: Publish the local extension you got working in the previous lesson—complete the three steps of publishing a Chrome extension, "register a developer account → package and upload → submit for review," and enter the Chrome Web Store's review queue so that strangers can find and install your extension.

What you'll be able to do after this lesson

• Register a Chrome Web Store developer account and gain access to the developer dashboard
• Package the extension directory into a compliant zip with manifest.json at the root
• Fill in the store listing information across 5 tabs in the dashboard
• Click Submit for Review and let the extension enter the store's review queue

Your current predicament

• "The extension runs, but it only lives in my own browser. When a friend wants it, I have to walk them through enabling developer mode and loading the folder manually over a remote session."
• "I've heard publishing costs money and requires review, but I have no idea how many steps there are or what materials each step needs."
• "My biggest fear is entering wrong information: if I get the account email wrong, is the account ruined?"

When to use this technique

When you need to: distribute the extension to strangers—anyone can find your extension in the Chrome Web Store and install it with one click, without you sending files one by one.

And you don't want to: walk friends through enabling developer mode and loading manually over a remote session; or keep the extension installed only on your own computer forever.

🎒 Preparation before you start

• Completed the prerequisite lesson"Your First Chrome Extension: Hello World in 15 Minutes"—the extension loads properly in the browser and all features work. The official documentation also emphasizes testing features locally before uploading.
• A Google account chosen carefully before use: the email bound to the developer account isnot changeable after creation. The official recommendation is to set up a dedicated new email for publishing, and one you check regularly—important notifications such as takedowns and rejections are sent by email by default.
• Budget for the one-time registration fee; the exact amount is subject to the payment page in the developer dashboard@@I18N_KEEP_000007@@.
• Prepare all extension assets: manifest.json, icons, screenshots, and description copy—there are quite a few required fields across 5 tabs, and making them on the spot will interrupt the workflow.
• Confirm the scope: this tutorial only covers Manifest V3 extensions for the Chrome Web Store; publishing to Firefox or Edge is outside this path.

Core idea

Publishing a Chrome extension is essentially turning "a folder on your computer" into "a product in the store." Each of the three steps handles one thing:

Stage	What you need to do	Output	Most common mistake
① Register	Pay the one-time registration fee and get a developer account	An account that can publish products	The email cannot be changed after creation
② Package	Check the manifest and compress it into a compliant zip	A zip with the manifest at the root	An extra folder layer inside the zip
③ Submit for review	Upload the zip, fill in 5 tabs, and submit	The product enters the review queue	Clicking submit before all required fields are complete

The three steps are sequential: the account is the admission ticket, the zip is the product itself, and the store listing is the shelf display. What the reviewer receives is the combination of these three—any single failure means getting sent back to start over.

Follow along

Step 1: Register a developer account (the first step in publishing a Chrome extension)

Why: Without a developer account, the developer dashboard won't even show you the "Add new item" entry—get this admission ticket first, so the next two steps have somewhere to land.

Open the Chrome Web Store developer dashboard (chrome.google.com/webstore/devconsole) and sign in with a Google account. On first entry, a registration page appears: first agree to the developer agreement and policies, then pay the one-time registration fee@@I18N_KEEP_000008@@. You need to provide a developer email during registration; China is on the list of supported countries/regions.

You should see: After payment, when you return to the dashboard, the registration page no longer appears, and you can see the product list and the "Add new item" button.

• The registration page no longer appears, and the "Add new item" entry is visible in the dashboard

Step 2: Check the manifest and package it as a zip (packaging the extension as a zip)

Why: Once the extension is uploaded, you can no longer change the manifest's metadata in the developer dashboard—even a single typo means editing the file, bumping the version number, and repackaging. So check the manifest before packaging.

Check four things in order:

1. The four fields name, version, icons, and description are all present—name appears in the store and the browser, and description must not exceed 132 characters.
2. Set version to a low value, such as 0.0.0.1—the store requires every newly uploaded version number to be greater than the previous one, so starting low leaves room to increment.
3. No comments may remain in the manifest—comments are a common cause of the "Cannot parse the manifest" error on upload.
4. When compressing, select the filesinside the extension directory before zipping; manifest.json must land at the root of the zip, not inside a subfolder. The package size limit is 2GB, far beyond what an ordinary extension reaches.

You should see: Extract the zip into a temporary directory, and you can see manifest.json directly at the first level.

• Extract the zip, and manifest.json is right at the first level

Step 3: Upload the zip, fill in the store listing information, and submit for review (extension review submission)

Why: The zip is just the product itself—the store also requires you to fill in the "shelf information": users rely on it to decide whether to install, and reviewers rely on it to understand what your extension does.

1. In the developer dashboard, click Add new item, select Choose file to pick the zip you just built, and click Upload. If the zip and manifest are valid, you will enter the item editing page.
2. Fill in the 5 tabs in the left-side menu one by one:
   • Package: information about the uploaded package; this page is not editable on first creation;
   • Store Listing: product details, which determine how the store page is displayed;
   • Privacy: declares the extension's single purpose and how it handles user data;
   • Distribution: whether it is paid, which countries it is listed in, and which users can see it;
   • Test instructions: testing instructions and credentials for reviewers; fill in only when necessary.
3. After all required fields are filled in, click Submit for Review, and confirm again in the confirmation dialog.

You should see: the item status changes to "In review", and your extension appears in the item list in the dashboard.

• 5 tabs' required fields are all filled in, and the status has changed to "In review"

💡 Want to control the release time yourself?

The submission confirmation dialog lets you control the release timing: uncheck that option, and after the review is completed the item will not go live automatically immediately—you can publish it manually at a time of your choosing. When to publish and how to roll back will be covered in detail in the next lesson.

⚠️ New publishers have a quantity limit

When you first create a publisher account, you can have at most 2 published extensions (counted by the number listed; themes do not count toward the quota). The current limit is visible in the developer dashboard; once you reach it you can request an increase, and in most cases you get an answer immediately. Polishing one extension well is better than uploading a bunch at once.

Checkpoint ✅

• The registration page no longer appears, and the "Add new item" entry is visible in the developer dashboard
• The first level after unzipping the zip is manifest.json, and there are no comments in the manifest
• The manifest's four fields are all present, description ≤ 132 characters, and version starts from a low value like 0.0.0.1
• All required fields in the 5 tabs are filled in, and Submit for Review has been clicked
• The item status in the dashboard shows "In review", and the registration email is one you check regularly

Pitfall reminders

❌ An extra folder layer inside the zip

The entire project folder was dragged in when compressing, so manifest.json ended up in a subdirectory.

Reason: the store requires the manifest to be in the root directory of the zip; an extra layer means immediate failure.

Correct approach: select the files inside the extension directory before compressing; unzip the package once before submitting to confirm the first level is manifest.json.

❌ Comments left in the manifest

Upload reports "Cannot parse the manifest".

Reason: the manifest is a JSON file, and comments are a common cause of this parsing error.

Correct approach: remove all comments from the manifest, repackage, and upload again.

❌ Casually entered an email you rarely check

Reason: the email of a developer account cannot be changed after creation; to switch, you can only create a new account and transfer the items over via the official form. Important notices such as takedowns and rejections are sent to this email by default—missing them can cause delays.

Correct approach: think it through before registering. The official recommendation is to create a dedicated new email for publishing and make sure it is one you check frequently.

❌ Starting with a very large version number

Reason: the store requires each newly uploaded version number to be greater than the previous one; moreover, manifest metadata cannot be edited in the dashboard after upload—fixing even a typo requires bumping the version and repackaging. If you start too high, there is no room to grow.

Correct approach: set the first version number to a low value, such as 0.0.0.1.

Lesson summary

Publishing a Chrome extension is three steps: register a developer account → package the zip → submit for review.

• ✅ Registration: a one-time registration fee (the amount is subject to the payment page), and the email cannot be changed after creation
• ✅ Packaging: the manifest's four fields are all present with no comments, manifest.json goes in the zip root directory, and the package size is ≤ 2GB
• ✅ Submission: upload the zip via Add new item, fill in the 5 tabs, and click Submit for Review
• ✅ New publishers can have at most 2 published extensions—focus on polishing one first

Review of key configuration fields:

Field	Recommended value	Notes
manifest.json's version	a low value like 0.0.0.1	Each new version number must be greater than the previous one; starting low leaves room to increment
manifest.json's description	≤ 132 characters	Used for the store listing display, with an upper limit of 132 characters
manifest.json's name, icons	Finalize in advance	Manifest metadata cannot be edited in the dashboard after upload
Zip structure	manifest.json in the root directory	An extra folder layer will fail
Package size	≤ 2GB	Exceeding it will be rejected

Next lesson preview

Submitting is only the beginning: how long does the review take, how can you improve the approval rate, and how do you fix things after a rejection? Continue with "Store Review and Publishing Strategy: Review Within 3 Days, Staged Rollout and Rollback".

You will learn:

• The store review process and approximate timeline
• What preparations can improve the approval rate
• Fixes and resubmission after a rejection
• How to do staged rollout and rollback

If you are going the WeChat Mini Program route, you can refer to "Submission for Review and Publishing: A Guide to Avoiding WeChat Review Rule Pitfalls".