Chrome Deletes the Last Manifest V2 Listings From the Web Store on August 31. Here's the 30-Minute Check If Your Side Income Is a Browser Extension.
Google is removing every remaining Manifest V2 extension listing from the Chrome Web Store on August 31, 2026. Most of the coverage of this date treats it as the deadline, full stop, which is wrong and has led a few people I know to panic-check extensions that already migrated over a year ago. The actual runtime cutoff happened back in July 2025. What August 31 does is different, narrower, and still worth twenty minutes of your Sunday if you've got a browser extension generating any revenue.
I run one small utility extension myself (nothing that makes real money, but enough that I went and checked my own manifest version while writing this), and I'd recommend you do the same before reading the rest of this as a hypothetical.
The two dates people keep conflating
No Manifest V2 extension has been able to run on stable Chrome since Chrome 138 shipped in July 2025. That's the hard technical cutoff. If your extension is still V2 today, it hasn't been running for over a year, and you'd already know, because your users would have told you. Google spent the months after that removing the last workarounds too: developer flags that let enterprise and experimental installs keep MV2 alive got pulled in Chrome 150 (June 30, 2026) and Chrome 151 (July 28, 2026).
August 31, 2026 is a different, later step. It's the date Google purges dormant MV2 listings from the Chrome Web Store itself: the storefront, not the browser. An MV2 listing that's been sitting there, unmaintained, since before the 2025 cutoff disappears from search and can no longer be freshly installed by anyone. If a copy is already installed on someone's machine, it may keep functioning locally depending on their Chrome version and flags, but it's gone from the store, gone from search results, and gone from the update pipeline. For a solo-built extension, that's the difference between "technically still exists somewhere" and "actually discoverable and installable by a new customer."
Why this is a real check, not a formality
If you built or maintain an extension and migrated to Manifest V3 any time in the last two years (which is most active, maintained extensions at this point), nothing changes for you on August 31. This section exists for the smaller set of people running something that still works, that they haven't touched recently, and that they've been assuming is fine because nobody's complained.
The way to actually know, rather than assume: open your extension's manifest.json and check the manifest_version field. If it says 3, you're done, close this tab. If it says 2, or if you're not sure where that file lives because someone else built the extension originally, go to the Chrome Web Store Developer Dashboard for your listing. Google has been surfacing manifest-version warnings there for a while now, and if your listing has one, you're the extension this article is actually about.
The part that actually costs you a weekend
The reason MV2-to-MV3 migrations aren't always a quick fix is the service worker change, and it's worth understanding before you assume this is a find-and-replace job. Manifest V2 extensions could run a persistent background page: a script that stays alive in memory indefinitely, holding state, running timers, listening continuously. Manifest V3 replaces that with an event-driven service worker that Chrome can and will kill after roughly 30 seconds of inactivity, waking it back up only when a new event fires.
If your extension does anything that depends on continuous in-memory state (a running counter, a websocket connection you assumed stayed open, a setInterval timer doing periodic work), that logic breaks under MV3's service worker model, and it doesn't break loudly. It breaks by working fine when you test it (because you're actively interacting with it, which keeps the worker alive) and then quietly stopping in production once the worker goes idle. This is the single most common reason a solo dev's "quick MV3 port" turns into a weekend: you have to move persistent state into chrome.storage or a comparable mechanism, and redesign anything time-based around alarms (chrome.alarms) instead of setInterval, because setInterval doesn't survive a worker restart.
What to actually check, in order
Start with the manifest version field: that's your one-minute answer to whether any of this applies to you at all. If you're already on V3, stop there. If you're not, or you're not sure, go check the Developer Dashboard warning next; Google will tell you directly whether your specific listing is flagged for removal. Only after that should you dig into the code itself, and when you do, search your background script for setInterval, setTimeout with long delays, and any variable that's supposed to persist between events: those are the three things most likely to silently break under a service worker.
Budget a weekend if you find real dependencies on persistent state, not because the migration is conceptually hard, but because tracking down every place your extension assumed continuous execution takes longer than the actual code changes once you've found them.
The honest take
For most solo-built extensions, this is a non-event, and I don't want to overstate the urgency for the majority case. If you've touched your extension's codebase at all in the past eighteen months, you're almost certainly already on Manifest V3, and August 31 changes nothing for you. The people this actually matters to are the ones running something they built once, that still generates a little affiliate or subscription revenue, and that they haven't opened in a year or more: the exact profile of a solo operator's forgotten side project.
What I'd actually do
Check the manifest version today, not on August 30. If you're on V3, you're done. If you're not, don't try to guess whether your specific extension depends on persistent background state: grep for setInterval and check your background script directly, because that's the actual failure mode, not some vague "MV3 compatibility" concept. And if you're running an extension you didn't build yourself, or inherited from an earlier version of your own business, this is the week to actually open the codebase and look, rather than assume it's fine because it hasn't broken yet.
Author
Lukas
@lukcombinator