Chrome Web Store Submission Checklist: Register, Package, Fill In, Submit

Where do these steps come from?

Every fact below was read on 13 November 2026 from Google’s Chrome Web Store documentation: publishing, registering, setting up an account, preparing an extension, the store listing tab, the privacy tab, the distribution tab and the review process. Google states that its enforcement practices are subject to change without notice, so confirm the current wording before you upload.

This page is the order of work, with the reason for each step. Image sizes get a page of their own in Chrome Web Store listing assets, and the build side is in the guide to building a Chrome extension. Where to promote the extension once it is live is covered in where to launch Chrome extensions.

Which account decisions are hard to undo?

Registration looks like a formality, but two of its choices stay with you. Google’s registration page says the developer email cannot be changed after the account is created, and that someone who recently deleted an account cannot reuse its email identity to create a new one. Moving an item to a different account needs a transfer request. So choose carefully on day one.

1. Create or pick an email address that you will check often and that is not tied to one person’s job; Google suggests a new address used only for publishing, because that is where take-down and rejection notices arrive.
2. Open the Developer Dashboard, agree to the developer agreement and policies, and pay the one-time registration fee. The page does not state the amount, so read it on the registration screen before you pay.
3. Confirm your country or region is on the supported list. Google’s page says it cannot accept registrations or submissions from places that are not listed.
4. On the Account page, set a publisher name, since it appears under “Offered by” on your listing, and verify your contact email using the link Google sends.
5. Add a physical address only if your extension sells items, extra features or subscriptions; Google says only those need one.
6. If you want friends or testers to install a private build, list their Google Account emails under Trusted testers. Google’s page says group addresses do not work there.
7. Turn on email notifications on the Account page if you want a message when the item is published or staged; rejection and take-down emails are on by default.

How do you prepare the zip so the upload does not fail?

1. Load the extension unpacked in Chrome and exercise every feature before you package it, because a fix after upload means a new version number.
2. Check the manifest fields Google lists: name, version, icons and description. The description is a string of no more than 132 characters.
3. Treat the manifest as final, since you cannot edit its metadata in the dashboard after upload; a typo means editing the file, raising the version and zipping again.
4. Start the version at a low number and raise it on every upload, because each version must be larger than the one before.
5. Remove any comments from the manifest JSON. Google names comments as the usual cause of a “Cannot parse the manifest” error.
6. Zip the extension with manifest.json in the root of the zip and not inside a folder. The package limit is 2GB.

Then, in the dashboard, choose Add new item, pick the zip and upload. If the manifest and zip are valid you land on the item’s edit page.

Which dashboard tab needs what?

Write the first sentence of the description as a plain statement of what the extension does, since Google’s guidance is to start with that and then add detail. Keep the text honest and free of keyword lists, because Google points to its keyword spam policy.

How do you keep permissions from slowing the review?

Review time is the part you can influence most. Google’s review page says reviews take longer for extensions that request broad host permissions such as *://*/*, https://*/* or <all_urls>, or sensitive permissions such as tabs and downloads, and for extensions that contain a lot of code or hard-to-review code. It also says obfuscation is disallowed, and that minified code is allowed but harder to review. A privacy tab that says why each permission exists, in words a human reviewer can check, is part of the answer.

The practical rule is to ask for the narrowest access that makes the single purpose work. If your extension only acts when the user clicks its icon, say so and use a narrower grant than a blanket host permission. If you do not need a permission, remove it from the manifest and upload a new version before continuing, as the privacy tab itself instructs.

SINGLE PURPOSE
This extension [does one thing, in one sentence], for example "saves the current page as a clean reading note".

PERMISSION JUSTIFICATIONS
storage: Saves the user's notes and settings on their own device. No data leaves the browser.
activeTab: Reads the page the user is viewing only when they click the extension icon, to extract the text to save.
[permission]: [what it is used for, when, and why a narrower option would not work].

REMOTE CODE
No, I am not using remote code. All code ships in the package.

DATA USE
Collected: [list the data types, or "none"]. Used only for [the single purpose]. Privacy policy: [URL].

What happens between Submit for Review and going live?

1. Press Submit for Review and read the confirmation dialog. Leave the publish-after-review box ticked if you want it to go live automatically.
2. Untick that box if you want to choose the moment. Google says that once review finishes you have up to 30 days to publish, after which the staged submission reverts to a draft that must be reviewed again.
3. Expect most reviews to finish within a few days, with some taking up to a few weeks. Google says to contact developer support if an item has been pending for more than three weeks.
4. Understand why yours may be slower: Google lists new developers, new extensions, dangerous permission requests and significant code changes as signals that make a reviewer look more closely.
5. If you find a bug after submitting an update, use cancel review to upload a corrected package instead of waiting.
6. If it is rejected, the email names the policy you violated and how to appeal. The published listing is unaffected by a rejected update.

Plan the launch around the review, not the other way round: submit at least two to three weeks before any date you have promised to anyone, and do not announce until the item is published.

What can you skip, and what costs the most time?

• Skip the promo tiles at first. Google marks them optional; add them once the listing works.
• Skip a public beta in the main listing. If you publish a test version beside the real one, Google says to add BETA or DEVELOPMENT BUILD to the name and “THIS EXTENSION IS FOR BETA TESTING” to the description, or both may be taken down.
• Mistake: asking for host access you do not use. Google lists broad host permissions as a factor that lengthens review.
• Mistake: forgetting the privacy policy link when you collect any user data.
• Mistake: no test credentials for a feature behind a login.

When the extension is live, list it where its users look. You can launch your product free on this board, add the Chrome Web Store link and say plainly what it does. For ideas that suit the browser, see the Chrome extension ideas guide and the ideas board.