TL;DR

• Pocket's Chrome extension shut down in 2025, leaving a clear opening for save-to-read tools built on MV3.
• Selection-capture extensions need a content script, a service worker, and a sync layer; MV3 changes how each one works.
• If you're charging for sync or AI summaries, crxpay handles entitlements with 0% platform fee on the first $2,500 in revenue.

How to save web selections to a chrome extension after the pocket shutdown

Mozilla pulled the plug on Pocket in mid-2025. The Chrome extension stopped accepting new saves, and the millions of users who relied on highlight-and-save workflows started shopping for replacements. Some moved to Readwise, some to Matter, some to small indie tools like ChapterPal. Most are still looking.

If you're a Chrome extension developer, this is a real opening. The product is well-understood (highlight a span, click an icon, save it somewhere readable later), the audience is already trained, and there's no dominant successor. This post is the technical playbook: how to build a selection-saving extension on Manifest V3 in 2026, where the gotchas live, and how to charge for it without bleeding 5% to a flat-fee processor.

Why did pocket's chrome extension shut down, and why does it matter?

Pocket launched as Read It Later in 2007 and was the dominant "save for later" extension for over a decade. Mozilla acquired it in 2017, integrated parts of its recommendation engine into Firefox, and announced the full shutdown in May 2025. The Chrome extension was deprecated alongside the apps. According to Mozilla's own numbers, Pocket had around 30 million registered users at peak.

That's a large pool of people whose muscle memory is "highlight, click, save." They lost the underlying service overnight. A handful of replacements emerged, but most are mobile-first or note-app-first. The pure highlight-to-archive workflow, executed cleanly inside Chrome, is genuinely under-served.

There's a parallel here for monetization. Chrome Web Store payments shut down in 2021 (Google's announcement landed in July 2020, full sunset followed). Developers had to wire up their own billing or use a third party. The same dynamic applies now to read-later: when a category leader vanishes, the developers who ship a clean replacement quickly tend to keep the users.

If you're thinking about building one, the rest of this post walks the technical and commercial decisions. For background on the Web Store payments side of that history, see docs.crxpay.io/docs/legacy-cws.

What does a selection-saving chrome extension actually need?

Strip the feature list down and there are four moving pieces:

1. A content script that listens for selection events on the active tab and exposes a save action (context menu, floating button, or keyboard shortcut).
2. A service worker (the MV3 replacement for the background page) that receives the saved payload, normalizes it, and forwards it to your backend.
3. A storage layer. chrome.storage.local for offline buffering, your own API for sync across devices.
4. An entitlements check. Free users get N saves per month, paid users get unlimited plus AI summaries, OCR on PDFs, full-text search, whatever your wedge is.

The first three are well-documented by Google. The fourth is where most indie devs lose weeks. Service workers terminate after 30 seconds of idle, in-memory caches die with them, and a naive "fetch the user's plan on every save" call adds latency to every interaction and breaks the moment the user is offline on a flight.

For the MV3 lifecycle specifics, the canonical reference is Chrome's MV3 migration guide. For how crxpay solves the entitlement-cache problem, jump to the SDK section below or read docs.crxpay.io/docs/chrome.

How crxpay handles entitlements when the service worker dies

The hard part of MV3 isn't the content script. It's the service worker terminating mid-flow and your popup needing to know "is this user still on the Pro plan?" without doing a network round-trip every time.

crxpay's SDK ships an HMAC-signed envelope to chrome.storage.local so the worker (and the popup) can verify entitlement state for 8 hours offline without a network call. Public methods never throw; they return typed Result<T, E> shapes so the popup never crashes from an SDK exception.

import { crxpay } from "@crxpay/sdk";

const client = crxpay.init({ publishableKey: "pk_live_..." });

// In your save handler:
const entitlement = await client.entitlements.check("pro_sync");

if (entitlement.ok && entitlement.value.active) {
  await syncToCloud(selection);
} else {
  await client.paywall.open({ planId: "pro_monthly" });
}

That's the full surface. The check() call hits the signed local cache first and returns in under 5 ms; it only contacts the API when the envelope expires. Full method reference at crxpay.io/features/sdk.

How does the build vs buy math work for the billing layer?

You can absolutely roll your own Stripe integration. A lot of people do, then come back to a third party six months later when refunds, dunning, trial conversions, and proration have eaten their build week.

Here's the comparison table, with numbers from crxpay.io/pricing:

Capability	crxpay	ExtPay	Roll-your-own	CWS payments
Platform fee	0% (first $2.5k), then 2.5%	Flat 5%	0% (your code)	N/A, shut down 2021
MV3 service-worker support	Native, CORS-safe	Partial	You handle CORS	N/A
Offline-first entitlements	HMAC-signed, 8h+ offline	None	Build it	N/A
Hosted paywalls	Yes, brandable	Email-only	Build it	N/A
Stripe Connect Express	Yes, you own the account	Stripe owned by ExtPay	Direct Stripe	N/A
Bayesian A/B testing	Built-in	None	Build it	N/A
Webhooks (signed, replayable)	Yes	None	Build it	N/A

The Stripe Connect Express line matters more than it looks. With crxpay, your Stripe account is yours; payouts go directly to your bank. crxpay takes the platform fee through Stripe's application_fee_percent: 2.5. If crxpay disappeared tomorrow, you'd still have your customers, your subscriptions, and your Stripe data. See docs.crxpay.io/docs/stripe for the connection flow.

For a save-selections extension at, say, $4/month with 1,000 paying users, that's $48,000/year. ExtPay would take $2,400. crxpay takes $1,200 (after the free $2,500 of lifetime revenue is exhausted). The build-it-yourself option is "free" until you count the engineer-weeks.

What features convert free users to paid on a read-later extension?

Looking at what users actually pay for in this category, three wedges keep showing up:

1. Cross-device sync. Anyone using a phone wants their saves on the phone. Free tier: device-local. Paid tier: sync.
2. AI summaries and Q&A. Mid-tier subscribers will pay $5-10/month if your extension can summarize a 4,000-word article in two paragraphs and answer questions against the saved set. Token costs are real, so gate this hard behind the paywall.
3. PDF and image OCR. Pocket never did this well. Researchers and students pay for it.

A reasonable pricing structure: free for 20 saves/month with no sync, $4/month for unlimited saves plus sync, $9/month for AI features. That mirrors what Matter and Readwise charge, and it stays under the psychological $10 threshold where churn spikes.

Run the experiment. crxpay's hosted paywalls (see crxpay.io/features/paywalls) let you ship two paywall variants and split traffic with the built-in Bayesian engine. Most extension devs we've talked to find the conversion rate moves 2-3x between a generic paywall and one tuned to the moment of friction (the 21st save, the first failed sync, the first AI-summary attempt).

How do you migrate users from another save-to-read tool?

If you're targeting Pocket refugees specifically, you need an importer. Pocket's export format was a single HTML file with <a> tags and time_added attributes; that file still works for any user who exported before the shutdown. Build a drop-zone in your options page that parses it and POSTs to your sync API.

For users coming from Matter, Readwise, or Instapaper, each has a JSON or CSV export. A 200-line parser per source covers it.

The harder migration is on the billing side, if you're acquiring a paid user from a competing tool. You don't get to import their card. What you can do is offer a discounted first month on a hosted paywall, tracked as a separate cohort in analytics so you can measure retention against your organic signups. crxpay's webhook system (signed, replayable, queue-backed via Cloudflare Queues) makes this kind of cohort tracking straightforward; details at crxpay.io/features/webhooks.

If you're migrating from ExtPay specifically, there's a one-line shim that keeps existing paid users entitled while you cut over: crxpay.io/migrate-from-extpay.

Frequently asked questions

Q: Is Pocket really gone, or just the extension?

A: The whole service shut down in 2025. Mozilla announced the deprecation in May 2025 and ended new saves shortly after. Existing users were given an export window. The Chrome extension was pulled from the Web Store as part of that wind-down.

Q: Can I just use the Chrome Web Store's payment system?

A: No. Google deprecated Web Store payments in 2020 and fully sunset them in 2021. Every Chrome extension developer collecting subscription revenue today is doing it through their own integration or a third party like crxpay or ExtPay.

Q: What's the smallest viable selection-saving extension?

A: A content script that captures window.getSelection(), a service worker that writes to chrome.storage.local, and an options page that lists saves. That's a weekend build. Sync, paywalls, and AI come after you have users.

Q: How does crxpay handle the MV3 service-worker termination problem?

A: The SDK signs entitlement state with HMAC and stores it in chrome.storage.local. When the worker spins back up, it reads and verifies the envelope locally without a network call. Cached state is valid for 8 hours by default, configurable up to 24.

Q: What does crxpay charge?

A: 0% platform fee on the first $2,500 of lifetime revenue, then 2.5% after. Stripe's standard processing fees (2.9% + $0.30 in the US) apply on top, paid directly to your own connected Stripe account. No monthly minimum, no setup fee.

Q: Can I keep my own Stripe account?

A: Yes. crxpay uses Stripe Connect Express, so you own the merchant relationship. crxpay takes its platform fee through Stripe's application_fee_percent mechanism. Payouts go directly to your bank.

Q: What happens to my saved data if the extension developer shuts down?

A: That's a product decision you should make explicit. Best practice for a read-later tool is to provide an export endpoint that returns the user's full save list as JSON or HTML at any time, and to commit to a 90-day notice window before shutting down sync. Pocket users got that window; not every service will.