How to Launch a Chrome Extension (2026)

Set Up Your Developer Account

A Chrome extension launch has two parts: getting through the Chrome Web Store, then getting people to your listing. The first takes longer than most makers expect, so start a week or two before you plan to announce.

To publish, you register as a Chrome Web Store developer in the developer dashboard, agree to the developer agreement and pay a one-time registration fee, as Chrome's registration docs explain. The dashboard shows the current fee when you sign up. Two details catch people out:

• The account email is permanent. You can't change it after the account is created, so Chrome suggests a new address used only for publishing, and one you check often.
• 2-Step Verification is required. Your Google account needs it before you can publish an extension or update one (Chrome's policy).

Before you open the dashboard, have these ready:

1. A ZIP of the extension, built the way users will get it. Test the packed version, not only the unpacked folder: Chrome's troubleshooting guide lists packed builds that behave differently, and file names whose case doesn't match the manifest, among the reasons extensions fail review.
2. A 128×128 icon inside the package, plus at least one screenshot (sizes below).
3. A privacy policy URL, a website and a support page or email address.
4. Test instructions and a working test account if reviewers need to sign in to see what the extension does.

A Store Listing That Converts

Your store listing does the same job as any launch listing: tell the right person, in a few seconds, what the extension does and that it's real. Chrome's listing best practices give the specifics:

• Title: make the core function clear. A short, unique name beats a string of keywords.
• Summary: 132 characters or less, plain text. Say what it does and where. "Turns any GitHub pull request into a one-page summary" gets read; "The best productivity extension" gets skipped.
• Description: an overview paragraph, then a short list of the main features. Chrome's listing requirements say a product with a blank description, or a missing icon or screenshots, will be rejected, and the keyword spam rules give "unnatural repetition of the same keyword more than 5 times" as an example of what's not allowed.
• Website and support URLs: fill in both. They help people trust a developer they've never heard of.

The images, from Chrome's image guidelines:

Make the first screenshot the extension doing its main job on a real-looking page, not a settings screen. Chrome asks for full-bleed screenshots with square corners and no padding, showing the actual experience with little text. Promo images shouldn't carry claims like "Editor's Choice" or "Number One". The small promo tile matters more than its "optional" label suggests: the image guidelines say extensions without one are shown after those that have it.

Our guide to writing a launch listing people click covers the wording in more depth, and the launch asset resizer crops screenshots for launch boards.

Permissions and Privacy Disclosures

Permissions are where many extension launches go wrong, both in review and with users who read the install warning and close the tab. Ask only for what the extension uses today.

• Avoid broad host access if you can. Patterns like <all_urls> and *://*/* get closer examination, according to Chrome's review process docs. If the extension only works on a few sites, list those sites.
• Request extras when they're needed. Chrome recommends requesting permissions at runtime, which lets users choose which features they want to enable.

The dashboard's Privacy practices tab asks for six things:

1. A single-purpose description. The extension must have "a single purpose that is narrow and easy to understand", so a toolbox of unrelated features won't pass.
2. A justification for each permission in your manifest.
3. Whether you use remote code. Under Manifest V3, running code from outside the package, such as remote scripts or fetched strings passed to eval(), gets an extension rejected.
4. The types of user data you collect.
5. Certification that you follow the limited use policy.
6. A link to your privacy policy.

Chrome's program policies say that if your product handles any user data, you must post an accurate and up-to-date privacy policy, and you may only collect the data your single purpose needs. Write a policy that matches what the code actually does, and keep it consistent with your disclosures. The privacy policy generator gives you a first draft to edit.

The Review and Common Rejections

Every new extension and every update is reviewed. Chrome's review docs say that "for most extensions, review is completed within a few days, but it can take up to a few weeks", and to contact developer support if a submission has been pending for more than three weeks. New developers, new extensions, sensitive permissions, broad host access and large or hard-to-read code all draw closer review. Minified code is allowed; obfuscated code isn't.

The most useful setting for a planned launch is deferred publishing. When you submit, untick the option to publish automatically. Once review passes, you have up to 30 days to publish whenever you choose; after that, the submission reverts to a draft (Chrome's publishing docs). That lets you submit early and still pick your launch day.

Chrome's troubleshooting guide gives each violation a code name, which is what your rejection email will mention. The ones worth checking before you submit:

A rejection email names the policy and how to appeal, and a listing that's already live isn't affected. Fix the issue and resubmit, or use the Appeal button on the item's dashboard page if you think the reviewer got it wrong.

Where Extension Makers Launch

Publishing isn't a launch on its own. The store's homepage picks are chosen by editors and can't be bought, and search ranks items partly on ratings and usage, which a new extension doesn't have yet (how discovery works). Your first users will mostly come from links you share outside the store:

1. Product Hunt ranks launches over a single day, so it suits makers who can bring people with them on the day.
2. Show HN for extensions that developers will use. Read our Show HN guide first.
3. DevHunt, a weekly launchpad for developer tools, if your extension is one.
4. Communities such as r/SideProject, Indie Hackers and subreddits about the sites your extension works on. Read each one's self-promotion rules first; our Reddit launch guide explains how.
5. Launch boards with longer windows, such as Peerlist and Hauntboard, where a person reviews each launch, it spends 7 days in New this week, and its page views and visits are shown in public.

Decide where your links point. Linking straight to the store listing removes a step. Linking to your own site lets you explain more, collect emails and send people to the store with one clear button.

Either way, tag your links. If you opt in to Google Analytics from the Store listing page in the dashboard, UTM parameters on your listing URL are forwarded to Google Analytics along with page views and installs. The UTM builder makes one link per channel, and our list of places to launch has more to work through.

Getting First Users and Reviews

Ratings matter twice for an extension. People read them before installing, and Chrome's ranking uses ratings and usage, such as downloads compared with uninstalls over time. So a smaller number of installs that stick can be worth more than a burst that's removed the next day.

• Make the first minute count. Open a short welcome page on install that shows the one action to try first. If people can't see what it does, they have no reason to keep it.
• Ask at the right moment: after the user has had value from it, for example after the tenth summary, not on install.
• Never buy or trade reviews. Chrome's spam policy bans inflating ratings, reviews or installs through "fraudulent or incentivized downloads, reviews and ratings". Ask real users for honest reviews.
• Reply to reviews, especially critical ones. Chrome's user feedback docs note that users aren't notified of replies and that you can't remove reviews, so write each reply for the next person reading the listing.

A short in-extension prompt that respects the user:

For your very first users, reach out one by one to people who have described the problem your extension solves. The outreach generator drafts those messages, and our guide to the first 100 users covers where to find them.

Two badges help later. The Established Publisher badge is granted automatically once your identity is verified and you've built a good track record, which takes at least a few months. You can also nominate a published, public extension for the Featured badge through One Stop Support, currently a trial.

Updating Safely After Launch

Launch week brings bug reports, and you'll want to ship fixes quickly. Every update goes through review again, each one needs a higher version number, and the published version stays live until the new one is out (Chrome's update docs). Three rules worth knowing before your first update:

1. New permission warnings disable the extension. If an update adds a permission that triggers a warning, Chrome disables the extension until the user accepts it, so it stays off for anyone who doesn't. Add new access as optional permissions where you can.
2. Partial rollout comes later. Rolling an update out to a percentage of users is only available once the extension has over 10,000 seven-day active users. Until then, every update reaches everyone, so test the packed build each time.
3. Warnings come with a deadline. If a published version breaks a policy in a minor way, you're typically given 7 to 30 days to fix it before it's taken down.

Watch reviews and support messages closely for the first couple of weeks, and batch small fixes rather than shipping one a day, since each update waits in review. Then read what to do after launch day for the weeks that follow. Once it's live in the store, launch it on Hauntboard for a permanent page that other makers and search engines can find.