How to Launch a Chrome Extension for Free: Plan Around the Store Review

Why does the Chrome Web Store set your launch date?

Most people install an extension from the store, and the store lists nothing until a reviewer has looked at it. That makes the review queue the one part of the launch you cannot schedule yourself. Google’s own documentation says review is completed within a few days for most extensions but can take up to a few weeks, and that times fluctuate with how many submissions are waiting (read on 13 November 2026).

The same page names what slows a review down: broad host permissions, sensitive execution permissions, a lot of code, and code that is hard to read. If your idea only needs to run on one site, ask for that site and nothing wider. A narrow permission list is the cheapest speed-up on offer, and it also makes the install prompt less alarming to the people you want.

What does the listing need before you press Submit?

The store asks for a few images, and each has a fixed size. The icon must be 128 by 128 pixels inside your extension package, with the actual artwork at 96 by 96 and the remaining margin left empty, because Google warns that the store may add its own edge. Screenshots are 1280 by 800 or 640 by 400, full bleed with square corners and no padding. Google notes that the larger size looks better on high-resolution screens. The full list is in our Chrome Web Store listing assets reference.

Beyond the images, the part that trips people up is the single-purpose rule. Google’s quality FAQ says an extension must do one thing, either in a narrow subject area such as news headlines or in a narrow browser function such as tab management, and that permissions unrelated to that purpose count as a violation. A tab manager that also asks to read every page is the standard way to fail it.

• A one-sentence purpose you can say without “and”. If it needs “and”, you may be shipping two extensions.
• A permission list you can justify line by line, written down before the reviewer asks.
• Three to five screenshots showing the extension working on a real page, not a mock-up of an empty popup.
• A support address that reaches you, since the listing page is where unhappy users go first.

Which visibility setting fits which stage?

The dashboard lets you choose who can see an item, and the three settings map neatly onto three stages of a launch. The wording below follows Google’s distribution page.

One detail matters for timing. When you submit, you can choose to publish automatically after review or to defer. A staged submission waits for you to press the button, but it expires after a period the dashboard shows and then reverts to a draft. Deferred publishing is how you pass review on a Tuesday and still launch when you have answered your first twenty emails.

What does a 21-day plan look like?

1. Day 1 to 7: build the one purpose. Cut every feature that needs a new permission. Write the listing text and capture screenshots on a real site as you go.
2. Day 8: submit as unlisted with deferred publishing. You are buying review time, not announcing anything. If the reviewer rejects it, you learn that now, not on launch day.
3. Day 9 to 14: test through the unlisted link. Send it to five people who actually have the problem. Fix what they hit by uploading a new package; if you spot a bug right after submitting an update, Google’s publish page says to cancel the review first and upload again.
4. Day 15 to 17: switch to the final listing. Set visibility to public in a deferred submission and let it pass review.
5. Day 18: publish and announce. Post where tools like yours are discussed and launch your product free on a board that has no queue.
6. Day 19 to 21: answer every comment and review, then read the install numbers in the dashboard.

Where should an extension be announced, and where not?

An extension is an unusually easy thing to show. A Show HN post suits it, because the guidelines ask for something others can try, ideally without sign-ups. Install, click, see the result: that is the whole test. The Show HN playbook covers how to write the post. The same guidelines call blog posts, sign-up pages and newsletters off topic, so a post that links only to a landing page will not qualify.

Beyond that, go where the target site’s own users gather. An extension that improves a spreadsheet tool belongs in that tool’s community, not in a general maker feed. The places that suit extensions are listed separately, and the ideas board is a good place to see which extension problems other builders have already named. If you still need a concept, the Chrome extension ideas guide is a start.

On this site a launch takes one email. You fill in the name, address and description, open the emailed link, and it is public at once, with no queue and no paid placement. Your outbound link is a normal followed link. You bring your own traffic, since the audience here is still small.

Which mistakes cost a review cycle?

• Asking for every site because it is easier. It makes review slower and the install prompt scarier, as described above.
• Shipping a surprise on launch day. A late change goes back into review, and you cannot announce a version people cannot install.
• Measuring installs without a source. The store does not carry your UTM tags. Send people to a one-page site first, tag that link, and let the page forward to the store. The UTM tagging guide shows the pattern.
• Leaving the listing text for later. The store page is your landing page, and people who arrive from a post read it before they install.

How do you read the first week?

Look at three numbers and nothing else: installs that came from your tagged page, how many of those people are still using the extension after three days, and the number of reviews or support emails that name a specific bug. Installs alone are cheap. A small group that keeps the extension active tells you the purpose is right.

If installs are fine and retention is poor, the listing promised something the extension did not do. If both are low, the problem is reach, and a second round of announcements in the right community is worth more than a redesigned icon. Write what you changed and the date next to each number, as the launch metrics checklist suggests, so the next release has something to be compared with.