You built the extension and it works with "Load unpacked". This is the map of everything between that and a public Chrome Web Store listing: the one-time $5 fee, the images the listing needs, the privacy paperwork, the review, and the maintenance that never quite ends.
Fees, limits, and review policies described here reflect the Chrome Web Store as of mid-2026. Google adjusts these over time — verify the current details in the official documentation before relying on them.
The mental model: pay once, then it's process, not money
Publishing Chrome extensions costs $5 — once, ever, for your whole catalog — and everything else the store asks of you is paid in time, not money. The costs split cleanly into three buckets: what you do once (create a developer account), what you do per release (package, describe, justify, wait for review), and what never stops (re-reviews, policy changes, user support).
If you're planning a series of extensions — the situation that prompted this post — the good news is that the "once, ever" bucket really is once: one account, one fee, one identity verification covers all of them. The per-release bucket, though, multiplies by the number of extensions you ship. Let's walk the buckets in order.
The developer account
Registration happens in the Chrome Web Store Developer Dashboard with a Google account, and requires a one-time $5 registration fee. There is no annual renewal — unlike Apple's $99/year or Microsoft's one-time-but-per-account-type fees, you pay Google exactly once in your life as an extension developer.
Three account decisions matter more than they look:
- The email is permanent. You cannot change the account's email address later — Google's own advice is to create a dedicated account just for publishing, so your store presence isn't welded to a personal inbox. For a series of extensions this is doubly worth doing: the account is the brand.
- Two-step verification is required. Publishing (and the publishing API you'll want later) requires it on the Google account.
- You get 20 slots. An account can have at most 20 extensions published at once (you can request an increase, granted based on account history). Plenty for most series — but worth knowing before you design a strategy around fifty micro-extensions.
There's one piece of paperwork many developers don't see coming: the trader declaration. Since February 2024, the European Union (EU) Digital Services Act (DSA) requires marketplaces to identify "traders" — anyone publishing in the course of business rather than as a hobby. Every developer must declare trader or non-trader status. If you monetize your extensions, you're likely a trader, and the store will verify and publicly display contact details — including a physical address and phone number — alongside your listings for EU users. If your extensions are free hobby projects, you declare non-trader and none of that applies. Decide which you are before you publish, not after.
What a submission actually contains
With the account in place, publishing one extension means uploading a zip file of your
built extension — manifest.json at the zip root, plus your code, icons, and any bundled
assets — through the dashboard's publish flow.
The manifest's name, version, and description seed the draft listing.
The zip is the easy part. What turns a working extension into a submittable one is the dashboard paperwork: a store listing tab, a privacy tab, and a distribution tab, all of which must be complete before the submit button works.
- Store listing — the public-facing text and images (next section).
- Privacy — purpose statement, permission justifications, and data disclosures (the section after that).
- Distribution — free or paid, which countries, and visibility: public (searchable), unlisted (installable via link, invisible in search — handy for betas), or private (restricted to specified users). No website of your own is required for any of these.
The listing images: heroes, tiles, and screenshots
The store listing needs real image assets at exact sizes, and this is per extension — a five-extension series means five sets. Budget actual design time here; it's most of the visible difference between a listing that looks maintained and one that looks abandoned.
| Asset | Size | Notes |
|---|---|---|
| Store icon | 128×128 PNG (96×96 artwork + 16 px transparent padding) | Must read well on light and dark backgrounds |
| Screenshots | 1–5 images, 1280×800 or 640×400 | Full-bleed, square corners; 1280×800 preferred for hi-res displays |
| Small promo tile | 440×280 | Effectively required: listings without one rank below those with one |
| Marquee promo tile | 1400×560 | Optional; needed to be eligible for store featuring |
PNG is the Portable Network Graphics format — the store wants it for the icon; screenshots and tiles can be PNG or JPEG. Google's design guidance for the promo tiles: communicate the brand, don't cram in screenshots, avoid text (it's unreadable at half size), and use saturated colors that survive shrinking.
For a series, design the icon and promo tiles as a family — same palette, same composition, one varying element per extension. It amortizes the design work and makes your catalog recognizable in search results.
The privacy tab: the part that actually takes time
The privacy tab is where submissions stall, because it's not about your code — it's about whether you can justify your code in writing. The privacy fields every extension must complete:
- A single-purpose statement. Extensions must have one narrow, easy-to-understand purpose. "Productivity suite that also manages your tabs and blocks ads" is a rejection; pick one job per extension. (For a series, this rule is actually your friend — it's the argument for shipping several small extensions instead of one kitchen-sink.)
- A justification for every permission in your manifest, one by one. The standing rule: request the minimum permissions consistent with the purpose. Unjustified or unused permissions are a standard rejection reason.
- A remote-code declaration. Manifest V3 (MV3) — the current extension platform version — forbids loading and executing remotely hosted code; you declare that you don't, or justify the exception.
- Data-use disclosures. Checkboxes declaring what user data you collect and certifying your compliance with the store's data policies. These render publicly on your listing.
- A privacy policy URL (uniform resource locator) if you handle user data — a publicly reachable page describing how data is collected, used, and disclosed, consistent with the checkboxes above.
That last item answers a question you asked: do you need a website? No. The store listing is your storefront; the only thing you must host yourself is the privacy policy page, and a free static page is enough — GitHub Pages, a page on a blog like this one, even a rendered Markdown file in the extension's repository with a public URL. One well-written policy can cover your whole series if it accurately describes all of them. A product site is a trust-and-marketing nicety, not a requirement.
The review
Every submission — first upload and every update after it — goes through the same review process, a mix of automated and human checks. Most reviews complete within a few days, but Google's own guidance says it can take up to a few weeks — so a review is something you schedule around, not something you wait out overnight. (If it exceeds three weeks, contact developer support.)
What you ask for largely determines how hard you're looked at:
| What you request | Example | Review friction |
|---|---|---|
| Narrow permissions, specific hosts | storage, one declared domain | |
| Sensitive execution permissions | tabs, cookies, webRequest, downloads | |
| Broad host access | <all_urls>, *://*/* |
New developers and brand-new extensions also get extra scrutiny, as do large codebases and minified or hard-to-read code. For a series, this has a pleasant consequence: your first extension is the slow one; a clean track record makes the rest smoother.
The outcomes form a lifecycle:
A rejection arrives by email with the policy violation named and can be appealed from the dashboard; your existing published version stays up and users aren't notified. Minor violations found later trigger a warning with a 7–30 day remediation window before takedown. Serious violations (malware territory) skip the courtesy and can end the account. One scheduling nicety: you can opt for deferred publishing — after approval you get up to 30 days to press the publish button yourself, which is how you line a release up with an announcement.
After publishing: what maintenance looks like
A published extension is never "done" — the store re-reviews it periodically, the platform underneath it keeps moving, and every fix you ship re-enters the review queue. Concretely, maintenance means:
- Every update is a full review. The few-days-to-weeks timeline applies to your one-line bugfix too. Batch small changes into planned releases rather than shipping five patches a week, and never ship a fix "urgently" the day before you need it live.
- New permissions freeze your users. If an update adds a permission that triggers a new
warning, the extension is disabled for existing users until each of them accepts the new
permission.
For a real user base this is the scariest lever in the whole system — design your permission
needs upfront, and prefer
optional_permissions(requested at runtime, no disable-and-ask) for features only some users need. - Policy and platform changes arrive on Google's schedule. Published extensions get periodic re-reviews as policies evolve; the Manifest V2 shutdown that forced every extension to migrate to MV3 is the canonical example. Expect roughly one "mandatory homework" event like this every couple of years.
- Users talk to you through the listing. Reviews and support questions accumulate on the store page, and your developer email is public. For a series, a shared support email and a simple issue tracker (the repository's, if it's public) keep this manageable.
Shipping a series: repository layout and automation
Everything above is per extension, so with a series the leverage is in sharing. One repository as a monorepo — each extension a package, shared code (UI components, storage helpers, build config) as internal packages — beats one repo per extension for a solo developer: one dependency update, one lint config, one place where the shared privacy policy and design assets live. Split repos only when the extensions stop sharing code or need different collaborators.
The second lever is automating the upload. The Chrome Web Store API lets a continuous integration (CI) pipeline upload the zip, publish, and check review status programmatically — turning "release five extensions" from an afternoon of dashboard clicking into a tag push. It authenticates with OAuth against your (two-step-verified) developer account, and community command-line wrappers around it exist if you'd rather not call it raw. The store listing and privacy tabs must be filled in the dashboard first — the API updates packages, not paperwork. For extensions with more than 10,000 weekly users it also supports percentage-based staged rollouts.
A working release pipeline for a series looks like:
- Bump the version in the extension's
manifest.json(the store rejects re-uploads of the same version). - Build and zip that extension's package in CI.
- Upload and publish through the Chrome Web Store API.
- Track the review state; on rejection, the email tells you which policy to fix.
The bill, itemized
| What | Cost | How often |
|---|---|---|
| Developer registration | $5 | Once, ever |
| Listing an extension | $0 | — |
| Updates and re-reviews | $0 | — |
| Hosting the privacy policy | $0 (GitHub Pages or any static page) | — |
| Store listing images | Your design time (×N extensions) | Per extension, occasional refresh |
| Privacy paperwork + review round-trips | Your time | Every release |
So the honest answer to "how much and how often do you pay": $5, once. The Chrome Web Store is the cheapest major software marketplace to be on. What it charges instead is process — image assets at exact sizes, written justifications for every permission, reviews measured in days, and a permanent, low-grade maintenance duty. Budget your time accordingly, share everything you can across the series, and let a pipeline do the uploading.
If you want the prequel — what an extension actually is before you ship it — that's How Chrome Extensions Work, for Dummies.
References
- Register your developer account — Chrome for Developers
- Publish in the Chrome Web Store — Chrome for Developers
- Supplying images — Chrome for Developers
- Fill out the privacy fields — Chrome for Developers
- Chrome Web Store review process — Chrome for Developers
- Trader/Non-Trader developer identification and verification — Chrome for Developers
- Permission warnings — Chrome for Developers
- Using the Chrome Web Store Publish API — Chrome for Developers