Chrome Web Store Extension Review Time 2026: How Long Does It Actually Take?

You submitted three days ago. The dashboard still says “Pending Review.” You’ve refreshed it eleven times today. Is that normal? Did something go wrong? Should you resubmit?

Breathe. Here’s what’s actually happening — and a precise breakdown of how long Chrome Web Store extension reviews take in 2026, depending on exactly what’s in your manifest.

The Two-Track Review System (And Why It Changes Everything)

Chrome Web Store review isn’t one process. It’s two, and which track you land on determines whether you’re waiting hours or weeks.

Track 1 — Automated fast review. Google’s systems scan your extension for known malware signatures, policy red flags, and code patterns. For simple extensions — clean code, narrow permissions, no sensitive APIs — this can complete in under an hour. Manifest V3 extensions with only activeTab permission have been reported processing in as little as a few minutes.

Track 2 — Manual in-depth review. A human reviewer examines your code, validates your permission justifications, and checks that your extension actually does what your listing claims. This is where time stops being predictable.

The official documentation from Google’s review process page states that extensions with broad host permissions, sensitive execution permissions, or complex code “may require a more thorough review.” That’s the diplomatic version. The real version: requesting <all_urls> or tabs will almost certainly kick you to Track 2.

Key diagnostic: If your submission has been pending for more than 12 hours and you haven’t received any email, you’re almost certainly in manual review territory.

Review Time by Permission Type: The Honest Breakdown

This is what developers actually want to know. Here’s the data based on Google’s documentation, developer forum threads, and community reports:

Google’s own docs note that if your extension remains pending for more than three weeks, you should contact support — which implicitly tells you that three weeks is within the normal range for in-depth reviews.

Minor code-only updates to existing extensions move considerably faster: 1–3 days in most cases, sometimes under 24 hours. Major updates that add permissions get treated almost like new submissions.

What Actually Happens During an In-Depth Review

I know what you’re thinking: “What are they even checking for three weeks?” Fair question.

When an extension hits manual review, the reviewer needs to:

1. Read your code. Not scan — read. They’re checking that your code matches your listing description, that permissions are genuinely used, and that nothing looks like it could exfiltrate data or hijack user behavior. An extension with <all_urls> could theoretically read every page a user visits. That demands serious verification.

2. Test your functionality. They’ll load your extension, click through it, and verify it does what you claim. If your extension needs login and you didn’t leave test credentials in the reviewer notes field, they may not be able to complete this step — which causes delays or rejection for “non-functional extension.”

3. Verify your permissions are justified. Each sensitive permission has to have an obvious, demonstrable use case visible in the extension’s actual behavior. “I might use it later” doesn’t cut it.

4. Cross-check your privacy policy. If you handle user data, they’re checking that your privacy policy URL works, loads over HTTPS, and actually describes what the code does. A policy that says “we collect nothing” paired with code that makes analytics requests is a hard rejection.

The check-review documentation notes that email notifications from chromewebstore-noreply@google.com carry all status updates. Check your spam folder before panicking.

The Five Factors That Guarantee a Slower Review

Some developers submit and wait two days. Others wait three weeks for an identical extension type. These five factors explain almost all of that variance:

1. Broad host permissions. <all_urls>, https://*/*, http://*/* — any of these patterns is the single biggest predictor of a long review. The official warning message in the developer dashboard even says: “Due to the Host Permission, your extension may require an in-depth review which will delay publishing.” They’re telling you directly.

2. Being a new developer. First submission from a new account gets scrutinized harder. Your account has no trust history. Expect the upper end of review time ranges for your permission profile.

3. Submitting code changes alongside listing changes. Updating your title, description, screenshots, and code all at once forces reviewers to evaluate more surface area simultaneously. When possible, separate listing-only updates from code updates.

4. Friday submissions. Reviewers don’t appear to work weekends at full capacity. Submissions queued Friday afternoon often don’t move until Monday. Tuesday through Thursday tend to produce the fastest turnaround.

5. Significant code changes without a version bump or release notes. Always update your manifest.json version number and fill in the release notes field. Reviewers reference these. A resubmission without any of this context reads as potentially hiding something.

How to Accurately Estimate Your Own Review Time

Stop refreshing the dashboard and start doing this instead.

Step 1: Audit your permissions. Open your manifest.json. Look at every entry in permissions and host_permissions. For each one, ask: does my code actively use this? Is there a narrower alternative?

Step 2: Classify yourself. New account or existing? New extension or update? Using <all_urls> or specific domains? Using tabs, cookies, history, webRequest?

Step 3: Apply the table above. Combine your permission profile with your account status and you have a realistic range.

Step 4: Add buffer for complexity. Large codebase (many files, significant bundle size)? Complex functionality that needs thorough testing? Add a few days.

The formula isn’t perfect — Google doesn’t publish a detailed SLA. But developers who understand this framework stop being surprised. An extension with activeTab only, from an established account, on a Tuesday? Probably approved today. An extension with <all_urls> plus tabs plus cookies, from a brand-new account? Plan for two to four weeks.

What to Do While You’re Waiting

This is genuinely the most useful section for developers in the queue right now.

Do not resubmit to “reset” the queue. This is the most common mistake. Resubmitting an extension that’s pending review doesn’t speed things up — it restarts the review clock entirely and may flag your account for rapid re-submissions. Wait.

Use the time to prep your launch. Your extension will be approved. Plan what happens next: email your waitlist, schedule your Product Hunt post, set up your AppBooster developer profile to start building visibility the moment you go live. Extensions that launch with momentum convert better.

Build your store listing. Reviews of listing-only changes are faster than code reviews. While your code is being reviewed, you can still update your screenshots, sharpen your description, and refine your short description (which drives store search ranking).

Check your email obsessively — just not your dashboard. All actionable communications come via email from chromewebstore-noreply@google.com. The dashboard status indicator often lags behind the actual review state.

Line up your first reviews. Extensions that launch with reviews and ratings get better placement in search results and the “New & Featured” section. Platforms like AppBooster connect you with real users who leave honest reviews — worth setting up before your approval lands, not after.

The Appeals Process (If Things Go Wrong)

If you hit three weeks without movement, or if your extension is rejected and you disagree with the decision:

1. Go to Chrome Web Store One Stop Support
2. Select “My item was warned/removed/rejected”
3. Write a clear, factual explanation — reference the specific policy the reviewer cited, explain why your extension is compliant, provide evidence if you have it
4. Submit and expect 3 business days for a response

Emotional appeals don’t work. Policy references do. Keep it professional and specific.

One thing to know about appeals: you get one per violation decision. Frivolous appeals can forfeit your future appeal rights. Use them carefully.

The Fastest Path to Approval in 2026

None of this is secret. Google’s documentation is remarkably transparent about what slows reviews. Here’s the compressed version:

• Use activeTab instead of tabs wherever possible
• Replace <all_urls> with specific host patterns (e.g., https://api.yourservice.com/*)
• Remove every permission your code doesn’t actively use
• Never obfuscate JavaScript — minification is fine, obfuscation is an automatic rejection
• Bundle all dependencies locally, no remote script loading
• Leave test credentials in reviewer notes if login is required
• Write clear, human-readable release notes on every update
• Submit Tuesday through Thursday, not Friday

Do all of that and you’re looking at hours to a few days, not weeks.

Update Reviews vs. New Submissions: A Different Animal

Worth clarifying because the rules are slightly different — and developers often get caught off guard when a routine update takes three times longer than expected.

Updates move faster. Your account already has trust history. Reviewers compare the diff between your previous approved version and the new one rather than auditing the entire codebase from scratch. A minor bug fix or UI tweak from an established account can clear in under 24 hours.

Except when they don’t. These update scenarios get treated like brand-new submissions:

• You added a new permission (even a seemingly minor one)
• You changed or expanded your host permissions
• You significantly rewrote a large portion of the codebase
• You’re adding a feature that changes what data your extension handles

In all those cases, expect the full review timeline for your permission profile, not the fast-track update timeline.

The version number and release notes fields matter more than developers realize. Reviewers read them. A clearly written release notes entry like “Fixed null pointer in content script; no permission changes” signals a low-risk update. An update with no release notes and a changed permission set looks suspicious, even if it isn’t.

One more thing: you cannot withdraw or replace an update while it’s in manual review. If you submitted a bad build, you’re waiting. This is why staging your extension as a trusted tester before submitting the public update is worth the friction.

Common Myths About Review Time (Busted)

Myth: Resubmitting resets the queue and moves you up. Reality: It restarts the clock entirely and may flag your account for rapid resubmissions. Don’t do it.

Myth: Google reviews are slower on weekends. Reality: Mostly true — but not universally. Some developers report weekend approvals; most don’t. The safest assumption is Tuesday–Thursday for fastest turnaround.

Myth: Paying the $5 fee faster or upgrading anything speeds up review. Reality: No. There is no paid fast-track lane. The $5 is a one-time account registration fee, not a per-submission processing fee.

Myth: Your extension being “featured” helps it get reviewed faster. Reality: Featured status is evaluated after publishing, not during review. It has no effect on review speed.

Myth: If you’ve been approved before, your next extension goes faster. Reality: Account trust helps at the margins, but the permission profile of each individual extension still determines which review track it lands on. A new extension with <all_urls> from a veteran developer account still triggers manual review.

After Approval: Your Store Listing Becomes Your First Impression

Review time matters. But what happens after approval matters more.

The Chrome Web Store algorithm surfaces extensions based on ratings, review velocity, and user engagement signals. An extension that launches with 10 genuine reviews outperforms one with zero, every time — and that gap compounds over weeks and months.

Our free developer tools at AppBooster include an Icon Generator, Screenshot Makeup Tool, and Tile Cropper to help you build a listing that converts browsers into installers. And once you’re live, our review growth platform connects you with real users actively looking for extensions like yours.

Check out our complete Chrome Web Store publishing requirements guide to make sure your submission is airtight before you hit submit.

Further reading from AppBooster:

• Chrome Web Store Review Process Explained — what reviewers actually check
• Top 8 Reasons Chrome Extensions Get Rejected — avoid the most common rejections
• Chrome Web Store SEO Guide — rank higher after you launch