Chrome extension privacy policy and Data Use: what reviewers actually check

1. When you need a privacy policy at all

If the extension handles user data in any way, you need a privacy policy URL registered in the Privacy practices tab. Handling is broader than most developers assume: it covers collecting, using, storing and transferring data, and it applies even when the data never leaves the browser.

An extension that reads page content to render something locally is still handling user data. So is one that keeps a record of what the user exported in chrome.storage. The safe reading is that if your code touches anything a person typed, visited, or owns, you disclose it.

2. The declaration has to match the code

This mismatch is a recurring reason privacy reviews fail. The dashboard asks which categories of data the extension handles and why. Reviewers compare those answers with the package they were given.

What triggers it

• The listing says data never leaves the browser, while the code sends a license key, telemetry, or crash reports
• An analytics library that sends usage data is bundled, but no matching category is declared
• The policy URL returns 404, sits behind a login, or describes a different product
• The declaration lists fewer categories than the code touches

3. Categories people forget to declare

• Authentication information — a license key, token, or account id sent to your server or a payment provider counts, even if it is one request at activation
• Website content — text, images, or DOM content read from the pages the extension runs on
• User activity — clicks, page views, or feature usage sent anywhere for product analytics
• Personal communications — chat or message content, which is what conversation exporters handle by definition
• Personally identifiable information — an email collected for a newsletter or a support form inside the extension

Every declared category should serve the extension’s single purpose or a related operational need you can explain — a category with no explainable purpose reads as over-collection, and a feature that handles data you never declared reads as an undisclosed transfer.

4. What the policy document should cover

Policy requirements vary with what you handle, but a policy that holds up under review is short, specific, and consistent with the dashboard. In practice it is worth stating:

• Who is responsible for the extension and how to contact them
• Which data categories are handled, named the same way as in the dashboard
• The purpose of each category, in plain sentences
• Where the data goes — your server, a payment provider, an analytics vendor, or nowhere
• How long it is kept, and how a user can ask for deletion
• If you handle sensitive data, how your use stays within the Limited Use requirements, and how users are told before anything is collected

5. Why this also causes post-publish removals

Permission and remote-code problems show up in the package itself. A privacy mismatch can hide longer, because the code path may only run for paying users or ship in a later update. When it surfaces then, the outcome is an enforcement action against a listing that already has users and revenue.

The practical defense is to treat the declaration as part of the release checklist. Any change that adds a network call, a bundled library, or a new storage key should also update the declaration and the policy.

6. Pre-submit checklist

• Is the privacy policy URL public, live, and about this extension?
• Does every network call in the code map to a declared category?
• Is local collection and storage declared, not just transfers?
• Does the listing copy avoid claims the code contradicts?
• Can you explain each declared category in terms of your single purpose?
• Are users told what is collected before it happens, and does any sensitive data stay within the Limited Use requirements?

The companion guide covers the other rejection reasons — remote code, host permissions, unused permissions, single purpose and listing quality: Why Chrome Web Store rejects extensions.