A clean outline in the dust where an object used to stand, now gone

cwspy.com · July 26, 2026 · 9 min read

Chrome Extension Uninstalls: What Happens and Why

Every extension developer watches the same number: how many people are using this thing. It goes up, which is pleasant, and it goes down, which is not — and when it goes down, the store tells you nothing about why. This guide is the map of everything that sits behind that number. What actually happens when someone removes your extension, why the browser gives you almost nothing to work with, the one hook it does give you, and how to turn a departure into a sentence you can act on. Each section links to a deeper guide; read this one first to see how the pieces fit.

Three ways an extension disappears

"My users dropped" covers three very different events, and confusing them will send you chasing the wrong problem. Before anything else, work out which one you are looking at.

What happenedWho decidedDo you hear about it?
The user uninstalled itThe userOnly if you registered an uninstall URL in advance
The user disabled itThe userNo — the extension is still installed, just switched off
The browser or store turned it offGoogle, or an administratorNo — and it is not an uninstall, so no page opens

The third row catches people out badly. When a platform change deactivates a whole class of extensions — as the Manifest V2 shutdown did — your users see a message telling them the extension is no longer supported, your numbers fall, and not one of those people made a decision about your product. The same is true when an administrator removes an extension through enterprise policy: the person using it was never consulted.

So the first question when a graph turns down is not "what did we do wrong" but "did anyone actually choose this". Only real uninstalls carry a reason worth chasing.

What happens when you uninstall a Chrome extension?

Here is the part that surprises most developers: from inside your extension, an uninstall is completely invisible. There is no event. Nothing fires. The browser terminates your service worker, discards your local storage, stops injecting your content scripts, and your extension ID stops resolving. By the time removal is confirmed, your code cannot execute at all.

Chrome does not give you an uninstall event, and no amount of clever code will produce one. The removal is deliberately not something your extension gets to participate in.

That is a security decision, not an oversight — an extension that could run code while being removed could also try to stop it, exfiltrate whatever it still had access to, or reinstall itself. Read through the chrome.runtime API reference and you will find no uninstall event of any kind. The trade-off is that you learn nothing by default.

The one exception is a URL you nominated ahead of time. Register it while your extension is healthy, and when a user removes it the browser opens that page in a new tab. It is the only channel that survives the removal, because it runs on your server rather than in the extension. How to register it correctly — and the Manifest V3 trap that silently disables it — is covered in the complete guide to the uninstall URL.

Can the Chrome Web Store dashboard show uninstalls?

The Chrome Web Store reports a user count, and developers reasonably treat it as their churn signal. It is not one, for three separate reasons.

  • It is a net figure. A week where 300 people installed and 300 left looks identical to a week where nothing happened at all. The churn is invisible underneath the flat line.
  • It is coarse and delayed. The figure shown publicly on a Chrome Web Store listing moves in rounded steps, so small changes hide entirely and the moment a decline starts is hard to pin down.
  • It contains no reasons. This is the fundamental limitation. A count is an outcome. You need a cause, and no aggregate number contains one.

Reviews do not fill the gap either. People who leave a store review are a loud, self-selected minority — usually either delighted or furious — and someone quietly disappointed by a broken feature rarely stops to write one. The middle of your distribution never speaks in public.

The users you lose know things you do not

This is the argument that runs through every article in this series, so it is worth stating plainly here.

Consider the funnel of who tells you about a problem. A user hits a bug. Most shrug and stop using the feature. A smaller group works around it. A smaller group still leaves a one-star review. A tiny, technical minority finds your support address or your issue tracker and files a proper report. And a large share of everyone affected simply removes the extension and moves on without a word.

The failures costing you the most users are, almost by definition, the ones nobody bothered to report.

The specific things that reach you through no other channel are remarkably consistent across extensions: a feature that works everywhere except one popular site, a conflict with another widely installed extension, a regression shipped in last week's release that your own testing missed, a permission prompt that read as alarming to someone without the context you have, a limit nobody knew about until they hit it.

None of that appears in an install graph. All of it appears, in plain language, in answers collected at the moment of departure — which is also the most honest moment you will ever get, because the person has nothing left to lose and no relationship to protect. Read them regularly and the list turns into a queue of fixes; each fix quietly stops the next batch of users from leaving for the same reason. That loop is the whole point.

Uninstall feedback responses listing the reason, extension version, country, and device for each
What a departure looks like when you ask: specific, dated, and tied to a version.

Three answers, three different fixes — an engineering bug, a packaging decision, and a permissions problem. A user-count chart would have shown all three as the same downward tick.

How do you ask departing users why they left?

Having a channel is not the same as getting answers through it. The design that works is aggressively minimal: your extension's name and icon, one question, one optional field, a submit button, nothing else. No account, no email, no rating scale, no second page.

A minimal uninstall feedback page with a single optional question
Every element you add past this costs you answers.

Capture the version they were running alongside the answer — it is the difference between a pile of complaints and a dated regression report. The full design brief, the columns worth keeping, and the mistakes that kill the response rate are in how to build an uninstall feedback page. For what people actually write once you start asking, see why users uninstall Chrome extensions.

Measuring departures honestly

Two cautions before you start putting these numbers in front of anyone.

First, an uninstall page sees a subset of removals. Users who were offline, users removed by administrator policy, users who deleted their whole browser profile — none of them reach your page. It is an excellent source of reasons and a poor census of departures, and presenting it as the latter will get you into trouble internally.

Second, resist averaging it. The sample is self-selected and skewed toward the annoyed. Treat repeated phrasing as a priority queue of defects, not as a satisfaction score. Our guide to reading your uninstall rate covers what can and cannot be inferred, and how to line answers up against your release history.

And because this involves collecting something from people at a sensitive moment, it is worth knowing where the line is. There is a legitimate critique of uninstall tracking, and it lands squarely on implementations that quietly re-identify users as they leave — uninstall tracking without crossing the privacy line walks through what is fair to collect and what is not.

A short plan

  1. Work out whether your decline is uninstalls, disables, or a platform change. Only the first has reasons attached.
  2. Register an uninstall URL, and register it on every service-worker startup — not once on install.
  3. Put a one-question page behind it, with no account and no required fields.
  4. Record the extension version with every answer.
  5. Read the answers regularly. Sort by what repeats, not by what stings.
  6. Fix the repeats, ship, and check whether the sentences stop.
  7. Keep it anonymous, and say in your privacy policy what the page collects.

The rest of the series

Losing users is normal; losing them without learning anything is a choice. One API call and one honest question turn the most opaque event in your product into the clearest feedback you will ever receive. Questions about any of this? Reach out through our contact form or email us at [email protected].