Home › Resources

Chrome Extension Privacy Policy: What Google Requires and How to Create One

Published August 26, 2026

Every Chrome extension that handles user data needs a privacy policy URL before Google will approve it for the Chrome Web Store. The policy must be publicly accessible, describe exactly what data the extension collects and why, and match the data-use disclosures you certify in the Developer Dashboard. Skip it and the extension fails review. Submit a vague or generic document and the review team rejects it -- they read the policy, not just the URL field.

This guide covers when the Chrome Web Store requires a policy, what Google's review process actually checks, the data categories extension developers commonly overlook, how to fill out the Data Usage certification, where to host the finished policy and link it in your listing, and a complete sample policy you can copy. If you need a policy fast, you can generate a privacy policy for free and host it at no cost.

When Chrome Web Store Requires a Privacy Policy

Google's Chrome Web Store Developer Program Policies are explicit: any extension that handles personal or sensitive user data must provide a privacy policy. "Handling" includes collecting, transmitting, using, or sharing that data -- even temporarily. The requirement is enforced at the point of submission, not retroactively, so the policy must be in place before the first review.

Three conditions trigger the requirement:

• The extension requests permissions that access user data. Permissions like tabs, history, bookmarks, cookies, webRequest, identity, and any host permissions (e.g., *://*.example.com/* or <all_urls>) give the extension access to browsing data, authentication tokens, or page content. Requesting any of these means the extension can access user data, and Google treats that as handling it.
• The extension collects any information from the user. Form inputs, email addresses, preferences, usage analytics -- if the extension captures information a user provides or generates, the privacy policy field is mandatory.
• The extension uses remote code or connects to external services. Extensions that fetch scripts, send data to an API, or communicate with a backend server are transmitting information outside the browser. Google requires disclosure of what data leaves the device and where it goes.

Extensions that request zero data-touching permissions (for example, a simple theme or a CSS-only modifier with no host permissions) can skip the privacy policy field. However, even these extensions benefit from having one -- Google's review is faster when the data story is clear, and users see the policy link on the extension's Web Store listing page.

The requirement applies equally to public extensions, unlisted extensions distributed via direct URL, and extensions published to a managed Google Workspace domain. The distribution channel does not change the obligation -- the Developer Dashboard enforces the same fields regardless.

What Review Checks

Google's Chrome Web Store review runs in two stages. An automated pipeline scans the submitted ZIP for known patterns — permission usage, remote code references, manifest structure — and flags items for human review. A human reviewer then checks the flagged items against the Developer Program Policies. Extensions requesting sensitive permissions (webRequest, <all_urls>, tabs, identity, cookies) are routed to human review more frequently than extensions with narrow permissions like activeTab or storage. The reviewers check several specific conditions before approving an extension.

• The privacy policy URL loads to the actual policy text. The link must open directly to the privacy policy content -- not a homepage, not a generic legal page, not a link that redirects through a login wall or returns a 404. Google's reviewers test the URL and expect a 200 response that renders the policy immediately.
• The policy describes the extension's actual data practices. A boilerplate document about website cookies and server logs that never mentions browser extensions, permissions, or the specific data the extension accesses will be flagged. The content must be relevant to the extension being submitted.
• Declared permissions match the policy disclosures. If the extension's manifest.json requests activeTab, storage, and host permissions for specific domains, the privacy policy must explain why those permissions are needed and what data they access. Mismatches between the manifest and the policy trigger rejection.
• The Data Usage certification in the Developer Dashboard is consistent with the policy. The dashboard asks you to certify which data types the extension collects (see the certification section below). If the certification says "No data collected" but the policy mentions collecting browsing history, the submission fails.
• The extension does not collect more data than it needs. Google enforces a minimum-data principle: the extension must "collect and use the minimum amount of data needed" to fulfill its stated purpose. A tab manager that requests <all_urls> and reads page content when it only needs tab titles will be questioned during review.

Common rejection reasons and what the rejection emails say

When Google rejects a submission, the developer receives an email from "Chrome Web Store Developer Support" with a subject line starting "Your item was not published" or "Action required: Your extension [name]." The body cites a specific Developer Program Policy section. Here are the rejection patterns developers hit most often:

• Privacy policy URL missing or broken. The rejection email reads: "Your extension does not comply with the following Chrome Web Store policy: User Data Privacy — Prominent Disclosure. Your extension must provide a privacy policy." The field labeled "Privacy policy URL" in the Store listing tab is either blank or resolves to a non-200 status. Google's automated check fetches the URL before human review begins — a 404, redirect loop, or login wall stops the process immediately.
• Policy does not match the extension's data practices. The email states: "Your extension's privacy policy does not adequately disclose how user data is collected, used, and shared." This fires when the policy is recycled from a mobile app or website and never mentions Chrome permissions, the extension name, or browser-specific data flows. Reviewers cross-check the manifest.json permissions against the policy text.
• Excessive permissions without justification. The rejection references the "Use of Permissions" policy and reads: "Your extension is requesting permission(s) that are not required for implementing its functionality." The permissions that most frequently trigger this are <all_urls>, webRequest, webRequestBlocking (Manifest V2), tabs when activeTab would suffice, and clipboardRead on extensions that have no paste-related feature. Switching from tabs to activeTab alone resolves a large share of these rejections because activeTab grants access only to the current tab on user gesture, while tabs exposes the URL and title of every open tab.
• Remote code execution. The email cites the "Code Readability Requirements" policy: "Your extension is loading and executing remote code or modules that are not included in the extension package." Manifest V3 banned remotely hosted code effective January 2023. Extensions that use chrome.scripting.executeScript with dynamically constructed code strings, or that fetch() JSON configuration that alters runtime behavior, still get flagged. The policy requires all executable logic to be included in the submitted ZIP and reviewable in the code review.

Data an Extension Collects That Developers Overlook

Most extension developers disclose the obvious inputs: an email address from a login form, a search query typed into the popup. But Chrome extensions handle several less obvious data categories that trip up review and violate privacy laws if undisclosed.

• Permissions-based browsing data. The tabs permission exposes the title and URL of every open tab. The history permission exposes the user's full browsing history. The bookmarks permission exposes saved bookmarks. Even if the extension only reads this data locally and never transmits it, the capability itself means the extension is handling personal data under GDPR and CCPA definitions -- disclose it.
• Host permissions and page content. Host permissions (specific domains or <all_urls>) allow content scripts to read and modify page content. If a content script reads form values, scrapes text, or captures DOM elements from pages the user visits, that is personal data collection. Even reading a page title for display in the extension popup counts if it is stored or transmitted.
• The storage API. Data saved with chrome.storage.local or chrome.storage.sync persists across sessions. If the extension stores user preferences, authentication tokens, cached page data, or usage counters, those are persistent attributes tied to a user profile -- especially storage.sync, which is linked to the user's Google account and synced across devices.
• Remote code and API calls. Any fetch() call, WebSocket connection, or external script load transmits data outside the browser. Even a simple analytics ping or crash-report payload contains metadata (extension version, browser version, possibly URLs or error contexts) that constitutes data transmission.
• The identity API and OAuth. Extensions that use chrome.identity to authenticate users via Google OAuth receive profile data -- name, email, profile photo URL. Extensions that authenticate with third-party services via custom OAuth flows collect tokens and profile data the same way.
• Web request interception. The webRequest or declarativeNetRequest permissions let extensions observe or modify network requests. Even if the extension uses this to block ads or modify headers, the capability to inspect request URLs and headers means it has access to browsing patterns.
• Cookies. The cookies permission grants read and write access to browser cookies for specified domains. Cookies frequently contain session tokens, user IDs, and tracking identifiers -- all personal data.

The rule is straightforward: if the extension can access, read, store, or transmit anything that traces back to a specific user or device, disclose it in the policy. Not sure which privacy regulations apply to your extension's user base? A quick compliance check based on your platform and audience can clarify which laws require specific disclosures.

Required Disclosures and the Data Usage Certification

Since 2021, the Chrome Web Store Developer Dashboard includes a Privacy practices tab where developers must certify their extension's data handling. This certification is separate from the privacy policy URL but must be consistent with it. Contradictions between the two are a fast path to rejection.

To reach the certification, open the Developer Dashboard at chrome.google.com/webstore/devconsole, select your extension, and click "Privacy practices" in the left sidebar (it sits between "Store listing" and "Distribution"). The page is divided into three sections that must all be completed before you can submit for review.

Section 1 — "Single purpose." A text field labeled "What is the single purpose of your extension?" requires a plain-language description. Google enforces single-purpose policy strictly: if your description names two unrelated functions, reviewers may reject it. State the core function in one sentence.

Section 2 — "Permission justification." For each permission declared in your manifest.json, a row appears with the permission name and a text field labeled "Justification." Explain why the permission is needed in concrete terms. For example, if you request activeTab, write "Reads the current tab's URL to check it against the user's saved blocklist." Generic justifications like "needed for the extension to work" are flagged by reviewers.

Section 3 — "Data usage." This section asks you to certify which data types the extension collects. The data categories appear as checkboxes with these exact labels:

• Personally identifiable information — name, address, email address, age, date of birth, phone number, or Social Security number
• Health information
• Financial and payment information
• Authentication information — credentials, security questions, or personal identification numbers
• Personal communications — emails, texts, or chat messages
• Location — region, IP address, GPS coordinates, or geolocation data
• Web history — list of web pages the user has visited
• User activity — network monitoring, clicks, mouse position, scroll, or keystroke logging
• Website content — text, images, sounds, videos, or hyperlinks from websites the user visits

For each checked category, a follow-up asks whether the data is "Used locally only" or "Transferred out of the user's device." If you select "Transferred," you must specify whether the destination is your own servers, third-party servers, or both.

Below the data categories, two certification statements appear as checkboxes that you must affirm or deny:

• "I certify that my extension doesn't sell user data to third parties, outside of the approved use cases described in the Chrome Web Store Developer Program Policies."
• "I certify that my extension doesn't use or transfer user data for purposes that are unrelated to the item's single purpose."

These pledges appear on the extension's Chrome Web Store listing under a "Privacy practices" section visible to users before they install. If your privacy policy says data may be shared with advertising partners but you certify that data is not sold or used for unrelated purposes, the inconsistency can lead to removal from the Web Store.

How the certification maps to your privacy policy

Think of the Developer Dashboard certification as a structured summary and the privacy policy as the full-text version. Every data type you check in the dashboard must have a corresponding section in the policy explaining what is collected, why, who receives it, and how long it is retained. The certification is the machine-readable declaration; the policy is the human-readable one. Both must tell the same story.

Writing a privacy policy that covers permissions, data types, and third-party transfers follows the same process as writing a privacy policy for any app: audit your data flows, map them to purposes, identify third parties, and draft each required section.

Hosting the URL and Where to Paste It

The privacy policy needs a permanent, publicly accessible URL that loads without authentication on any device. Three hosting approaches cover most Chrome extension developers.

Hosting options

• Your own domain. If you have a website, host the policy at a path like yoursite.com/chrome-extension-privacy-policy. This is the most professional option and gives you full control over updates.
• A free hosted policy. If you do not have a website or do not want to manage hosting, you can generate and host a privacy policy for free. The generated URL is permanent and loads without authentication, which satisfies Google's requirements.
• GitHub Pages or a static site. A free GitHub Pages site with a single HTML page works. The URL is stable and publicly accessible. Ensure the page renders on mobile -- Google's review checks across devices.

Do not use Google Docs, Notion pages, Pastebin links, or any URL that requires login, displays editing UI, or could change without a stable permalink. These are rejected during review.

Adding the URL in the Chrome Web Store Developer Dashboard

1. Open the Chrome Web Store Developer Dashboard and select your extension.
2. Click the Store listing tab in the left sidebar.
3. Scroll to the Privacy policy field. Paste your full URL including https://.
4. Click the Privacy practices tab. Complete the Data Usage certification by selecting the data types your extension handles and their purposes. Every selection must match what your privacy policy describes.
5. Save all changes and submit for review.

After approval, the privacy policy link appears on your extension's Chrome Web Store listing page under the "Additional Information" section. Users can review it before installing. The Alexa Skills Store has a similar requirement for Alexa skills, and Discord blocks bot verification without a working policy in the Developer Portal -- the pattern of platform-mandated policies before distribution is standard across app ecosystems.

Sample Chrome Extension Privacy Policy You Can Copy

Below is a complete privacy policy written for a fictional Chrome extension called "[Your Extension Name]." It covers the data categories most extensions handle -- permissions-based browsing data, stored preferences, authentication, and external communications. Copy the entire block, replace the bracketed placeholders with your extension's details, and remove any sections that do not apply.

This sample covers the most common Chrome extension data flows. If your extension handles additional data -- such as health information, financial data, or biometric identifiers -- add dedicated disclosure sections for those categories. Need to generate a policy tailored to your exact permissions and data practices instead of editing a template? You can build one for free with the generator.

Frequently Asked Questions