Publish Chrome Extension to Web Store: Full Guide (2026)

The code is the easy part. Plenty of developers finish a working extension in an afternoon and then spend a week bouncing off review rejections, because the process to publish Chrome extension to Web Store listings is not a file upload — it is a compliance submission with a file attached.

This guide walks the whole path in order: registering and verifying the developer account, packaging the archive correctly, writing a listing that does not trip the metadata policies, completing the privacy declarations that cause most rejections, choosing visibility, and shipping updates afterwards. It assumes you already have a working Manifest V3 extension. If you do not, how to build a Chrome extension covers the build first.

What You Need Before You Upload

Gather these before you open the dashboard to publish Chrome extension to Web Store listings. Assembling them mid-submission is how a thirty-minute task becomes an evening.

A working Manifest V3 extension tested via Load unpacked at chrome://extensions with Developer mode on.
A Google account you are willing to attach to a public developer identity, with two-step verification enabled — the store requires it.
Five US dollars for the one-time developer registration fee.
A 128 by 128 pixel PNG icon. Required. It is what appears in search results and on the install button.
At least one screenshot at 1280 by 800 or 640 by 400 pixels. You can supply up to five, and you should.
A short description under 132 characters and a detailed description for the listing body.
A one-sentence single purpose statement. The store requires every extension to have one narrow purpose, stated plainly.
A written justification for every permission in the manifest, including each host permission pattern.
A privacy policy URL if your extension touches user data in any way that requires disclosure.
Your trader or non-trader status, which the store now requires developers to declare for EU regulatory compliance. Traders must supply contact details that are shown publicly on the listing.

The last four are where submissions stall. They are not code problems, so developers tend not to prepare them.

Step 1: Create and Verify a Developer Account

Go to the Chrome Web Store Developer Dashboard and sign in. On first visit you are asked to accept the developer agreement and pay the one-time registration fee. The fee is per account, not per extension, and it does not recur.

Then handle the account-level items that will block you later when you try to publish Chrome extension to Web Store items for real:

Enable two-step verification on the Google account. Publishing is blocked without it.
Verify a contact email. Google uses it for review outcomes and policy notices. Missing these is how developers discover a takedown weeks after the fact.
Set the publisher display name. This is what users see under your extension name. A real name or a company name reads better than a Gmail address, and it is one of the small signals people use to decide whether to install.
Declare trader status. If you are publishing in a commercial capacity, you are a trader and must publish contact details.
Consider a group publisher. If more than one person will manage the item, set this up before you publish rather than trying to migrate ownership afterwards. Ownership transfers are possible but tedious.

Optional but worth it: domain verification. Linking a verified website to your publisher account enables a verified publisher badge on the listing.

Step 2: Package the Extension Correctly

The upload is a single ZIP archive. Two rules cover nearly every packaging failure people hit when they publish Chrome extension to Web Store items for the first time.

Rule one: manifest.json must be at the root of the archive, not inside a folder. Zipping the folder rather than its contents is the single most common mistake. If your archive contains one directory and the manifest is inside it, the upload is rejected immediately.

Rule two: ship only what runs. Exclude node_modules, source maps, test fixtures, .git, README drafts, design files, and anything else that inflates the package. Reviewers look at what is in the bundle, and unexplained files invite questions.

On macOS, use a command-line zip rather than the Finder compress option, which adds __MACOSX metadata directories. From inside the extension directory, zipping the current directory contents to an archive one level up produces a clean package.

Manifest details reviewers check:

Version. Up to four dot-separated integers, each between 0 and 65535. It must be strictly higher than any previously uploaded version for that item. You cannot reuse or roll back a version number, ever.
Name and description in the manifest should match the store listing. Divergence looks like a bait-and-switch.
No remotely hosted code. Manifest V3 forbids it. Loading a script from a CDN at runtime is an automatic rejection, and so is anything that evaluates fetched strings.
No obfuscated code. Minification is fine. Deliberate obfuscation is a policy violation. If your build pipeline mangles output heavily, be ready to explain it.
Permissions trimmed to the minimum. Every leftover permission from a feature you cut is a rejection waiting to happen. Audit the manifest against what the extension actually does before you zip.

That last point is worth dwelling on. An extension that only needs the clipboard should request the clipboard and nothing else. Narrow permission sets clear review faster, install more readily, and survive policy changes better. See open source Chrome extensions for why a small, auditable surface is also the easiest thing to earn trust with.

Step 3: Build the Store Listing

In the dashboard, create a new item and upload the ZIP. The dashboard then opens the listing editor with several tabs. Start with Store listing.

Name. Up to 75 characters. Descriptive beats clever. Keyword stuffing is explicitly against the metadata policy and gets flagged, but a name that states what the extension does is both allowed and better for discovery.

Short description. Up to 132 characters, and this is the line shown in search results. Say what it does and for whom. No marketing adjectives; there is no room.

Detailed description. Up to 16,000 characters. Structure it: what it does in one paragraph, how to use it, what permissions it needs and why, what it does not collect. The permission explanation matters — users read it, and so do reviewers.

Category and language. Pick the narrowest accurate category.

Screenshots. At least one, up to five, at 1280 by 800 or 640 by 400. Show the extension doing its job, not a logo on a gradient. If the extension is invisible in normal use — a keyboard shortcut tool, for instance — screenshot the confirmation state, the shortcuts page, or the settings.

Promotional tiles. A 440 by 280 small tile and a 1400 by 560 marquee. Optional, but required for any chance at editorial placement.

Support links. A support site or email. Users with a problem either find a support channel or leave a one-star review; there is no third option.

Metadata policy is stricter than most first-time publishers expect. Do not use another product name in your title. Do not list unrelated keywords in the description. Do not claim features you do not have. Each of these is a documented reason for rejection when you publish Chrome extension to Web Store listings.

Step 4: The Privacy Practices Tab, Where Most Rejections Happen

This is the tab that decides most outcomes, and it is entirely prose. Nothing else in the process to publish Chrome extension to Web Store listings rejects as many first submissions.

Single purpose description. One narrow purpose, stated in a sentence. "Copies the URL of the current tab to the clipboard using a keyboard shortcut" is a single purpose. "Productivity toolkit for browsing" is not, and an extension that bundles unrelated features gets rejected under the single purpose policy no matter how well built it is.

Permission justifications. One field per permission, plus one for host permissions and one for remote code if applicable. Each justification must connect the permission to a user-visible feature. Write them like this:

Weak: "Needed for the extension to work."
Strong: "The clipboardWrite permission is used to place the current tab address on the system clipboard when the user presses the configured keyboard shortcut. It is used for no other purpose."

If you cannot write a strong justification for a permission, remove the permission. That decision is faster than the appeal.

Remote code declaration. Answer honestly. Manifest V3 prohibits executing remotely hosted code, so for a compliant extension this is a straightforward no.

Data usage disclosures. Declare every category you handle: personally identifiable information, health information, financial information, authentication information, personal communications, location, web history, and user activity. Then certify three things: that you do not sell data to third parties, that you do not use or transfer data for purposes unrelated to the single purpose, and that you do not use or transfer data to determine creditworthiness or for lending.

Privacy policy URL. Required if you handle user data. Even extensions that collect nothing benefit from publishing a short policy that says so plainly — it is one sentence, it costs nothing, and it removes an obvious reviewer question.

An extension that genuinely collects nothing, makes no network requests, and holds one narrow permission has the easiest possible version of this tab. The Ctrl+Shift+C extension listing is a compact example to read before you write yours: one stated purpose, clipboard permission only, no network calls, and a data disclosure with nothing in it. That shape is not a coincidence — the store review process rewards small scope, and scope is a design decision you make long before submission.

Step 5: Choose Visibility and Submit

The final choice before submission is who can see the item.

Public. Listed in the store, indexed in search, installable by anyone.
Unlisted. Not in search or category browsing, but anyone with the direct link can install. Good for beta testing with real users and for tools distributed through your own site.
Private. Restricted to named trusted testers, or to a Google Workspace domain if the account is linked to one. The route for internal enterprise tools.

Unlisted and private items still go through review. Visibility is not a way to skip it.

You can also defer publishing: pass review, then publish manually when you are ready. Useful when the launch is coordinated with anything else.

Then submit. The dashboard shows the item as Pending review.

For the user-side view of what happens next — what people see when they land on your listing and click Add to Chrome — see how to install Chrome extensions.

Review Times and the Most Common Rejection Reasons

Review is partly automated and partly manual. Simple extensions with narrow permissions frequently clear within a day. Anything requesting broad host permissions, content script injection across all sites, or access to sensitive APIs routinely goes to a human and takes longer. Plan for a week and be pleased when it is faster. Do not schedule a launch announcement against an unreviewed submission.

The rejections that come up most:

Permission mismatch. Requested permissions exceed what the extension visibly does. Fix by trimming the manifest, not by rewriting the justification.

Single purpose violation. The extension does several unrelated things. Fix by splitting into separate items or cutting features.

Misleading or spammy metadata. Keyword stuffing, competitor names in the title, claims the extension does not deliver.

Missing or inadequate privacy disclosure. Data collection that is not declared, or a privacy policy URL that returns a 404. Reviewers check the link.

Obfuscated or remotely hosted code. Non-negotiable under Manifest V3.

Minimum functionality. An extension that is only a bookmark to a website, or a thin wrapper with no browser-level function, does not qualify.

Broken on review. The reviewer could not get it to work. Include test instructions and credentials for anything behind a login, in the notes field provided for reviewers.

When rejected, you get a policy reference and usually a short explanation. Fix the specific issue, bump the version, and resubmit. An appeal is appropriate when you believe the rejection is factually wrong, not as a first response to a rejection you disagree with. Repeated non-compliant resubmissions can put the account itself at risk.

Shipping Updates After Launch

You only publish Chrome extension to Web Store listings for the first time once. Publishing repeatedly is where the habits matter.

Every update goes through review. There is no fast path for small changes, so batch fixes rather than shipping five one-line patches in a week.

Bump the version every time. Uploading a package whose version matches a previous upload is rejected before review even begins.

Adding a permission resets user trust. Chrome disables an extension and prompts the user when an update requests new permissions. Many users never re-enable it. Plan the permission set at launch; adding later is expensive in installed base.

Use staged rollout for anything non-trivial. The dashboard supports releasing an update to a percentage of users, which limits the damage from a regression you did not catch.

Watch the dashboard analytics. Installs, uninstalls, and impressions tell you what your listing is doing. A high impression count with a low install rate is a listing problem: usually the short description or the screenshots.

Respond to reviews. Developer replies are public, and a visible support presence measurably changes how a listing reads to a prospective installer.

Keep the listing current. Screenshots showing an old UI, or a description referencing features you removed, are both metadata accuracy issues and can be flagged long after launch.

Frequently Asked Questions

How much does it cost to publish a Chrome extension? A one-time developer registration fee of five US dollars covers the account for life. There is no per-extension charge and no recurring fee, and the same account can hold many items.

How long does Chrome Web Store review take? Many submissions clear within a day or two, but extensions requesting broad host permissions or sensitive APIs are routinely held longer for manual review. Plan for a week rather than an afternoon, and never schedule a launch against an unreviewed submission.

Do I need a privacy policy for my extension? You need one if your extension handles any user data at all. Extensions that collect nothing still have to complete the data disclosure certifications, and publishing a one-paragraph policy stating that you collect nothing removes an obvious reviewer question.

What is the most common reason a Chrome extension gets rejected? A mismatch between the permissions requested and what the extension visibly does. Every permission needs a written justification that ties it to a feature a reviewer can see, and the right fix is usually to remove the permission rather than to argue for it.

Can I publish an extension privately for just my team? Yes. Visibility can be set to unlisted, which hides it from search but keeps the direct link working, or private, which limits install to named trusted testers or a Google Workspace domain. Both still go through review.

Is Manifest V2 still accepted in the Chrome Web Store? No. New submissions must use Manifest V3, and the migration deadline for existing items has passed. Anything built against the older manifest has to be rewritten before submission.

How do I ship an update after publishing? Increment the version number in the manifest, upload a new package to the same item, and submit for review again. Use the staged rollout option for anything non-trivial so a regression reaches a fraction of users rather than all of them.

Submit Small, Ship Often

The path to publish Chrome extension to Web Store listings rewards restraint. A narrow single purpose, the smallest possible permission set, an honest privacy disclosure, and screenshots that show the thing working will clear review faster than a feature-rich submission with a vague purpose statement and a manifest full of permissions nobody justified.

If you want to see what a minimal, review-friendly extension looks like from the user side, Ctrl+Shift+C is a working example of the shape: one keystroke copies the current tab URL, one permission, no network calls, no data collection, and a single purpose you can state in one line. Install it to see the pattern, then go and build yours with the same discipline.