Chrome Web Store Publishing Requirements 2026: Complete Checklist

The Chrome Web Store rejects a significant portion of first-time submissions. Not because the extensions are bad — but because developers didn’t know about a policy change, missed a required field, or requested one permission too many.

This checklist is organized by rejection risk, highest first. Work through it before you hit submit and you’ll bypass the most expensive part of extension development: the wait-fix-resubmit loop.

Before Anything Else: Your Developer Account

You cannot publish without these. No exceptions.

$5 one-time registration fee. Paid once, covers your account forever. If you haven’t registered, go to the Chrome Web Store Developer Dashboard and complete registration first.

2-Step Verification. This is mandatory as of 2021 and still enforced in 2026. Your Google account must have 2-Step Verification enabled before you can publish or update any extension. Check your Google Account security settings. No 2SV = no publishing. Simple as that.

Verified contact email. When setting up your developer account, you must verify your contact email address. Chrome Web Store sends all review notifications, rejection emails, and policy violation warnings to this address. Use an address you actually monitor — missed rejection emails cause avoidable delays.

Publisher display name. This appears under every extension you publish. Choose something professional and consistent. It cannot be changed easily after the fact.

Rejection Risk #1: Manifest V3 Compliance

This is the single biggest source of silent rejections in 2026. MV2 is dead for new submissions. If you’re building anything new or migrating an existing extension, you need to be fully MV3-compliant.

The non-negotiables:

{
  "manifest_version": 3
}

That’s the starting point. But MV3 compliance goes much deeper than a version number.

Service workers, not background pages. MV3 replaced persistent background pages with service workers that terminate when idle. Your background logic must handle this — store state in chrome.storage, not in-memory variables that evaporate when the worker sleeps.

No remote code execution. This is probably the most violated rule. MV3 (and Chrome Web Store policy independently) prohibits:

• <script> tags pointing to external URLs
• eval() on strings fetched from remote servers
• Loading modules from remote origins at runtime
• Any mechanism that executes logic fetched from outside the extension package

You can still communicate with remote servers — fetch JSON configuration, sync user data, call APIs. What you cannot do is execute the response as code. The logic must live in your bundle.

declarativeNetRequest instead of blocking webRequest. If your extension modifies or intercepts network requests, you must use the declarative API. Blocking webRequest is not available in MV3.

Content Security Policy. MV3 enforces a strict CSP that bans unsafe-eval and inline scripts by default. Review your content_security_policy field in the manifest carefully.

Rejection message you’ll see if you fail this: “Extensions using Manifest V2 are no longer accepted. Please update your extension to use Manifest V3.” Or more painfully, a vague “functionality could not be determined” rejection that traces back to remote code execution you didn’t realize you had.

Rejection Risk #2: Permissions and the Principle of Least Privilege

Permissions are reviewed exhaustively. Every entry in your permissions and host_permissions arrays must have a demonstrable, active use case in your code.

The checklist:

• Remove every permission that isn’t actively called in your code
• Replace <all_urls> with specific host patterns wherever possible (e.g., https://api.myservice.com/*)
• Use activeTab instead of tabs if you only need page access during explicit user action
• Declare optional permissions under optional_permissions and request them at runtime only when needed
• For webRequest, confirm you genuinely cannot achieve your goal with declarativeNetRequest

The dashboard will show you a warning if you use <all_urls> or broad patterns: “Due to the Host Permission, your extension may require an in-depth review which will delay publishing.” That’s not just a warning about time — it’s a signal that reviewers will scrutinize every byte of your code for permission justification.

Sensitive permissions that guarantee manual review: tabs, cookies, history, downloads, webRequest, debugger, and any broad host pattern. Request only what you’d be comfortable explaining to a stranger.

Rejection message you’ll see: “This extension requests permission to access sensitive information. Please justify your use of the following permissions: [list].”

Rejection Risk #3: Single Purpose Policy

Every Chrome extension must have “a single purpose that is narrow and easy to understand.” This rule is actively enforced and has real teeth.

What this means in practice: your extension should do one job for one user need. Not two. Not “related features.”

Passes: A tab manager that helps users organize open tabs. A grammar checker for text fields. A dark mode toggle for specific websites.

Fails: A “productivity suite” that blocks distracting sites, tracks time, and also injects custom CSS into every page. Those are three separate user jobs. Split them into three extensions or remove the unrelated features.

The nuance: Features that all serve the same underlying user job can coexist. A developer tools extension that includes a network inspector, a storage viewer, and a console enhancer probably passes — they’re all the same user job (debugging). An extension that does developer tools and manages your todo list does not.

Before submitting, write one sentence that describes your extension’s purpose. If you can’t do it without using “and” to join two different user needs, you have a single-purpose problem.

Rejection message you’ll see: “Your extension does not comply with the Extension Quality Guidelines regarding single purpose. Please ensure your extension has a single purpose that is narrow and easy to understand.”

Rejection Risk #4: Privacy Practices Disclosure

Since 2021, every Chrome extension must certify its privacy practices before publishing. This is not optional, and incomplete disclosures are a common cause of rejection even for extensions that otherwise look fine.

What you must complete in the Privacy tab of the developer dashboard:

Single purpose description. A clear statement of what your extension does, for reviewer context.

Data collection disclosure. Checkboxes for every type of data your extension collects or transmits: personally identifiable information, health information, financial information, authentication information, personal communications, location, web history, user activity, website content. Check everything that applies — including analytics events and crash reports. Undisclosed collection is grounds for removal after publishing, not just rejection upfront.

Limited use certification. You must certify that data use complies with Chrome Web Store’s limited use policy — no selling data, no personalized ads, no transferring to data brokers.

Privacy policy URL. Required if your extension handles any user data. Must be:

• A stable, permanent HTTPS URL
• Publicly accessible (test in incognito)
• Accurately describing what your code actually does
• Updated every time you add data collection

A privacy policy hosted on a Google Doc is not acceptable. A policy that says “we don’t collect data” when your extension calls an analytics endpoint is an automatic rejection on resubmission once reviewers notice.

Rejection Risk #5: Code Quality — The Zero-Tolerance Rules

Two violations result in immediate rejection, no appeals, no gray area:

Obfuscation. Not minification — obfuscation. Minification (removing whitespace, shortening variable names, combining files) is perfectly fine. Obfuscation (transforming code so its logic is deliberately unreadable) is a hard ban. Google’s reviewers cannot review what they cannot read, and they won’t try.

If you’re worried about IP protection: move sensitive logic server-side. That’s the correct solution.

Remote code execution. Covered under MV3 above, but worth repeating as a standalone quality check because it’s also independently prohibited by Chrome Web Store policy, separate from the MV3 requirement. This means no eval() on remote strings, no dynamic script injection from external sources, no plugin systems that execute downloaded logic.

Additional code quality checks:

• No document.write() or unescaped innerHTML with user-controlled input
• No hardcoded credentials, API keys, or secrets in your extension bundle (they’re visible to anyone who installs it)
• Dependencies bundled locally — no loading from CDNs at runtime
• Clean, readable code structure (reviewers are humans; dense, unstructured code takes longer to clear)

Rejection message for obfuscation: “Your item is not allowed to contain obfuscated code.” This one is particularly frustrating because it’s non-negotiable — there’s no path to appealing it other than removing the obfuscation.

Rejection Risk #6: Store Listing Requirements

Your listing is reviewed alongside your code. Incomplete or misleading listings fail independently of code quality.

Required fields:

Listing-specific rejection triggers:

• Description claims features that don’t exist in the code
• Screenshots show browser chrome without demonstrating the extension itself
• Icon uses trademarked logos or resembles another extension
• Title contains your competitor’s brand name
• Keyword stuffing in description (“best tab manager tab management tab organizer for tabs”)
• Unattributed testimonials presented as fact

The AppBooster Icon Generator and Tile Cropper tools handle exact-spec asset creation if you want to skip manual resizing.

Rejection Risk #7: Content Policy Violations

Some violations get extensions rejected instantly. Others get extensions taken down after publishing with no warning beyond an email. Know these:

Zero-tolerance rejections:

• Malware, spyware, or any code that accesses user systems without consent
• Cryptocurrency mining (even opt-in)
• Extensions that facilitate unauthorized access to accounts or systems
• Child sexual abuse material — immediate account termination

Common content violations that developers accidentally hit:

• Injecting ads into third-party pages without prominent disclosure in your listing
• Affiliate link modification without disclosure before installation
• Impersonating system notifications or browser alerts
• Hijacking search queries or default search settings

A note on affiliate programs. They’re allowed — but the requirements are strict. You must disclose affiliate functionality prominently in your store listing, in your extension UI, and the disclosure must appear before installation. The affiliate action must be directly triggered by an explicit user action. Modifying links silently in the background is a policy violation regardless of how small the revenue is.

Rejection Risk #8: Deceptive Installation and Listing Tactics

This category covers a range of behaviors that Google treats as trust violations, not just policy oversights.

What Google explicitly prohibits:

• Misleading advertising for your extension (outside the Chrome Web Store) that misrepresents functionality
• Installation flows that trick users into installing additional extensions or changing browser settings without consent
• Using deceptive screenshots that misrepresent what the extension does on real pages
• Changing browser settings (homepage, new tab, search engine) without explicit, affirmative user consent — and reverting those changes when the extension is disabled

This last one catches a surprising number of developers who think a checkbox during onboarding is sufficient consent. It’s not. The consent must be clear, prominent, and separate from other onboarding steps.

Rejection message: “Your extension is in violation of the following section of our policy: Impersonation or Deceptive Behavior.”

The Complete Pre-Submission Checklist

Run through this before every new submission and every significant update:

Developer Account

• $5 registration fee paid
• 2-Step Verification enabled on Google account
• Contact email verified and monitored

Manifest & Code

• "manifest_version": 3 in manifest.json
• No obfuscated JavaScript (minification OK)
• No remote code execution (eval() on remote strings, external script tags)
• All dependencies bundled locally
• Every permission in manifest.json actively used in code
• Host permissions as narrow as possible
• No hardcoded secrets or API keys in extension bundle
• Version number updated from previous submission
• content_security_policy reviewed and appropriate

Privacy & Data

• Privacy practices disclosure completed in dashboard
• All data collection types checked accurately
• Limited use certification checked
• Privacy policy URL provided (if any user data handled)
• Privacy policy is live, HTTPS, publicly accessible, accurate

Store Listing

• 128×128 PNG icon (512×512 recommended)
• Short description ≤132 chars, accurate
• Full description matches code behavior, no keyword stuffing
• At least 1 screenshot at 1280×800 showing actual UI
• Small promotional tile at 440×280
• Single purpose description filled in
• Category selected accurately
• Release notes written (for updates)

Behavior

• Extension does one thing (single purpose compliant)
• No ad injection without prominent listing disclosure
• No affiliate links without pre-install disclosure
• No browser setting changes without explicit user consent
• Test credentials in reviewer notes (if login required)

Real Rejection Messages and What They Mean

Developers in the Google Chrome Extensions group and Reddit’s r/chrome_extensions share these constantly. Here’s the translation guide:

“Your item is not allowed to contain obfuscated code.” You have obfuscated JavaScript. Find it, remove it, replace with readable or minified code. No appeal path.

“Extensions using Manifest V2 are no longer accepted.” Your manifest_version is 2. Update to 3. Also check for MV2-specific APIs you’ll need to replace.

“Due to the Host Permission, your extension may require an in-depth review.” This is a warning, not a rejection. Your extension has <all_urls> or a broad host pattern. It’ll still be reviewed; expect weeks not days. Consider narrowing permissions.

“Your extension requests permission to access sensitive information.” You have tabs, cookies, history, or similar. Provide justification in reviewer notes. Remove if genuinely unused.

“The extension does not comply with our single purpose policy.” You’re bundling unrelated features. Audit your feature set and either remove unrelated functionality or split into separate extensions.

“Functionality could not be determined from the submitted code.” Almost always remote code execution. The reviewer couldn’t verify what your extension does because some logic lives outside your bundle. Fix: bring all logic in-house.

After You Submit: What’s Next

Publishing requirements don’t end at submission. Once live, your extension must stay compliant as Google updates policies (announced via developer email) and as you update your code.

Every significant update goes through review again. Adding new permissions means the update is scrutinized like a new submission. Adding data collection without updating your privacy policy is a policy violation.

The extensions that stay live long-term are the ones maintained proactively — policies watched, privacy disclosures updated, permissions audited on each release.

Once you’re published, your store listing quality directly determines your growth. Ratings and reviews signal trust to new users and feed Chrome Web Store’s search algorithm. Our AppBooster review platform helps extension developers build genuine review velocity from real users — no fake reviews, no bots, no policy risk.

Explore our free developer tools — the Icon Generator, MV2-to-MV3 Converter, and Tile Cropper — to make the technical side of submission faster. And when you’re ready to grow, check out our Chrome Web Store SEO guide to understand what drives ranking after you’re live.

Related guides from AppBooster:

• Chrome Web Store Extension Review Time 2026 — how long the wait actually is, by permission type
• Chrome Web Store Review Process Explained — what happens during review
• Top 8 Reasons Chrome Extensions Get Rejected — deeper dives on each rejection cause
• Chrome Extension Privacy & Permissions Guide — the full privacy compliance breakdown