Publishing to the Chrome Web Store: A Developer’s Submission and Review Guide

Publishing an extension to the Chrome Web Store is a process with real friction. Google’s review process has tightened substantially since 2019 in response to malicious extensions — some of which went through a nominal review and still ended up stealing data. The current review regime combines automated checks with human review for sensitive permission requests, and the rejection criteria have become harder to interpret from the outside. This guide covers the practical mechanics: what you need to prepare, where submissions get rejected, how to respond to rejections, and what to expect for timing.

Account Setup and Developer Registration

You need a Google developer account at chromewebstore.google.com/devconsole. First-time registration requires a $5 one-time fee and identity verification. This isn’t to generate revenue — it’s to raise the cost of throwaway accounts used to distribute malicious extensions.

If you’re publishing on behalf of an organization, use a dedicated account rather than a personal Google account. Account ownership is difficult to transfer after the fact.

Manifest Requirements Before Submission

Your manifest.json must declare Manifest V3 for new submissions. Google stopped accepting new Manifest V2 extensions in June 2022 and is phasing out existing MV2 extensions from the store. If you’re migrating from MV2, the Chrome extension migration guide covers the specific API changes.

In the manifest, permission declarations are the most review-sensitive element. The review process scrutinizes whether the permissions you request are justified by the extension’s stated functionality:

  • Request the minimum permissions your extension actually needs.
  • Replace tabs with activeTab if you only need tab information for the current tab in response to user action.
  • Replace broad host_permissions (<all_urls>) with specific origins if your extension only operates on specific sites.
  • scripting, webRequest, and storage each have documented review triggers.

The privacy_practices field requires a Privacy Policy URL if your extension handles any user data. Google’s user data FAQ specifies what constitutes “user data” broadly — essentially anything that could identify a user. If you’re in doubt, include a privacy policy.

What to Prepare Before Submission

Store listing assets:

  • Icon: 128×128 PNG, transparent background, no screenshots, no badges
  • Promotional image: 440×280 PNG or JPG (required for featured placement, optional but recommended)
  • Screenshots: 1280×800 or 640×400, minimum 1, maximum 5. Show actual extension functionality, not a landing page.
  • Short description: 132 characters maximum, displayed in the search results and extension card.
  • Detailed description: No hard character limit, but longer is not better. Explain what the extension does, what permissions it uses and why, and what data it accesses. The description affects review — reviewers read it to understand the extension’s purpose.

Privacy policy: Host it on a stable URL. Google checks that it’s accessible. The policy must specifically address what data your extension collects and how it’s used.

Justification for sensitive permissions: The developer dashboard has a “Permission justifications” section. Fill it out for any sensitive permission. Reviewers read these. The justification “our extension needs this to work” is not acceptable — explain specifically what functionality requires the permission.

The Review Process

Submission triggers an automated policy check first. If it passes, a human reviewer is assigned. Current review times (as of late 2025) range from a few hours for straightforward extensions to weeks for extensions requesting sensitive permissions or accessing financial data.

Google does not disclose the review criteria in full. What is publicly known from the Chrome Web Store developer policies:

  • Extensions must have a clear, single purpose.
  • The extension may not engage in deceptive behavior (misrepresenting functionality, mimicking other extensions or websites).
  • User data must be handled per the privacy policy declaration.
  • Monetization through ad injection is prohibited.
  • Extensions that modify other website’s content must disclose this.

Common rejection reasons based on developer forum patterns:

  1. Broad host permissions without justification. <all_urls> triggers review. Narrow to what you actually need.
  2. Privacy policy missing or inaccessible. Google’s crawlers check the URL; make sure it returns 200.
  3. Description doesn’t match functionality. A discrepancy between what the description says and what the extension does is a fast path to rejection or suspension.
  4. Remote code execution. Extensions may not fetch and execute arbitrary JavaScript from external servers in MV3. All logic must be bundled in the extension.
  5. Sensitive permission not justified. If you request webRequest or browsingData, you’ll need a compelling justification.

Responding to Rejections

Rejections come via email and the developer dashboard. The rejection notice includes a policy violation category, which is usually broad. You have options:

Fix and resubmit. For clear policy violations, fix the issue and resubmit. Each submission is reviewed as a new item — be explicit in the “What’s new” field about what you changed in response to the rejection.

Appeal. If you believe the rejection was incorrect, submit an appeal through the developer support form. Appeals are reviewed by a different team. Provide specific evidence that your extension complies with the cited policy.

Clarification request. For ambiguous rejections, you can request clarification before resubmitting. This adds time but may avoid a second rejection for misunderstanding the issue.

Update Submissions

Updates to existing extensions go through review too, but typically faster than initial submissions. If your update changes permissions (requesting new permissions not in the original), users must explicitly accept the new permissions, and the update flags for additional review.

The review timeline for updates is typically 1–3 business days for non-sensitive changes, longer if permissions change or the extension operates in financial/healthcare domains.

Distribution Options

The Chrome Web Store is not the only distribution path:

  • Unlisted items. Extensions can be unlisted — they’re in the store and go through review, but aren’t discoverable through search. Users can only install via a direct link. Useful for internal tools or beta distributions.
  • Group Policy (enterprise). Chrome enterprise deployments can force-install extensions from the store or from private hosts via CRX files. This bypasses the store for internal distribution.
  • Developer mode sideloading. For testing only — end users rarely have developer mode enabled, and sideloaded extensions prompt warnings.

Monitoring After Publication

Set up the developer dashboard notification emails for review status changes, user reviews, and policy violation notices. Extensions can be removed without warning for policy violations, and the removal email is the first notice you’ll receive.

Monitor user reviews for bug reports — many users prefer leaving a review to finding a support channel. A negative review mentioning specific behavior may also flag your extension for re-review.

FAQ

How long does initial review take? Variable. Simple extensions with no sensitive permissions: a few hours to a couple of days. Extensions requesting webRequest, accessing financial or health data, or with broad host permissions: several days to a few weeks. Google doesn’t publish SLAs.

Can I publish the same extension to Firefox Add-ons? MV3 extensions are cross-browser compatible with some differences. Firefox supports MV3 but with a more permissive webRequest implementation. Submit to addons.mozilla.org separately — it’s a different store with different review procedures and timelines.

What happens if my extension is removed after publication? You’ll receive an email specifying the policy violation. Existing installs are disabled for users. You can appeal, fix the issue and resubmit (if the removal was for policy violations, not security), or accept the removal.

Do I need a privacy policy if my extension doesn’t collect data? If your extension genuinely collects no user data (no analytics, no remote storage, no user-identifiable information), you may not need a full policy. But Google’s definition of “user data” is broad. An extension that reads page content to provide a feature is likely touching user data. When uncertain, include a policy — a rejection for missing privacy policy is easily avoidable.