Understanding the Single Purpose Policy

The rejection email cites “Violation of Single Purpose policy”. The extension is a tab manager — and also, since last quarter, a new-tab dashboard with weather, a coupon finder, and a setting that changes the default search engine. Each addition seemed reasonable to the team. To a reviewer, the extension now does four unrelated things, which is exactly what the policy prohibits. The single purpose policy is one of the Chrome Web Store’s oldest rules and among the most misunderstood: it does not forbid multiple features, it forbids features that do not serve one narrow, easy-to-understand purpose. This guide explains how reviewers apply it and how to stay on the right side. It belongs to store submission and permissions compliance.

What the policy actually requires

The Chrome Web Store requires each extension to have a single purpose that is narrow and easy to understand. A purpose can be a topic (“everything to do with managing tabs”) or a function (“make reading articles easier”), and an extension may have many features as long as each serves that purpose. Two things are called out specifically. Extensions must not bundle unrelated functionality to gain installs or permissions — a calculator that also replaces the new tab page. And changes to browser settings such as the default search engine, new tab page or homepage are only acceptable when that change is the extension’s single purpose, not a side effect of something else. The underlying aims are user understanding — people should know what they installed — and minimal permissions, since every unrelated feature tends to bring its own.

Step-by-step: defining and defending your purpose

1. Write the purpose in one sentence

1Purpose: "Readable makes long articles easier to read and remember — a clean reading view,
2highlights and notes, and a searchable library of what you've saved."

Execution context: the developer dashboard’s single purpose field, the listing’s first line, and your team’s product documentation. One sentence a non-technical reviewer can read in five seconds. Every feature should be describable as “part of” that sentence. If you need “and also” to fit a feature in, it probably does not belong.

2. Check every feature against the sentence

1feature-audit.md
2Reading view ............... directly serves "easier to read"            ✓
3Highlights + notes ......... directly serves "remember"                  ✓
4Library search ............. directly serves "library of saved"          ✓
5Sync across devices ........ supports the library                        ✓ (explain)
6New tab page with weather .. unrelated                                   ✗ remove or separate
7Default search override .... unrelated, settings change                  ✗ remove

Execution context: a review document updated whenever features are proposed. Doing this audit before building a feature is far cheaper than after a rejection. Features that fail can become their own extension with their own purpose and permissions.

3. Keep settings overrides only when they are the product

1// Acceptable only for an extension whose purpose IS a new tab page
2{ "chrome_url_overrides": { "newtab": "newtab.html" } }
3
4// Search override: only for an extension whose purpose IS providing a search engine
5{ "chrome_settings_overrides": { "search_provider": { /* ... */ } } }

Execution context: the manifest. Overrides of the new tab page, homepage, startup pages and search provider are scrutinised heavily, because historically they were the main vehicle for unwanted changes. They also require the change to be clearly disclosed in the listing. A reading extension that also overrides the new tab page has two purposes; a new tab dashboard that also changes search has two settings changes, each needing justification.

4. Align permissions with the purpose

Each permission should be explainable as necessary for the single purpose. A reading extension requesting downloads for an export feature is fine with a sentence of justification; one requesting history and management invites the question of what unrelated feature they serve. The permission justification fields and the purpose statement are read together. See writing a permission justification that passes.

5. Make the listing match

The listing’s first paragraph should restate the purpose, the screenshots should show features that serve it, and nothing in the description should surprise a reviewer with an unrelated capability. Listings that bury an unrelated feature at the end of a long description are a common pattern reviewers look for.

6. Respond to a rejection constructively

If rejected, identify which feature the reviewer considered unrelated, then either remove it, move it to a separate extension, or — if you believe it serves the purpose — explain the connection concretely in the appeal and the listing. Re-submitting unchanged with a general disagreement rarely works. See responding to a policy violation takedown.

7. Build a review gate into planning

Add “Does this serve our single purpose?” to the feature proposal template, with the one-sentence purpose printed above it. It costs seconds per proposal and prevents the slow drift into a multi-purpose extension that a single reviewer eventually stops.

Common mistakes

• Adding growth features unrelated to the purpose. The most common violation.
• Settings overrides as side effects. New tab or search changes outside their own extension.
• A purpose statement so broad it means nothing. “Productivity tools” is not narrow.
• Permissions that hint at unrelated features. Reviewers ask why.
• Listings that hide secondary capabilities. Disclosure must be upfront.

Cross-browser variation

• Chrome / Edge: the Chrome Web Store’s single purpose policy; Edge Add-ons has similar requirements around clear functionality and settings changes.
• Firefox: AMO policies require add-ons to clearly describe functionality and restrict unexpected settings changes; bundling unrelated features draws review comments.
• Safari: App Review evaluates the containing app and extension together; unrelated bundled functionality is treated under Apple’s guidelines on app completeness and clarity.

Verification

1. Read the purpose sentence aloud, then list every feature; each should obviously belong.
2. Check every manifest permission maps to a feature that serves the purpose.
3. Confirm there are no settings overrides unless they are the purpose.
4. Ask someone unfamiliar with the product to read the listing and state what the extension does in one sentence.

FAQ

Can an extension have many features?

Yes. The policy limits the purpose, not the feature count.

Is “productivity” a single purpose?

Too broad. Narrow it to what the extension does: “manage tabs”, “read articles”, “save snippets”.

Can I link to my other extensions from inside one?

Yes, as long as the link is not a hidden feature or a forced install — a simple, honest link is fine.

Does monetisation affect single purpose?

Paid features that serve the purpose are fine. Monetisation through unrelated additions — affiliate injection, coupon widgets, search changes — is exactly what the policy targets.

Related

• Passing Chrome Web Store review — the broader review checklist.
• Reducing permission warnings at install — fewer features, fewer permissions.
• Choosing between popup, side panel and tab — organising features within one purpose.
• Store submission and permissions compliance — the parent topic.