Chrome Web Store Policy Changes in 2026
Stay compliant with every Chrome Web Store policy change in 2026. Privacy Sandbox impact, Manifest V3 deadlines, new disclosure rules, and action checklists.
Table of Contents
The Chrome Web Store is tightening its policies faster than at any point since Manifest V3 was first announced. The theme across all 2026 changes is transparency: Google wants users to understand exactly what an extension does, what data it accesses, and why. Extensions that operated in grey areas — collecting analytics without disclosure, requesting broad permissions "just in case," or bundling monetization without clear consent — are the primary targets.
This is not speculation. The policy update documents, developer blog posts, and enforcement actions from Q1 2026 paint a clear picture of where things are heading.
Timeline of 2026 policy changes#
Every confirmed and announced policy change, in chronological order. Dates reflect enforcement start dates, not announcement dates.
- 🔒
January 15, 2026 — Enhanced privacy disclosures
All extensions must include a detailed privacy practices section in the store listing. The old single-paragraph privacy policy link is no longer sufficient. Extensions must declare every data type collected, whether it is sold or shared, and the specific purpose for each data type.
- ⚠️
March 1, 2026 — Manifest V2 final sunset
Manifest V2 extensions are no longer loadable in Chrome stable channel. Previously disabled MV2 extensions are removed from user browsers. No exceptions, no enterprise extensions, no grandfathered items. This is the hard cutoff.
- 📋
June 1, 2026 — Permission justification requirement
Any extension requesting host permissions, storage, or identity APIs must submit a written justification during the review process. Justifications are reviewed by human reviewers, not automated systems. Insufficient justifications trigger rejection.
- 💰
August 15, 2026 — Monetization transparency rules
Extensions with any form of monetization — subscriptions, one-time payments, affiliate links, sponsored content — must display a visible monetization disclosure within the extension UI. The disclosure must be accessible within two clicks from the main interface.
- 🤖
October 1, 2026 — AI feature disclosure mandate
Extensions that use AI/ML models, send data to AI APIs, or generate AI-powered content must disclose this prominently in both the store listing and the extension UI. Users must be able to opt out of AI processing of their data.
- 🔍
December 2026 (tentative) — Third-party code audit requirement
Extensions with 100,000+ active users must submit to a third-party security audit. Google is finalizing the approved auditor list and cost-sharing program. Expected to be mandatory for large extensions and optional with a trust badge for smaller ones.
Detailed breakdown of each change#
Each policy update has nuances that the summary announcements do not cover. Here is what the actual policy language means for your extension.
Privacy Sandbox impact on extensions#
The Privacy Sandbox changes affect extensions more than most developers realize. Several APIs that extensions commonly use for analytics, ad blocking, and user tracking are being modified or restricted.
Third-party cookie deprecation: Extensions that inject content scripts into pages and rely on third-party cookies for session tracking or analytics lose that capability. The replacement is the Topics API and Attribution Reporting API, neither of which is designed for extension use cases. If your extension tracks cross-site user behavior for analytics, you need to move to first-party storage using chrome.storage.local.
User-Agent reduction: Extensions that parse User-Agent strings for compatibility checks or analytics segmentation must switch to the User-Agent Client Hints API (navigator.userAgentData). The old User-Agent string is frozen and no longer contains accurate browser version or platform details.
Network request observability: The move from webRequest to declarativeNetRequest was part of Privacy Sandbox, and with MV2 sunset in March, there is no longer any way to synchronously intercept and modify network requests. Ad blockers and privacy extensions have adapted, but extensions with custom network logic need to verify their declarativeNetRequest rules are equivalent to their old webRequest handlers.
Compliance action items#
Work through these checklists to ensure your extension meets all 2026 requirements. Start with the items that have the earliest deadlines.
Checklist
- Audit your extension's data collection — list every data type touched, even analytics
- Update your store listing privacy disclosure with the new structured format
- Verify your extension runs on Manifest V3 with no MV2 API calls remaining
- Test your service worker lifecycle — ensure it handles suspension and restart correctly
- Document a permission justification for every permission in your manifest.json
- Remove any permissions you requested 'just in case' but don't actively use
- Add a monetization disclosure page to your extension UI if you have any revenue source
- Inventory all AI/ML features and prepare the standardized disclosure
- Add a user-facing toggle to disable AI features while keeping core functionality
- Review all third-party dependencies for known vulnerabilities
- Set up automated dependency scanning with npm audit or Snyk
- Create a compliance calendar with all 2026 deadline dates
- Subscribe to the Chrome Extensions developer mailing list for updates
- Test your extension with the Chrome Beta channel to catch issues before stable release
What the enhanced review process means in practice#
Google has increased the review team size by 40% in 2026, and the review process itself has changed. Understanding the new review workflow helps you avoid rejections.
Previously, most extensions went through automated review only, with human review triggered by flags. The new process adds a human review step for any extension that:
- Requests more than three permissions
- Has more than 10,000 active users
- Handles financial data, health data, or authentication
- Includes a service worker longer than 500 lines
- Uses any AI/ML APIs or models
Human reviewers check three things: (1) does the extension do what the listing says it does, (2) are permissions justified by visible features, and (3) does the data handling match the privacy disclosure. Review times have increased from an average of 1 day to 3-5 days for flagged extensions.
With review times stretching to 5 business days for flagged extensions, do not wait until the deadline week to submit compliance updates. Give yourself a two-week buffer before every policy deadline. If your update is rejected, you need time to fix and resubmit.
API deprecation timeline#
Several Chrome extension APIs are deprecated or being replaced in 2026. If your extension uses any of these, plan your migration now.
| Feature | Deprecated API | Replacement | Removal Date | Migration Effort |
|---|---|---|---|---|
| chrome.extension.getBackgroundPage() | Service worker messaging | March 2026 | Medium | |
| chrome.extension.getURL() | chrome.runtime.getURL() | March 2026 | Trivial | |
| chrome.tabs.getAllInWindow() | chrome.tabs.query() | March 2026 | Low | |
| chrome.webRequest.onBeforeRequest (blocking) | declarativeNetRequest | March 2026 | High | |
| document.execCommand('copy') | navigator.clipboard.writeText() | June 2026 | Low | |
| chrome.identity.getAuthToken() (implicit) | OAuth PKCE flow | August 2026 | Medium | |
| Unstructured privacy policy link | Structured privacy disclosure | Already enforced | Medium |
The highest-risk migration is webRequest to declarativeNetRequest. If your extension modifies network requests dynamically based on runtime conditions, you may need to rearchitect your approach entirely. Static rulesets are powerful but fundamentally different from the imperative webRequest model. See our deep dive on Manifest V3 permissions best practices for detailed migration patterns.
Preparing for the security audit requirement#
Even if your extension has fewer than 100,000 users today, preparing for the security audit now is smart. The audit checklist overlaps heavily with general best practices, and fixing issues proactively is far cheaper than fixing them under deadline pressure.
The security audit requirement is expected in December 2026, but the approved auditor list and scheduling system will likely be announced in September or October. Firms with audit capacity will fill up fast. If you expect to cross 100,000 users before year-end, contact potential auditors now and get on their calendar. The audit itself covers code review, network traffic analysis, and dependency scanning — all things you should be doing regardless.
Common issues that fail security audits in other ecosystems (and will likely fail Chrome Web Store audits):
- Bundled dependencies with known CVEs that have available patches
- Hardcoded API keys or tokens in source code
- Overly broad content security policies
- Network requests to undisclosed domains
- Eval() or similar dynamic code execution
- Lack of input sanitization in content scripts
For a broader look at handling policy compliance and store rejections, read our guide on handling Chrome Web Store rejections. The rejection patterns we documented there map directly to the 2026 policy enforcement priorities.
Continue reading
Related articles
Data Handling Compliance for Extensions
Navigate GDPR, CCPA, and Chrome Web Store data policies for your extension. Covers consent flows, data deletion, privacy manifests, and third-party data sharing rules.
Inside the Chrome Web Store Review Process in 2026
A detailed look inside Chrome Web Store's review process in 2026. Learn what reviewers check, common rejection reasons, review timelines, and how to pass review on the first try.
Manifest V3 Permissions: Best Practices
Best practices for requesting and managing permissions in Manifest V3 Chrome extensions. Covers required vs optional permissions, host permissions, and review implications.