The Chrome Web Store review process rejects a lot of Manifest V3 extensions, and the rejection emails are often vague. Most of the time it’s one of a handful of recurring mistakes — and knowing them up front saves a rejected submission and a week of waiting.
Too many permissions
Asking for broad host permissions — access to all sites — when your extension only needs one is the fastest way to get flagged. Request the narrowest permissions that make the feature work, and use activeTab instead of blanket host access where you can.
Remote code and CSP violations
Manifest V3 forbids inline scripts, eval, and remotely hosted code. Pulling a script from a CDN at runtime, or a bundle that injects inline code, will fail review. All code must be packaged inside the extension — test the packed build, not just the dev version.
Leftover V2 patterns are another trap: background pages became service workers, so code that keeps state in memory or uses APIs that no longer exist breaks. Make the background logic event-driven and able to survive the worker shutting down.
Finally, the store wants a single, obvious purpose and an accurate privacy policy if you collect data. A “utility” that quietly does five unrelated things gets rejected. Narrow permissions, no remote or inline code, proper service worker patterns, and an honest privacy policy clear most rejections.