Rejection notices are short and often feel generic. A generic notice does not by itself tell you how extensively the submission was reviewed; it may identify only the relevant policy category. Either way, the work is the same: translate the policy reference into a specific change in your package.
Read the notice for two things
- The policy name. Permissions, remote code, user data, deceptive installation, spam, minimum functionality — each points at a different part of the submission.
- Any item that is quoted. If the notice quotes a permission, a URL or a listing field, that is the concrete thing to start from.
If the notice names a policy but quotes nothing, treat the whole category as in scope. With a permissions rejection and no permission named, review both what you declare and how each one is justified — the notice alone may not identify the exact issue.
Fix before you argue
The instinct is to reply explaining that the reviewer misunderstood. Sometimes that is right. But a resubmission with an actual change attached gives the next review something concrete to check, and it costs you less if your reading was wrong.
Change the whole category, not just the quoted line
If one permission was called out, review every permission. If one listing image was called out, review the whole listing. The next review may identify other issues in the package or listing, and a second rejection for a neighbouring problem costs another cycle.
How to word the resubmission note
Keep it to three parts and no more:
2. Why the extension needs what remains, in user terms.
3. What the extension does not do — no transmission, no background collection — only if true.
Avoid restating the policy back to the reviewer, and avoid promises about future versions. The submission is judged on what is in the package now.
When an appeal makes sense
An appeal is worth considering when you can point to something factual the notice got wrong — a permission you do not declare, a behaviour your code does not have, a URL that is reachable and was reported as unreachable. Attach the evidence: the manifest line, the file path, the working link.
For a judgement call about clarity, rewriting the unclear part is usually less effort than arguing that it was already clear.
If it happens repeatedly
Repeated rejections in the same category may indicate that the three descriptions of your extension disagree — the code, the justifications, and the listing. Read them side by side and make a stranger able to describe the extension the same way from each.
Before you resubmit, run your manifest through the free checker — it lists what you declare and flags the parts reviewers question most. Your manifest is read in your browser and is not uploaded; the page itself records an anonymous view count, and standard server logs may include your IP address.
The Chrome Web Store Submission Kit (paid, opens in a new tab) includes the resubmission checklist, justification templates and a privacy policy template.
PC Wise AI