The Chrome Web Store has somewhere north of 130,000 published extensions in 2026, and almost everything you read about it is anecdotal. "Most extensions have low ratings", "permission warnings are a bigger problem now", "the long tail is huge" — all true-ish, all unverified. This guide is the actual distributions, scraped and aggregated across the published catalog: rating distribution, review-count curves, the most common permissions, update cadence, and bundle size. Numbers you can cite, with what each one means for a growth plan.
Rating distribution across the Store
The first thing most listings underestimate: the median Chrome extension has a higher rating than people assume. Among extensions with at least 10 reviews:
Median average rating: ~4.5★. The much-discussed 'mediocre middle' is real but small. Most extensions cluster between 4.0 and 4.7.
Three reads:
- Median is 4.5★, not 3.5★. The vibes around Web Store quality are wrong — the catalog is generally well-rated among extensions with enough reviews to register.
- Below 4.0 is the bottom 22%. If your rating is 3.8, you're losing CVR against most competitors regardless of feature parity, per the rating curve in the growth playbook.
- 4.8+ is the top 18%. Beating most listings on rating alone is achievable with disciplined success-anchored review prompting; the math is in the growth playbook above.
Review count: where the curve breaks
Review count distribution is heavily long-tailed. Most listings have very few reviews; a small minority have thousands.
Just clearing 10 reviews puts you ahead of 54% of the catalog. Crossing 200 reviews puts you in the top 11%.
Two non-obvious implications:
- Getting your first 10 reviews is meaningful by itself — it crosses you out of the"basically invisible" cohort and starts the social-proof flywheel. Most extensions never get here; ship the review prompt as described in the growth playbook and you're past the threshold in weeks.
- 200 reviews is the "moat" threshold where the listing starts to look established to users scanning multiple options. CVR climbs noticeably between 50 and 200; flattens after 500.
Most common permissions (and the rarest valuable ones)
Frequency of each permission key across the published catalog. The top 7 cover 80%+ of all permission usage; the long tail is dominated by browser APIs most devs don't know exist.
storage is near-universal. Note that 32% still declare <all_urls> — the broadest permission warning. Many could move to activeTab + optional_host_permissions.
Two takeaways for growth:
- 32% of extensions still declare
<all_urls>— which triggers the "Read and change all your data on all websites" warning that quantifiably destroys install CVR. A meaningful fraction don't actually need it. The migration recipe is in the permission warning guide. activeTabis only on 41% — well below its use-case justification. Many of the<all_urls>extensions above would rank-and-CVR better onactiveTabplusoptional_host_permissions.
How many permissions extensions request
Counting unique entries in permissions + host_permissions per published extension:
Median: 4 permissions. Extensions in the 6+ band frequently include unused permissions inherited from copied boilerplate.
Anything above 7 permissions starts looking suspicious to users in the install dialog, and the dialog itself gets longer (and therefore less read). Two thirds of extensions in the 8+ bands could trim. The audit is mechanical: chrome://extensions → details shows exactly what each permission is used for; remove anything you can't justify in a sentence.
Update frequency distribution
Days since last update, for currently-listed extensions:
45% of extensions updated within 90 days — the band where CWS appears to maintain a freshness signal. 9% haven't shipped in 2+ years and pay a quiet ranking cost.
The pattern is consistent with the freshness-signal observation in the CWS SEO guide: listings updated within 90 days appear to outrank otherwise equivalent listings that haven't shipped recently. Shipping substantive updates every 60–90 days hits the cadence; trivial version bumps appear to be discounted by the algorithm.
Bundle size — what's normal, what's suspicious
Total uncompressed extension package size (manifest + scripts + assets + locales):
Median bundle: ~600KB. Anything over 5MB usually means bundled images/fonts that should be lazy-loaded — or remote-loaded JS that's MV3-policy-risky.
Bundle size matters for two reasons:
- Cold-start latency. Larger bundles take longer for Chrome to load and parse, which feeds the service-worker cold-start time. The patterns to fix this are in the service worker guide.
- Update cost on the user's side. Big updates take longer to download and install; users on slow connections (mobile-tethered, transit, low-bandwidth regions) skip the update or uninstall the extension when Chrome stalls. Trimming a 12MB extension to 3MB is mostly mechanical (strip unused locales, lazy-load assets) and measurably improves D30 retention in slow-connection markets.
Manifest V3 adoption two years in
MV2 was sunset for new submissions in 2024 and for existing listings in 2025. As of mid-2026:
MV3 is now overwhelming. The remaining MV2 slice is mostly enterprise-policy or special-status extensions; new launches are MV3 by definition.
For dev planning purposes: writing about "MV2 vs MV3" in 2026 is mostly historical. The interesting question is which MV3 patterns settle into best-practice — the service-worker survival patterns, the no-remote-code constraint on A/B testing, the post-install tab in onboarding.
Install concentration: how unequal the Store is
Install counts follow a power law. The Pareto cut across the published catalog:
The top 0.1% of extensions capture more than half of all installs. The bottom 75% share roughly 1% of total volume between them.
Two implications for any extension still climbing:
- You don't need to beat the top 0.1%. Crossing into the top 5% — which captures >90% of all installs — is the realistic target. The distance from the long tail to the top 5% is much shorter than people assume because the long tail has near-zero install volume to begin with.
- The compound flywheel matters more in this market than in a uniform distribution. Once you cross into the top 10%, install velocity, review velocity, and rank signals compound on each other — see the full mechanics in the growth playbook.
FAQ
Where do these statistics come from?
Aggregated from public Chrome Web Store data scraped across the catalog. Methodology: random sample of ~100,000 published extensions, ratings and review counts as displayed, manifest and bundle data from the .crx packages. Numbers are approximate but representative; absolute values shift slightly each quarter.
Why is the median rating so high?
Two reasons: (1) extensions that fail badly get uninstalled and don't accumulate enough reviews to register in the ≥10-reviews cohort; (2) Web Store users disproportionately leave reviews after a positive experience because the prompt UX is positive-skewing. The combined effect makes median ratings look higher than the underlying user satisfaction.
How is the <all_urls> share calculated?
Extensions declaring either "<all_urls>" or "https://*/*" + "http://*/*" in host_permissions or in any content_script matches. Both trigger the same install-time warning.
Does Chrome Web Store penalize big bundle sizes directly?
No direct ranking penalty that we've been able to verify. The indirect penalty is real: slower cold-start, slower updates, more failed installs on weak connections, more early uninstalls in the time-to-uninstall <1h bucket. Compound effect, not a single penalty.
What's the catch on the "updated within 30 days" cohort?
It's self-selected toward active maintainers. The cohort skews higher-quality than the catalog at large; comparing your extension to it isn't apples-to-apples unless you also ship every month. The realistic peer band is "updated within 90 days", which covers 45% of the catalog.
Why does the long tail look so flat?
Because it is. The bottom 75% of extensions have almost no installs — most are abandoned, hobby, or category-fillers. The actually-competed-for catalog is roughly the top 25%, and within that, the top 5% captures most of the real install volume.
How often should I re-run these benchmarks?
Quarterly is enough. The underlying distributions shift slowly — most quarter-on-quarter movement is noise. The interesting signal is your position within the distribution over time, not the distribution itself.