A privacy policy is required whenever your extension handles user data. That covers more than most developers expect — anything personally identifiable, authentication information, website content, form entries, and general usage activity all count. In practice, if your extension reads what is on a page or remembers anything about the user, assume you need one.
The page itself has to work
Before the wording matters, the URL has to hold up — it must be accessible for review.
- Publicly reachable — no login, no "request access" screen, not a Google Doc set to restricted.
- A stable URL that will still resolve later, not a preview link that expires.
- Covers this extension. A company-wide policy is fine if its scope clearly includes this extension and describes its data handling accurately. What causes trouble is a policy a reviewer cannot match to what the extension does.
- Same URL in both places — the field in the developer dashboard and any link inside your extension should point to the same page.
What the page should answer
Chrome's core requirement is an accurate, current disclosure of what data is collected, how it is used and whether it is shared. The rest below is strong practice, and some items may be legally required for you depending on your users and jurisdiction.
- What is collected — name the categories plainly. "Page URLs of tabs the user chooses to save."
- Why — tie each category to a feature the user can see.
- Where it goes — stays on the device, or is sent to a server. If sent, say to whom.
- How long it is kept, and how a user can delete it.
- Third parties — analytics, error reporting, any hosted service that receives data.
- Contact — a working email address.
- Last updated date.
The mismatches that cause rejections
Common review problems are not a missing page at all. They are three descriptions of the same extension disagreeing: the privacy policy, the permission justifications, and the data disclosure checkboxes in the dashboard.
history or cookies is not collection by itself — what matters is whether the data is gathered, stored or transmitted.Before submitting, read all three side by side and make sure a stranger would describe the extension the same way from each.
Do not promise more than you do
"We never collect any data" is a strong claim, and it is worth separating two different statements: handling no user data at all, and collecting or transmitting nothing. An extension that stores settings locally is still handling data. If you also run a crash reporter or call your own API, the blanket sentence becomes inaccurate and the rest of the policy stops being trustworthy. Precise beats absolute:
If your data handling changes
Update the policy and the disclosure at the same time as the code. A version that adds a sync feature while the policy still says everything stays local may lead to rejection or enforcement at a later review.
Need a policy page now? The privacy policy generator asks what your extension actually does and produces a page you can publish and adapt. It runs in your browser. This page records an anonymous page-view count, and as with any web request, standard server logs may include your IP address and user agent.
The Chrome Web Store Submission Kit (paid, opens in a new tab) includes the disclosure-to-policy consistency checklist used above, plus justification templates.