The Ultimate Chrome Extension Pre-Submission Checklist (2026)

Most Chrome extension rejections are preventable. Google’s review team rejects extensions for the same recurring reasons: obfuscated code, missing privacy policies, overly broad permissions, or store listings that don’t match actual functionality.

A thorough pre-submission review catches the majority of these issues before they cost you review cycles. This checklist walks you through every phase—code, permissions, privacy, store listing, testing, and dashboard—before you hit that submit button.

Work through each phase sequentially. Check off every item. Most extensions are reviewed within 24 hours, with 90% cleared within 3 days—don’t waste that window on avoidable issues.

Phase 1: Code & Security

Your extension’s code is the first thing automated review systems and human reviewers examine. Violations here trigger immediate rejection with no appeal shortcut.

Phase 2: Permissions Audit

Permissions are the single most common reason for policy violations. Every permission you request must be demonstrably necessary for your extension’s stated purpose.

Only the narrowest required permissions — If your extension reads tab URLs, request tabs not <all_urls>. If you only need active tab data, use activeTab instead of broad host permissions.
No unused permissions — Audit your manifest.json against your actual code. Remove any permission that isn’t called by your code. Automated tools exist specifically to flag this mismatch.
Each permission documented and justified — Prepare a plain-language explanation for every permission: what it enables and why your extension cannot function without it. This goes in your test instructions.
No excessive host permissions unless required — *://*/* requires strong justification. If your extension works on specific domains, list those domains explicitly.
Optional permissions for non-core features — Features used by a subset of users should request permissions via chrome.permissions.request() at runtime rather than requiring them at install.

Quick Permission Reference

Permission	When to Use	Common Mistake
`activeTab`	Reading/modifying current tab only	Requesting `tabs` instead
`storage`	Saving user preferences	Using `localStorage` in service workers
`scripting`	Injecting scripts dynamically	Hardcoding all injections in manifest
`contextMenus`	Right-click menu items	Requesting when feature is optional
`notifications`	User alerts	Requesting for a rarely-used alert

Phase 3: Privacy Compliance

Privacy policy violations account for a large share of rejections, particularly for extensions handling any user data. “User data” is broadly defined—it includes browsing history, tab URLs, form inputs, and anything a user types or clicks while your extension is active.

Privacy policy written and comprehensive — Your policy must cover: what data is collected, how it’s used, how it’s stored, how long it’s retained, who it’s shared with, and how users can request deletion.
Privacy policy link valid and accessible — The URL must resolve to a live, public page. A 404 or redirect loop will fail review. Test the link in an incognito window.
Policy matches actual data handling — If your code sends tab URLs to your server but your policy says “we don’t collect browsing data,” that’s a policy violation. Audit your network calls and align your policy with what your code actually does.
Single purpose declaration aligns with functionality — Your extension must serve one primary purpose. An extension that blocks ads and also tracks competitor prices and also sends email newsletters is three extensions. Focus the purpose statement on what the extension primarily does.
All data collection disclosed — In the Chrome Web Store dashboard under Privacy Practices, every category of data you collect must be checked. Undisclosed data collection is grounds for removal, not just rejection.
Third-party sharing disclosed — If you use analytics (Google Analytics, Mixpanel), crash reporting (Sentry), or any third-party SDK, those must be disclosed. The SDK’s data collection counts as your data collection.

Phase 4: Store Listing

A technically perfect extension can still be rejected or underperform if the store listing is misleading, incomplete, or inconsistent with the extension’s actual behavior.

Clear, meaningful extension name — Names cannot include “Chrome” as a standalone word (it implies Google endorsement). The name should describe the extension’s function, not just a brand name.
Compelling short description — 132 characters max. Lead with the core value proposition. Avoid “best,” “free,” and superlatives without evidence. Focus on what the user gains.
Detailed full description — List all features, use cases, and permissions. If your extension requests the tabs permission, explain in the description why it’s needed. Reviewers compare description claims against functionality.
High-quality icon — 128x128 PNG minimum, but submit 512x512 for future-proofing. Transparent background, no text that becomes unreadable at small sizes, and visually distinct at 16x16.
3-5 crisp, annotated screenshots — Screenshots must show actual extension UI, not marketing graphics. Dimensions: 1280x800 or 640x400. Annotate with callouts to highlight key features.
Optional: marquee image — 1400x560 PNG/JPEG for featured placement. Clean design, no text-heavy layouts, readable at reduced sizes.
Optional: demo video — YouTube URL showing the extension in action. 60-90 seconds is the effective range. Actual usage footage outperforms animated mockups.
Appropriate category selected — Miscategorized extensions get less organic discovery. Choose the category that matches your primary use case, not the most popular category.
Description matches actual functionality exactly — Any feature mentioned in the description must exist and work. Any feature that exists but isn’t mentioned will look suspicious to reviewers if they find it.

Phase 5: Testing

Submit an extension you’ve actually stress-tested. Reviewers test extensions too, and they will find bugs you didn’t.

Tested on multiple Chrome versions — Test on the current stable, beta, and one major version back. APIs behave differently across versions.
Tested on multiple operating systems — File paths, system fonts, and keyboard shortcuts behave differently on Windows, macOS, and Linux. Test on at least two.
Tested on slow/unreliable networks — Use Chrome DevTools’ network throttling. Your extension should degrade gracefully, not crash, when API calls time out.
Error handling for network failures — Every fetch() call needs a .catch() handler. Service workers should handle offline scenarios. Unhandled promise rejections appear in reviews.
No back/forward cache invalidation — Extensions that add unload listeners prevent pages from being cached in the back/forward cache. Use pagehide with event.persisted check instead.
All advertised features work as described — Do a fresh-install walkthrough of every feature listed in your store description. Fix anything that doesn’t match.
Extension works as a fresh install — Disable the extension, clear extension storage, re-enable it, and test onboarding. Many bugs only appear on first run.

Phase 6: Dashboard Completion

Every tab in the Chrome Web Store developer dashboard must be complete before submission. Incomplete tabs block the submit button or cause delayed reviews.

Package tab: ZIP uploaded — Your ZIP must contain manifest.json at the root level, not inside a subfolder. Maximum file size is 500MB (keep it under 10MB for faster review).
Store listing: all fields completed — Title, short description, full description, category, language, icon, and at least one screenshot. Missing fields prevent submission.
Privacy: data practices disclosed — The Privacy Practices tab requires you to classify every type of data your extension handles. Be thorough—undisclosed practices are grounds for removal after publishing.
Distribution: country and visibility set — Choose public or unlisted. Select your target regions. Extensions set to private never go through public review.
Test instructions provided — If your extension requires login, API keys, or specific setup steps to review, include detailed instructions in the “Notes for reviewers” field. Reviewers who can’t test your extension may reject it.

Phase 7: Final Checks

Before clicking submit, run through this final gate.

No deceptive practices or hidden features — No hidden functionality, no dark patterns, no features that activate after review approval. Everything must be visible and working at review time.
Single, focused purpose — If you’ve added features since you wrote your purpose statement, revisit it. Purpose creep is a policy violation.
Proper error handling throughout — Review your error boundaries. Unhandled exceptions in service workers will cause the extension to stop working silently.
Performance optimized — Service workers must complete initialization quickly. Extensions that cause measurable browser slowdown attract negative reviews that compound over time.
Ready for review — You wouldn’t submit code to production without review. Treat the Chrome Web Store submission the same way.

Publishing Limits and Operational Tips

Account limits:

Maximum 20 published extensions per developer account
New developer accounts have a $5 one-time registration fee
Suspended accounts lose access to all published extensions

Deferred publishing:

You can schedule publication up to 30 days after approval
Use this window to coordinate launch with marketing, email campaigns, and social announcements
Approval does not mean immediate publication unless you’ve selected auto-publish

Notifications:

Enable email notifications for both staging and publishing events in your developer dashboard settings
Review feedback arrives via email—missing these delays your response time

Review timeline expectations:

Most submissions: under 24 hours (90% within 3 days)
First submissions or complex permissions: may take longer
For a full breakdown of the review process, see our Review Process guide

Quick Reference: What Gets You Auto-Rejected

These violations trigger rejection without human review escalation. Avoid all of them.

Violation	Why It’s Rejected	Fix
Code obfuscation	Reviewers cannot assess safety	Use minification, not obfuscation
Manifest V2	MV2 is deprecated, no longer accepted	Migrate to MV3
Remote code execution	`eval()` on fetched data	Parse JSON safely, no `eval()`
Missing privacy policy	Required for any data-handling extension	Write and host a proper policy
Deceptive description	Functionality doesn’t match listing	Update description to match code
Malicious behavior	Any code that harms users or systems	Do not submit
Excessive permissions	Permissions not justified by functionality	Request minimum required permissions
External scripts	Loading JS from remote at runtime	Bundle all JS in the package
Undisclosed data collection	Data practices not declared in dashboard	Complete Privacy Practices tab
Policy-violating content	Content that violates Chrome Web Store policies	Review policies before submission

Conclusion

The developers who get through Chrome Web Store review fastest aren’t necessarily the best coders—they’re the most prepared. Running through this checklist before every submission eliminates the most common rejection causes and demonstrates to reviewers that you understand and respect Chrome’s policies.

One submission done right beats three submissions with back-and-forth rejections every time. Your users are waiting.

Prepare your store listing assets before you submit.

Use the Screenshot Makeup Tool to create crisp, professional screenshots that meet Chrome Web Store dimensions and help your extension stand out.

Ready to grow your extension after it’s live? Sign in to ExtensionBooster to start collecting genuine reviews and building credibility from day one.

Related guides:

Chrome Web Store Review Process Explained — what happens after you submit
Top 8 Reasons Extensions Get Rejected — detailed breakdown of each rejection cause
Privacy & Permissions Guide — deep dive into Phase 2 and Phase 3
Store Listing Optimization — maximize Phase 4 for better conversions