How to Publish a Chrome Extension in 2026

To publish a Chrome extension, you package your extension's code into a ZIP file, upload it to the Chrome Web Store through Google's developer dashboard, fill out a store listing, and submit it for review. That's the whole idea in one sentence. The details, though, are where most first-time developers get stuck — so this guide walks through how to publish a Chrome extension in 2026, step by step, including the parts that usually trigger a rejection and what to do the moment your listing goes live.

What do you need before publishing a Chrome extension?

Gather everything on this list before you open the developer dashboard. Publishing goes much faster when you are not scrambling for a screenshot at the last minute.

• A working extension on Manifest V3. The Chrome Web Store only accepts new Manifest V3 submissions — Manifest V2 has been phased out. Test your extension locally by loading it unpacked via chrome://extensions before you even think about uploading.
• A Google account. You will use it to register as a Chrome Web Store developer. Consider a dedicated account if you plan to publish for a team or company.
• A small one-time registration fee. Google charges a one-time fee when you register your developer account. It is modest, and you only pay it once — it covers all future extensions you publish.
• Icons and screenshots in the right sizes. You need a 128x128 store icon, at least one screenshot at 1280x800 (or 640x400), and optionally a small promo tile at 440x280. Blurry or letterboxed images make a listing look abandoned, so it is worth doing these properly — our guide to extension icons covers every size Chrome asks for and how to produce them, and Google documents the store image requirements in its listing image guidelines.
• A privacy policy, if you handle user data. If your extension collects, transmits, or stores any user data — even just an email for login — you must link to a hosted privacy policy. A simple page on your own domain is fine.

How to publish a Chrome extension, step by step

Here is the full path from finished code to a live store listing. At the time of writing, this is the documented Chrome Web Store process — Google tweaks the dashboard occasionally, but the shape of it has been stable for years.

1. Register your developer account. Go to the Chrome Web Store Developer Dashboard, sign in with your Google account, accept the developer agreement, and pay the one-time registration fee. This takes a few minutes.
2. Prepare the ZIP. Zip the folder that contains your manifest.json — the manifest must sit at the root of the archive, not inside a nested folder. Strip out anything the extension does not need at runtime: source maps, tests, node_modules, design files. Smaller packages review faster and raise fewer questions.
3. Create the item in the developer dashboard. Click "New item", upload your ZIP, and the dashboard creates a draft listing with a permanent extension ID. From here on, every update you publish keeps that same ID.
4. Fill out the store listing. Write your title, a short summary (this is what shows in search results, so make it count), a detailed description, pick a category, and upload your screenshots and icons. The summary and title carry real weight in store search — we cover that in depth in our Chrome Web Store SEO guide.
5. Complete the privacy practices tab. Per the Chrome Web Store program policies, declare what data your extension collects, link your privacy policy, and — this is the part people skip — write a justification for every permission your manifest requests. "Needed for core functionality" is not a justification. Explain concretely what each permission does for the user.
6. Submit for review. Once every tab shows a green check, hit "Submit for review". Your item enters Google's review queue and you can no longer edit it until the review completes or you withdraw the submission.
7. Wait for the review. Review time varies — simple extensions with few permissions often clear within hours or a couple of days, while extensions requesting broad host permissions or handling sensitive data can take considerably longer. There is no published SLA, so build slack into your launch plan.
8. Publish. Once approved, you choose when it goes live: publish immediately, or use a staged rollout to release to a percentage of users first. For a first release, immediate is usually fine — there is no existing user base to protect.

Publishing a Chrome extension is not the finish line — it is the starting line. The review gets you into the store; what happens in store search afterwards decides whether anyone ever installs it.

Why do Chrome Web Store reviews get rejected?

Most rejections are avoidable and fall into a handful of well-known buckets. Check your submission against this list before you hit submit.

• Excessive permissions. Requesting <all_urls> when you only touch one domain is the single most common trip wire. Request the narrowest permissions that work, and prefer optional permissions the user grants at runtime.
• Missing privacy disclosures. If your code sends any data off-device and the privacy tab says otherwise — or the policy link is dead — expect a rejection.
• A misleading listing. Screenshots showing features that do not exist, or a description promising more than the extension does, violates the metadata policy.
• Keyword stuffing. Repeating search terms in the title or description reads as spam to the reviewers. Write for humans; the store algorithm is smarter than a keyword list.
• Remote code. Manifest V3 forbids loading and executing code from outside the package. All JavaScript must ship inside your ZIP — fetching remote configuration data is fine, fetching remote scripts is not.

What to do if you are rejected

A rejection is a routine event, not a black mark, and it arrives with a stated reason and a policy reference. Read both before changing anything — the reason is usually narrower than it first appears, and rebuilding half the extension in a panic is a common overreaction.

1. Match the reason to a specific thing in your package. If the notice names a permission, find where it is used. If it names your listing, find the sentence. Vague fixes produce a second rejection for the same cause.
2. Fix it, bump the version, resubmit. The resubmission goes through the same queue; there is no separate appeals lane for an ordinary policy fix.
3. Appeal only when you believe the reviewer was wrong, and when you appeal, explain what the extension does and why the flagged behaviour is necessary rather than restating that you disagree.
4. Keep a note of what happened. The same trip wire tends to catch the same developer twice, several months apart, on a different extension.

While you wait, resist the urge to resubmit repeatedly. Each submission replaces the one in the queue, so a stream of small changes restarts the clock rather than speeding it up.

After you publish: track what happens next

Your listing goes live, you share the link, and then comes the real question: does anyone actually find it? Almost all organic installs come from Chrome Web Store search, which means your position for the keywords your users type is the metric that matters most.

Here is the awkward part. The developer dashboard tells you very little about this. It shows nothing at all about where you rank in store search, and it says nothing about the store around you. You can be sliding from position 4 to position 19 for your money keyword and the dashboard will not tell you a thing until installs quietly dry up.

That gap is exactly what rank tracking fills. cwspy gives a just-published extension its day-one baseline: the moment your listing goes live it starts recording where you surface for the keywords you chose, how your first users accumulate, and how the incumbents respond — so week one is measured, not guessed at. It also keeps a history of your ratings, version releases, and competitors — all read from public store pages, so you never grant it access to your developer account.

Once you can see positions, the next step is moving them — our guide on how to promote a Chrome extension covers what actually shifts rankings and installs.

Quick launch checklist

Before submitting

• Manifest V3, tested locally as an unpacked extension
• ZIP with manifest.json at the root, no dev clutter
• 128x128 icon and at least one clean 1280x800 screenshot
• Privacy policy hosted and linked, if you touch user data
• Every permission justified in plain language

After going live

• Verify the listing renders correctly and the install works
• Pick the 5–10 keywords your users would actually search
• Start tracking your positions and user count from day one
• Watch how each new version affects growth

That is the whole process. Package, submit, pass review, publish — and then keep watching, because the store listing you launch with is rarely the one that wins. Questions? Reach out through our contact form or email us at [email protected].