Forem: SHOTA

Building a Cookie Manager Chrome Extension: What I Learned From the MV3 Transition

SHOTA — Fri, 08 May 2026 15:22:08 +0000

Cookie management extensions are one of the oldest categories in the Chrome Web Store. EditThisCookie has been around since 2011 and still has millions of users. The category is established, the use cases are well-understood, and it's a good study in how to migrate a conceptually simple tool to Manifest V3.

I built CookieJar as an EditThisCookie alternative built natively on MV3. Here's what the development revealed.

The `cookies` API in MV3

The Chrome cookies API is straightforward. To get all cookies for the current tab:

async function getCookiesForTab(tabId: number): Promise<chrome.cookies.Cookie[]> {
  const [tab] = await chrome.tabs.query({ active: true, currentWindow: true });
  if (!tab?.url) return [];

  return chrome.cookies.getAll({ url: tab.url });
}

The url parameter scopes the query to cookies accessible to that origin (matching domain and secure flag). Pass {} instead to get all cookies the extension can see.

The MV3 change that matters: In MV2, you could listen to chrome.cookies.onChanged from a persistent background page indefinitely. In MV3, the service worker is terminated after inactivity. Real-time cookie monitoring requires a different approach.

Real-Time Cookie Monitoring Without a Persistent Background

If a user has the extension open and is modifying cookies on the page, I want the UI to update. But chrome.cookies.onChanged is only active while the service worker is running.

The solution: keep a port connection alive between the popup and the service worker. A port connection keeps the service worker active as long as the port is open:

// In popup
const port = chrome.runtime.connect({ name: 'cookie-monitor' });

port.onMessage.addListener((msg) => {
  if (msg.type === 'COOKIE_CHANGED') {
    // Update UI
    refreshCookies();
  }
});

// Cleanup when popup closes
window.addEventListener('unload', () => port.disconnect());

// In service worker
chrome.runtime.onConnect.addListener((port) => {
  if (port.name !== 'cookie-monitor') return;

  const listener = (changeInfo: chrome.cookies.CookieChangeInfo) => {
    port.postMessage({ type: 'COOKIE_CHANGED', cookie: changeInfo.cookie });
  };

  chrome.cookies.onChanged.addListener(listener);

  port.onDisconnect.addListener(() => {
    chrome.cookies.onChanged.removeListener(listener);
  });
});

The port keeps the service worker alive while the popup is open. When the popup closes, the port disconnects, and the listener is removed cleanly.

Cookie Editing: The Session/Persistent Distinction

There are two cookie types users care about: session cookies (no explicit expiry, deleted when browser closes) and persistent cookies (explicit Max-Age or Expires attribute).

The chrome.cookies.set() API mirrors the HTTP Set-Cookie header:

async function updateCookie(
  original: chrome.cookies.Cookie,
  updates: Partial<CookieEditFields>
): Promise<chrome.cookies.Cookie | null> {
  const url = buildCookieUrl(original);

  const details: chrome.cookies.SetDetails = {
    url,
    name: updates.name ?? original.name,
    value: updates.value ?? original.value,
    domain: updates.domain ?? original.domain,
    path: updates.path ?? original.path,
    secure: updates.secure ?? original.secure,
    httpOnly: updates.httpOnly ?? original.httpOnly,
    sameSite: updates.sameSite ?? original.sameSite,
  };

  // Handle session vs persistent
  if (updates.expirationDate !== undefined) {
    if (updates.expirationDate === null) {
      // Make it a session cookie (no expirationDate in details)
    } else {
      details.expirationDate = updates.expirationDate;
    }
  } else if (original.session) {
    // Preserve session nature — don't add expirationDate
  } else {
    details.expirationDate = original.expirationDate;
  }

  return chrome.cookies.set(details);
}

function buildCookieUrl(cookie: chrome.cookies.Cookie): string {
  const scheme = cookie.secure ? 'https' : 'http';
  const domain = cookie.domain.startsWith('.') ? cookie.domain.slice(1) : cookie.domain;
  return `${scheme}://${domain}${cookie.path}`;
}

The domain handling is subtle: Chrome stores domain cookies with a leading . (indicating host-only = false), but cookies.set() wants the domain without the leading . when building the URL. Forgetting this causes silent failures where the set operation appears to succeed but the cookie isn't updated.

The `httpOnly` Problem

httpOnly cookies cannot be set directly via JavaScript — that's the whole point. But the chrome.cookies API can read and set them because it bypasses the JavaScript restriction. This is one of the key reasons developers need a cookie manager extension rather than just using DevTools.

When editing an httpOnly cookie, CookieJar preserves the flag:

// When displaying httpOnly cookies
{cookie.httpOnly && (
  <Badge variant="secondary" title="Cannot be accessed by JavaScript">
    httpOnly
  </Badge>
)}

The badge both informs the user and serves as a reminder that this cookie is protected from XSS-based theft.

Search and Filter

With 50+ cookies on a complex page, the list gets unwieldy. I added filtering that handles the common patterns:

function filterCookies(
  cookies: chrome.cookies.Cookie[],
  query: string
): chrome.cookies.Cookie[] {
  const q = query.toLowerCase().trim();
  if (!q) return cookies;

  return cookies.filter((c) => {
    return (
      c.name.toLowerCase().includes(q) ||
      c.value.toLowerCase().includes(q) ||
      c.domain.toLowerCase().includes(q)
    );
  });
}

I also added quick filters for common categories: session-only, httpOnly, secure, and by domain — the most common use cases I observed when I interviewed developers about their cookie management workflow.

Import/Export

CookieJar supports exporting the current page's cookies as JSON and re-importing them. This is useful for sharing a session state, preserving cookies before clearing storage, or transferring a session between environments.

The export format is the Chrome cookies.Cookie type directly — no transformation needed. The import uses chrome.cookies.set() for each cookie, with error handling for cookies that can't be set (e.g., cookies for a domain you're not currently on):

async function importCookies(
  cookies: chrome.cookies.Cookie[]
): Promise<{ success: number; failed: number }> {
  let success = 0;
  let failed = 0;

  for (const cookie of cookies) {
    try {
      await updateCookie(cookie, {});
      success++;
    } catch {
      failed++;
    }
  }

  return { success, failed };
}

The MV3 Lesson

Cookie managers are a good test case for MV3 constraints because they need real-time DOM observation and background API access. The port-based keep-alive pattern for the service worker solves the real-time monitoring problem, but it's not an obvious solution and isn't documented prominently by Google.

The key constraint: anything that needs to be "always on" has to be driven by an open UI (popup, side panel, or new tab page). If your background monitoring logic is important even when no UI is open, you need to rethink the architecture for MV3 — the service worker model simply doesn't support persistent background processes.

CookieJar is on the Chrome Web Store.

Built with Vite + React + TypeScript. Uses chrome.cookies, chrome.tabs, and port-based service worker keep-alive.

Building a Cookie Editor Chrome Extension — Why I Built CookieJar After EditThisCookie Died

SHOTA — Fri, 08 May 2026 00:00:00 +0000

EditThisCookie Is Gone — Now What?

In late 2024, EditThisCookie — the most popular cookie editor for Chrome with millions of users — was removed from the Chrome Web Store. The reason: it never migrated to Manifest V3.

Overnight, millions of developers and testers lost their go-to cookie management tool. I saw an opportunity and built CookieJar — a modern, MV3-native cookie editor with features EditThisCookie never had.

What CookieJar Does Differently

1. Automatic Cookie Classification

EditThisCookie showed you a flat list of cookies. CookieJar automatically classifies every cookie into 6 categories:

Essential — Session tokens, CSRF tokens, auth cookies
Functional — Language preferences, UI settings
Analytics — Google Analytics, Mixpanel, Hotjar trackers
Advertising — Facebook Pixel, Google Ads, retargeting cookies
Social — Social media widgets, share buttons
Unknown — Unclassified cookies

Classification uses a combination of:

Pattern matching on cookie names (e.g., _ga → Analytics)
Domain matching against the Disconnect.me tracking list
Heuristic analysis of cookie attributes (HttpOnly, SameSite, expiry)

2. Privacy Score

Every site gets a 0-100 privacy score displayed as a circular gauge in the popup header. The score factors in:

Number and type of tracking cookies
Presence of third-party cookies
Cookie security attributes (Secure, HttpOnly, SameSite)
Total cookie count relative to category average

A developer can instantly see whether a site's cookie practices are reasonable.

3. Profile Management

Save and restore cookie sets as profiles:

Testing multi-role authentication? Save "Admin" and "User" profiles
Switching between staging and production? One click
Debugging OAuth flows? Save pre-auth and post-auth states

4. Export Formats

CookieJar exports cookies in 5 formats:

JSON (for programmatic use)
Netscape/curl format (for cURL commands)
HTTP Header format (for direct API testing)
Puppeteer format (for automation scripts)
CookieJar format (for import into another CookieJar instance)

Technical Architecture

MV3 Cookie Access

In MV3, cookie access requires the cookies permission and proper host permissions:

{
  "permissions": ["cookies", "storage"],
  "host_permissions": ["<all_urls>"]
}

The chrome.cookies API provides methods for reading, setting, and removing cookies. CookieJar wraps these in a type-safe abstraction layer.

Real-Time Updates

CookieJar uses chrome.cookies.onChanged to show real-time cookie updates without polling. When a site sets, modifies, or deletes a cookie, the popup updates instantly.

Performance

With sites sometimes having 50+ cookies, rendering performance matters. CookieJar uses:

Virtual scrolling for large cookie lists
Debounced search filtering
Lazy classification (classify on first view, cache results)

8-Language Localization

CookieJar ships with full localization in:
English, Japanese, Chinese (Simplified), Korean, Spanish, French, German, Portuguese

All UI text goes through a localization system — no hardcoded strings.

Privacy Commitment

CookieJar itself collects zero data. No analytics, no tracking, no server communication. All cookie data stays in your browser. The irony of a cookie management tool that tracks you would not be lost on developers.

Installation

CookieJar is free and available on the Chrome Web Store.

Pro features (profile management, bulk operations, export) are available for $4.99/month.

Built by S-Hub — Chrome extensions for developers and productivity enthusiasts.

More Developer Tools from S-Hub

OnPageX — SEO meta analysis for any page
DataPick — Extract data from any webpage
Procshot — Auto-capture browser steps into guides
DataBridge — Transfer data between web apps

See all extensions at dev-tools-hub.xyz

Real Numbers: Freemium Chrome Extension Monetization After 6 Months

SHOTA — Wed, 06 May 2026 16:03:03 +0000

I've been publishing Chrome extensions for about a year. Six months ago I started adding freemium monetization to my extensions using ExtensionPay. Here are the actual numbers and what I've learned.

I'm sharing this because almost no one publishes real conversion data for Chrome extension monetization. The advice is almost always theoretical. Here's what I've observed across 5 monetized extensions.

The Portfolio

Five extensions with ExtensionPay freemium:

Extension	Category	Price	Free Limit	Installs
Procshot	Productivity	$4.99/mo	2 guides/month	~900
Japanese Font Finder	Dev Tools	$2.99/mo	30 inspections/day	~1,200
PaletteGrab	Dev Tools	$3.99 one-time	10 colors in tray	~600
AdLegalCheck	Productivity	$9.99/mo	3 scans/month	~150
ToritekiCheck	Productivity	$4.99/mo	3 analyses/month	~80

Installs are approximate active users from CWS Insights. Monthly active users are lower.

Conversion Rates

Across all five extensions, my overall free-to-paid conversion rate is 0.8%.

That sounds low. For SaaS, 2-5% free-to-paid is considered decent. For Chrome extensions, I've come to believe 0.5-2% is realistic.

Why so low?

Zero friction to install and use the free tier. There's no sign-up, no credit card, no friction at all. The baseline installed count includes a lot of casual installs that never became engaged users.
The upgrade decision happens at an inconvenient moment. Users hit the free limit while they're trying to do something. The friction of the upgrade prompt competes with the task they were trying to complete.
Trust gap. Chrome extension payments are unusual. ExtensionPay shows a payment page that says "extensionpay.com" — which many users don't recognize. Some users who would pay for a web app won't pay for an extension.

The Limit Design Matters More Than the Price

My highest-converting extension is Japanese Font Finder at about 1.4% conversion. The free limit is 30 inspections per day, which sounds generous but is calibrated to the power user's usage pattern.

A designer who uses JFF seriously will hit 30 inspections in a work session. The limit creates just enough friction for real users without frustrating casual users.

My lowest-converting extension (by rate) is PaletteGrab at 0.3%. The free limit is 10 colors in the color tray. This turns out to be fine for most use cases — you can pick and copy colors without saving them. The upgrade prompt appears too rarely.

What I've learned: The free limit should be just below the threshold for your power user's typical session. Too generous = no upgrade pressure. Too tight = users abandon before getting value.

The Upgrade Prompt Matters

My initial upgrade prompts were modal alerts: "You've reached your limit. Upgrade to Pro?"

Conversion from prompt to upgrade: 2%.

I rewrote them to show what the user would get: "You've made 2 guides this month. Pro users get unlimited guides + PDF export + annotation tools." Then two buttons: "Upgrade to Pro ($4.99/month)" and "Maybe later."

Conversion from prompt to upgrade: 8%.

The difference is showing value rather than showing a wall. Users need to remember why they'd pay before they decide to.

ExtensionPay Observations

ExtensionPay is the only practical solution for Chrome extension payments that I've found. It handles the Stripe integration, the payment UI, and the license verification API.

A few things I've noticed:

The payment flow is not optimized for conversion. The user leaves the extension, opens a new tab, sees "extensionpay.com", enters their email, then pays. Each step is a drop-off point. I estimate 30-40% of users who click "Upgrade" complete the payment.

Monthly vs. one-time matters by category. Productivity tools (recurring use) convert better to monthly subscriptions. Utility tools (occasional use) convert better to one-time payments. PaletteGrab switched from $2.99/month to $3.99 one-time and conversion improved 60%.

Free users complain; paid users don't. My CWS reviews are overwhelmingly from free users frustrated by limits. Paid users tend to leave positive reviews or no review at all. This is expected but worth knowing.

The Revenue Reality

My current monthly recurring revenue across all five extensions is approximately $180/month. That's well below what I'd need to make this a business, but it's meaningful signal.

The trajectory matters more: three months ago it was $60/month. Six months ago it was $0.

The install base is growing (mostly through CWS organic search), and conversion rates have improved as I've refined the upgrade prompts and limit designs. At current growth rates, I expect to cross $400/month within 6 months.

What I'd Do Differently

Ship freemium from day one. Extensions I launched without monetization have free users who feel entitled to free forever. Adding a paywall retroactively generates negative reviews. New extensions now launch with the freemium model from the first public version.

One-time pricing for tools, subscription for productivity. The recurring revenue math is better for subscriptions, but one-time pricing converts better for tools users reach for occasionally. Match the pricing model to the usage pattern.

The free limit should be lower for higher-priced plans. My $9.99/month AdLegalCheck has a free limit of 3 scans/month. That's appropriate for a $10 product. My $2.99/month JFF has a limit of 30/day — much more generous, appropriate for a $3 product. The limit signals the value relative to the price.

I track my Chrome extension revenue and growth at dev-tools-hub.xyz.

Monetizing Chrome Extensions with Freemium — Real Numbers from 7 Paid Extensions

SHOTA — Wed, 06 May 2026 00:00:00 +0000

Can You Actually Make Money with Chrome Extensions?

Yes. But the numbers are smaller than you think, and the strategy matters more than the code.

I run 7 freemium Chrome extensions through ExtensionPay + Stripe. Here's the real data — no vanity metrics, no cherry-picking.

The Portfolio

Extension	Category	Free Tier	Pro Price
Procshot	Productivity	5 captures/mo	$9.99/mo
DataPick	Data tools	10-row preview	$19/mo
PromptStash	AI tools	3 saved prompts	$5/mo
ReadMark	Reading	5 bookmarks	$4.99/mo
InvoiceReader	Business	10 checks/mo	980 JPY/mo
CookieJar	Dev tools	Basic features	$4.99/mo
FocusGuard	Productivity	Basic blocking	$5/mo

The Freemium Model

Why Freemium Over Paid-Only?

Chrome Web Store doesn't have a built-in payment system. Users can't buy your extension before installing it. This means:

User installs (free)
User tries the extension
User hits a limitation
User decides to pay

Freemium is the only model that works naturally with CWS's install flow.

The Reverse Trial Approach

Instead of a traditional free trial, I use a reverse trial: users get Pro features for 7 days immediately after install, then drop to the free tier.

Why this works:

Users experience the full product before deciding
No credit card required upfront
The "loss" of features is more motivating than never having them
Conversion happens when users feel the pain of downgrade

Setting Free Tier Limits

The hardest part of freemium is setting the right limit. Too generous and nobody pays. Too restrictive and users uninstall.

My framework:

The free tier must be genuinely useful (not a crippled demo)
The limit should be hit after the user has gotten value (not before)
Pro features should be visible but locked (grey out, don't hide)

Example — Procshot:

Free: 5 procedure captures per month
Pro: Unlimited captures + markdown/HTML/PDF export
The limit hits after the user has already created valuable documentation
Export formats are visible but locked with a Pro badge

Payment Infrastructure

ExtensionPay + Stripe

I use ExtensionPay which wraps Stripe for Chrome extension payments. The setup:

Register extension on ExtensionPay
Add ExtPay SDK to your extension
ExtPay handles the payment page, Stripe processes payments
Your extension checks payment status via ExtPay API

Cost: ExtensionPay takes a flat fee per transaction on top of Stripe's standard 2.9% + 30 cents.

Subscription Management in MV3

The tricky part is checking subscription status in a Manifest V3 service worker that can be terminated at any time:

Background service worker holds the ExtPay instance
On payment/trial events, cache the subscription in chrome.storage.local
Content scripts and popups query the background via chrome.runtime.sendMessage
If background is sleeping, fall back to cached data (5-minute TTL)
Periodic refresh via chrome.alarms (every 60 minutes)

This ensures paid users never get locked out, even if the network or service worker is temporarily unavailable.

What I've Learned

Pricing Insights

$3-5/mo is the sweet spot for utility extensions. Higher prices work only for niche professional tools.
Annual plans convert at 2x monthly when offered at a 40-50% discount
JPY pricing for Japanese users increases conversion significantly (InvoiceReader: 980 JPY vs $9.99 equivalent)

Conversion Patterns

Average free-to-paid conversion: 2-4% across all extensions
Reverse trial increases conversion by ~60% compared to no trial
Users who hit the free limit within 7 days are 5x more likely to convert
The paywall modal shown at the moment of limitation (not randomly) converts 3x better

What Doesn't Work

Aggressive upsell popups (users uninstall)
Hiding features completely (users don't know what they're missing)
Time-limited free trials without reverse trial (users forget to convert)
Pricing above $10/mo for general-purpose tools

Revenue Growth Strategy

My 90-day plan to reach $650/month:

Month 1: Optimize free tier limits + implement reverse trial on all 7 extensions
Month 2: Add annual pricing + improve paywall design + cross-promotion
Month 3: Content marketing (Dev.to, Zenn) + Product Hunt launch for top extension

The key insight: revenue growth comes from reducing friction in the conversion funnel, not from adding more features.

Key Takeaways

Freemium is the only viable model for CWS
Reverse trials outperform traditional trials
Set free limits at the point of value, not before
Cache subscription state aggressively for MV3 resilience
Price at $3-5/mo for utility extensions
Show Pro features locked, never hidden

Built by S-Hub — 17 Chrome extensions, 7 with freemium monetization.

Explore S-Hub Extensions

Procshot — Auto-capture browser steps
DataPick — Extract data from any webpage
PromptStash — Save and manage AI prompts
ReadMark — Save your reading position

See all extensions at dev-tools-hub.xyz

I Built a Chrome Extension That Checks Japanese Subscription Terms with AI

SHOTA — Tue, 05 May 2026 16:00:45 +0000

Japanese subscription services have a problem with terms and conditions.

Not the length — that's universal. The specific issue is that Japanese cancellation terms, automatic renewal clauses, and price change notifications are buried in dense legal Japanese that's difficult to parse even for native speakers. The phrasing is designed to be compliant, not readable.

I've been surprised by charges I didn't expect. A streaming service I thought I'd cancelled. A software license that auto-renewed at double the introductory price. A free trial that converted to a paid plan because the cancellation window was "within 3 days of the trial end date" buried in paragraph 12 of the terms.

ToritekiCheck (取適チェック) is a Chrome extension that analyzes subscription terms and conditions pages with GPT and summarizes the important parts in plain Japanese.

What It Analyzes

When you're on a service's terms page or subscription confirmation page, the extension scans for:

自動更新条件 (Auto-renewal conditions): When does it renew, what triggers it, how far in advance can you cancel?
解約方法・期限 (Cancellation method and deadline): How do you cancel, what's the deadline?
価格変更通知 (Price change notification): How will you be told if the price changes?
無料期間の終了 (Free trial end): Exactly when does the trial end and what happens after?
返金ポリシー (Refund policy): Under what conditions can you get a refund?

The output is a structured summary in plain Japanese, not the original legalese.

Architecture

The extension uses a side panel (Chrome's sidePanel API) rather than a popup, which gives enough vertical space to display detailed findings without feeling cramped.

ToritekiCheck/
├── entrypoints/
│   ├── content.ts          # Page text extraction
│   ├── sidepanel/          # React UI for results
│   └── background.ts       # API calls, message routing
└── lib/
    ├── extractor.ts        # Terms text extraction heuristics
    ├── analyzer.ts         # GPT call via Vercel proxy
    └── storage.ts          # Usage count, settings

Extracting Terms Text

Not every page that has "terms" in the URL is a terms page in the relevant sense. I need to find the actual terms content while ignoring navigation, footers, and cookie banners.

function extractTermsText(doc: Document): string {
  // Common terms container patterns in Japanese sites
  const selectors = [
    'article',
    '[class*="terms"]',
    '[class*="kiyaku"]',    // 規約 in romaji
    '[class*="agreement"]',
    '[id*="terms"]',
    '[id*="policy"]',
    'main',
  ];

  for (const selector of selectors) {
    const el = doc.querySelector(selector);
    if (el && el.textContent && el.textContent.trim().length > 500) {
      return cleanText(el.textContent);
    }
  }

  // Fallback: body text minus nav/header/footer
  return extractBodyContent(doc);
}

function cleanText(text: string): string {
  return text
    .replace(/\s+/g, ' ')
    .replace(/[\u200B-\u200D\uFEFF]/g, '') // Zero-width characters
    .trim()
    .slice(0, 8000); // GPT context limit
}

The 8000-character limit cuts most terms documents significantly, but the auto-renewal and cancellation clauses usually appear in the first third of any terms document (near the subscription-specific sections).

The GPT Analysis Prompt

const ANALYSIS_PROMPT = `
あなたは日本のサブスクリプションサービスの規約分析の専門家です。
以下の利用規約・特定商取引法に基づく表示から、ユーザーが特に注意すべき項目を抽出してください。

【抽出する項目】
1. 自動更新条件（更新タイミング、事前通知の有無）
2. 解約方法と解約期限（どのように、いつまでに解約が必要か）
3. 無料期間の終了条件（いつ有料に切り替わるか）
4. 価格変更の通知方法
5. 返金ポリシー

【出力形式】JSON
{
  "autoRenewal": { "exists": boolean, "conditions": string, "riskLevel": "high"|"medium"|"low" },
  "cancellation": { "method": string, "deadline": string, "riskLevel": "high"|"medium"|"low" },
  "freeTrial": { "endCondition": string, "conversionDate": string | null },
  "priceChange": { "notificationMethod": string },
  "refundPolicy": { "available": boolean, "conditions": string },
  "summary": "最も重要な点を1-2文で要約"
}

見つからない項目は null にしてください。
`;

The structured JSON output makes it easy to render each section with appropriate risk indicators in the UI.

Free Tier Limits

The extension has a free tier (3 analyses per month) and a Pro tier (unlimited). Usage is tracked per calendar month:

async function checkAndIncrementUsage(): Promise<{ allowed: boolean; remaining: number }> {
  const now = new Date();
  const monthKey = `${now.getFullYear()}-${String(now.getMonth() + 1).padStart(2, '0')}`;

  const data = await chrome.storage.local.get(['usage', 'isPro']);
  if (data.isPro) return { allowed: true, remaining: Infinity };

  const usage = data.usage ?? {};
  const currentMonthCount = usage[monthKey] ?? 0;

  if (currentMonthCount >= FREE_LIMITS.MONTHLY_ANALYSES) {
    return { allowed: false, remaining: 0 };
  }

  // Increment
  await chrome.storage.local.set({
    usage: { ...usage, [monthKey]: currentMonthCount + 1 },
  });

  return {
    allowed: true,
    remaining: FREE_LIMITS.MONTHLY_ANALYSES - currentMonthCount - 1,
  };
}

Month-key storage means usage resets automatically without any cleanup job — old month keys accumulate but are tiny. A periodic cleanup job removes keys older than 3 months.

The Proxy Requirement

Like my other AI-powered extensions, ToritekiCheck routes GPT calls through a Vercel serverless function. The API key lives server-side. The extension sends only the extracted terms text.

The data handling is important to be transparent about: the terms text (up to 8000 characters from a public terms page) is sent to the proxy, then to OpenAI for analysis. The text is not stored. This is disclosed in the CWS privacy settings and the in-extension UI.

What I Learned About Freemium for Utility Extensions

The 3-analysis-per-month limit is intentionally generous for casual users. Most people check subscription terms 1-2 times a month at most. The Pro tier is for people who review contracts professionally or have a high volume of subscriptions to manage.

This is different from productivity tools where the free limit needs to be tight enough to create upgrade pressure. For an occasional-use utility, being too restrictive hurts word-of-mouth without gaining proportional upgrades.

ToritekiCheck is live on the Chrome Web Store.

Built with WXT + React + TypeScript. AI analysis via GPT-4o-mini through a Vercel proxy.

I Built a Chrome Extension That Auto-Fills Any Form — Encrypted, No Cloud

SHOTA — Tue, 05 May 2026 15:59:09 +0000

I run a few side projects. The paperwork reality of running side projects is filling in the same company name, address, phone number, and tax ID into web forms, over and over, on vendor portals, invoice tools, e-commerce seller dashboards, and government registration pages.

My password manager handles login credentials. It doesn't handle business info particularly well. So I built FormFill Vault.

The problem is more specific than it sounds

Password managers are great at what they do. But "what they do" is structured around credentials: username, password, maybe a TOTP. When you hit an invoice form that wants your company legal name, postal code (Japanese 7-digit format), city/ward, building, floor, room number, fax, and tax registration number — in separate fields — the auto-fill either ignores most of it or fills random fields incorrectly.

The other option is a browser profile. Browsers let you save your address. One address. In one format. That doesn't cover the seller who has three business registrations.

FormFill Vault's model is simple: you create named profiles (Personal, Work, Side Project A), fill them in once, and click a button to fill whatever form is in front of you. The extension matches fields heuristically, fires the right events for React/Vue apps, and moves on.

The technical part I found interesting: storing encrypted data in chrome.storage.local

The obvious implementation is: save profiles as JSON in chrome.storage.local. But profiles contain business addresses and potentially invoice numbers. Storing them in plaintext felt wrong.

So I added AES-256-GCM encryption via the Web Crypto API. The implementation itself is straightforward:

const key = await crypto.subtle.generateKey(
  { name: 'AES-GCM', length: 256 },
  true,
  ['encrypt', 'decrypt']
);
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, encoded);

The part that tripped me up: persisting the key.

chrome.storage.local uses JSON serialization internally. An ArrayBuffer — which is what crypto.subtle.exportKey('raw', key) returns — serializes to {}. You store it, you read back an empty object, your key is gone, and all your encrypted profiles are permanently unreadable.

The fix is one line, but it's the kind of thing you only know if you've already lost data to it:

// Broken: ArrayBuffer becomes {} in JSON
await chrome.storage.local.set({ key: exportedKeyBuffer });

// Working: serialize to plain number array before storing
await chrome.storage.local.set({
  key: Array.from(new Uint8Array(exportedKeyBuffer))
});

// On retrieval:
const keyBuffer = new Uint8Array(storedArray).buffer;
const key = await crypto.subtle.importKey('raw', keyBuffer, { name: 'AES-GCM' }, false, ['encrypt', 'decrypt']);

The key lives in chrome.storage.local as a plain number array. On every read, it's reconstructed into a CryptoKey. The IV is prepended to the ciphertext and stored as Base64. The key never leaves the browser.

The form filling part: matching fields without a schema

The harder problem is that forms don't have a standard schema. Every vendor portal has different field names. Some use last_name, some use familyName, some use surname, some use Japanese 姓.

I built a heuristic matcher that checks, in order:

The field's name and id attributes
The placeholder and aria-label text
The autocomplete attribute
The associated <label for="..."> text if the field has an id

Each field type in the profile has a regex pattern. The address fields include Japanese kanji and katakana patterns. It's not perfect — edge cases in deeply custom enterprise portals exist — but it handles the common 80% of business forms without configuration.

One more thing: injecting values into React or Vue forms. You can't just element.value = 'new value' and dispatch a standard event. Those frameworks intercept the native input value setter. The fix is to use Object.getOwnPropertyDescriptor to get the original setter and call it directly, then dispatch both input and change:

const nativeInputValueSetter = Object.getOwnPropertyDescriptor(
  HTMLInputElement.prototype,
  'value'
)?.set;
nativeInputValueSetter?.call(element, value);
element.dispatchEvent(new Event('input', { bubbles: true }));
element.dispatchEvent(new Event('change', { bubbles: true }));

This is the standard workaround for triggering React state updates from external scripts.

What the extension actually is

FormFill Vault stores up to 3 profiles on the free plan. Pro removes the limit. All encryption, autofill, and the postal code lookup (a local static dictionary — no API calls) run locally. No network requests for profile operations.

It's available on the Chrome Web Store: [FormFill Vault — link coming soon]

If you do any amount of paperwork involving the same business data across multiple sites, it's the kind of tool you don't notice until you don't have it.

I'm also building Procshot (browser workflow documentation) and other small dev tools at dev-tools-hub.xyz. These posts are technical notes from building them.

I Built an AI-Powered Japanese Trade Law Compliance Checker as a Chrome Extension

SHOTA — Tue, 05 May 2026 09:00:00 +0000

Japan's Subcontracting Act (Toriteki-ho / 取引適正化促進法, commonly called 下請法) governs transactions between large businesses and their subcontractors. It mandates specific payment terms, required contract clauses, and prohibits certain business practices — and violations carry significant penalties from the Fair Trade Commission.

The problem: compliance checking is tedious. Most small businesses and freelancers either don't know the rules or spend time manually cross-referencing contract documents against the law's requirements. I built ToritekiCheck, an AI-powered Chrome extension that analyzes contract text and flags potential violations in seconds.

What the Law Actually Requires

The Subcontracting Act applies to transactions where a larger company subcontracts to a smaller company (thresholds based on capital: manufacturing >=30M yen, services >=50M yen). When it applies, the ordering company must:

Issue a written order (発注書) with specific required fields
Pay within 60 days of receiving the goods/service
Not require promissory note payment (手形払い) in many cases
Not unilaterally reduce prices after work is complete
Not return deliverables without cause

The extension checks for these conditions — specifically scanning for payment term violations and missing required clauses that are most commonly flagged in FTC investigations.

Architecture: Extension + Vercel API Proxy

The core analysis is done by an LLM. Rather than requiring users to provide their own API key, the extension routes requests through a Vercel serverless function:

Chrome Extension -> POST /api/llm/chat (Vercel) -> Claude API -> Response

The Vercel function holds the API key server-side:

// /api/llm/chat/route.ts
export async function POST(request: Request) {
  const { messages, system } = await request.json();

  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY!,
      'anthropic-version': '2023-06-01',
      'content-type': 'application/json',
    },
    body: JSON.stringify({
      model: 'claude-haiku-4-5-20251001',
      max_tokens: 1024,
      system,
      messages,
    }),
  });

  return Response.json(await response.json());
}

Using claude-haiku-4-5-20251001 keeps latency low and cost manageable for free-tier users.

Extracting Contract Text from the DOM

Contract documents come in several formats: PDF viewers, HTML pages, Google Docs embeds, and plain text areas. The extension uses a priority-ordered extraction strategy:

function extractContractText(): string {
  // Priority 1: User-selected text
  const selection = window.getSelection()?.toString().trim();
  if (selection && selection.length > 50) return selection;

  // Priority 2: Active textarea / contenteditable
  const activeEl = document.activeElement;
  if (activeEl instanceof HTMLTextAreaElement) return activeEl.value;
  if (activeEl?.getAttribute('contenteditable') === 'true') {
    return activeEl.textContent || '';
  }

  // Priority 3: Main content heuristic
  const candidates = [
    document.querySelector('article'),
    document.querySelector('main'),
    document.querySelector('[role="main"]'),
    document.querySelector('.contract'),
    document.body,
  ].filter(Boolean) as Element[];

  for (const el of candidates) {
    const text = el.textContent?.trim() || '';
    if (text.length > 200) return text.slice(0, 8000);
  }

  return '';
}

The 8000-character limit prevents hitting the LLM's context window and keeps costs predictable.

The Analysis Prompt

The system prompt is the heart of the product. After several iterations with real contract samples, I settled on structured JSON output with severity levels:

const SYSTEM_PROMPT = `You are a Japanese Subcontracting Act compliance expert.

Analyze the provided contract text and identify potential violations or missing required elements.

Output a JSON object with this structure:
{
  "applicable": boolean,
  "violations": [
    {
      "type": string,
      "severity": "high" | "medium" | "low",
      "description": string,
      "relevant_text": string,
      "legal_basis": string
    }
  ],
  "required_clauses_present": {
    "transaction_type": boolean,
    "delivery_date": boolean,
    "inspection_date": boolean,
    "payment_method": boolean,
    "payment_date": boolean,
    "price": boolean
  },
  "summary": string
}

Focus on:
1. Payment terms exceeding 60 days after receipt
2. Promissory note payment requirements
3. Missing mandatory order form fields (Article 3)
4. Price reduction clauses that may violate Article 4
5. Return conditions that may violate Article 4`;

Rendering Results

The popup receives the JSON and renders a color-coded compliance report:

function renderResults(analysis: AnalysisResult): void {
  const container = document.getElementById('results')!;

  if (!analysis.applicable) {
    container.innerHTML = `<div class="notice">この契約書には下請法が適用されない可能性があります。</div>`;
    return;
  }

  const highCount = analysis.violations.filter(v => v.severity === 'high').length;
  const statusClass = highCount > 0 ? 'danger' :
    analysis.violations.length > 0 ? 'warning' : 'safe';

  container.innerHTML = `
    <div class="status ${statusClass}">
      ${highCount > 0 ? `Warning: ${highCount} critical issues` :
        analysis.violations.length > 0 ? `Note: ${analysis.violations.length} issues` :
        'No issues detected'}
    </div>
    ${analysis.violations.map(v => `
      <div class="violation severity-${v.severity}">
        <p>${v.description}</p>
        <code>${v.relevant_text}</code>
        <small>${v.legal_basis}</small>
      </div>
    `).join('')}
    <div class="summary">${analysis.summary}</div>`;
}

Handling Japanese Legal Text

Japanese legal documents have conventions that don't map cleanly to standard NLP:

Formal grammar patterns (〜するものとする, 〜する旨) differ significantly from everyday text
Counter-intuitive negations: 「支払わないものとする」 looks structurally similar to 「支払うものとする」
Payment terms might be expressed as 「60日以内」, 「２ヶ月」, or embedded in prose

The LLM handles most of these naturally, but I add explicit guidance in the prompt to flag ambiguous payment clauses for human review rather than treating them as definitive violations.

Try ToritekiCheck

ToritekiCheck is free for basic compliance scanning. The Pro plan adds detailed clause-by-clause analysis, scan history, and PDF report export.

View on Chrome Web Store

If you work with Japanese business contracts and want to share feedback on analysis accuracy, leave a comment below.

Other tools I've built:

View on Chrome Web Store
View on Chrome Web Store

Manifest V3 Migration: The Gotchas Nobody Warned Me About

SHOTA — Mon, 04 May 2026 16:04:09 +0000

When Google announced the Manifest V3 deadline, the developer community had a lot to say — most of it negative. The service worker model was rightly criticized as a regression for ad blockers and complex extensions.

I've now migrated 18 extensions from MV2 to MV3, or built them MV3-native from the start. The commonly documented issues (no persistent background pages, limited webRequest) are real. But there's a longer list of subtler problems I hit that weren't well-documented.

Here's what actually caught me off guard.

1. Service Workers Die at Inopportune Times

This is the most-discussed MV3 change, but the extent of it surprised me. The service worker doesn't just "stop when idle" — it can be terminated after as little as 30 seconds of inactivity, even mid-operation.

The failure mode is subtle: a message from a content script reaches the service worker just as it's being terminated. The message is lost. The content script gets no response. No error, no log, just silence.

The fix: Always assume the service worker might not be running. Content scripts should retry with exponential backoff:

async function sendToBackground<T>(
  message: unknown,
  maxRetries = 3
): Promise<T> {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await chrome.runtime.sendMessage(message);
    } catch (err) {
      if (attempt === maxRetries - 1) throw err;
      // Brief delay — gives the service worker time to restart
      await new Promise(res => setTimeout(res, 100 * Math.pow(2, attempt)));
    }
  }
  throw new Error('Service worker unreachable');
}

2. `chrome.alarms` Is the Only Reliable Timer

setTimeout and setInterval do not persist across service worker suspensions. A 5-minute timer set with setTimeout will fire 30 seconds later — when the service worker happens to wake up and continue execution.

Use chrome.alarms for anything time-based:

// ❌ This timer won't fire reliably in a service worker
setTimeout(() => doSomething(), 5 * 60 * 1000);

// ✅ This will fire even if the service worker was suspended
await chrome.alarms.create('my-task', { delayInMinutes: 5 });

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'my-task') doSomething();
});

The minimum alarm interval is 1 minute. For shorter intervals, you have to use a different approach (keeping the service worker alive with a port connection, though this is unreliable and Google discourages it).

3. `chrome.storage` Race Conditions at Startup

When your service worker wakes up to handle an event, chrome.storage.local.get() might be slow if the storage backend needs to initialize. Code that reads storage synchronously at module level will fail intermittently:

// ❌ Race condition — storage might not be ready
const settings = await chrome.storage.local.get('settings');
let cachedSettings = settings; // Module-level variable

chrome.runtime.onMessage.addListener((msg) => {
  if (cachedSettings.enabled) { // Might be undefined on first wake
    // ...
  }
});

Fix: Read storage inside event handlers, not at module initialization:

// ✅ Always read from storage when handling an event
chrome.runtime.onMessage.addListener(async (msg) => {
  const { settings } = await chrome.storage.local.get('settings');
  if (settings?.enabled) {
    // ...
  }
});

4. `chrome.runtime.lastError` Must Be Checked

In MV3, failing to check chrome.runtime.lastError in callbacks causes uncaught errors that terminate the service worker immediately. This was less fatal in MV2 persistent background pages.

// ❌ If this fails, the service worker dies
chrome.storage.local.set({ key: value }, () => {
  console.log('saved');
});

// ✅ Always check
chrome.storage.local.set({ key: value }, () => {
  if (chrome.runtime.lastError) {
    console.error('Storage error:', chrome.runtime.lastError.message);
    return;
  }
  console.log('saved');
});

If you're using the Promise-based API (Chrome 88+), this is automatic — rejected promises propagate normally. Use the Promise API whenever possible.

5. Content Script Injection Timing Changed

MV2 allowed "run_at": "document_start" scripts to reliably modify the page before any other scripts ran. In MV3, the timing of dynamically injected scripts via chrome.scripting.executeScript is less predictable.

For extensions that need early injection (to intercept fetch calls, patch globals, etc.), stick with the manifest-declared content scripts:

{
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"],
      "run_at": "document_start"  // Still reliable in manifest declaration
    }
  ]
}

Avoid chrome.scripting.executeScript for anything timing-sensitive.

6. The `host_permissions` Split

MV2 combined permissions and host_permissions in one array. MV3 separates them. This isn't just a syntax change — it affects the install warning dialog.

Extensions with host_permissions: ["<all_urls>"] show a scary install warning. Extensions that request host permissions for specific domains show domain-specific warnings. Be intentional about which hosts you actually need:

// ❌ Request only if truly needed for all sites
"host_permissions": ["<all_urls>"]

// ✅ Only request what you use
"host_permissions": [
  "https://api.example.com/*",
  "https://extensionpay.com/*"
]

For my extensions that genuinely need all-host access (content scripts that run on user-chosen pages), I keep <all_urls> and explain it in the CWS listing.

7. `eval()` and `new Function()` Are Forbidden

MV3 enforces a strict Content Security Policy that disallows eval() and new Function(). This breaks several popular libraries that use dynamic code execution internally — including some older versions of template engines and math expression parsers.

Check your dependencies. The error is a CSP violation logged to the console, easy to miss during development if you're not looking for it.

8. The `offscreen` API Is for Background Media

MV3 removed background pages entirely, which broke extensions that needed a persistent DOM context (e.g., to play audio, use the Clipboard API, or parse HTML). The offscreen document API is the replacement:

async function ensureOffscreenDocument(): Promise<void> {
  const existing = await chrome.offscreen.hasDocument();
  if (!existing) {
    await chrome.offscreen.createDocument({
      url: 'offscreen.html',
      reasons: [chrome.offscreen.Reason.CLIPBOARD],
      justification: 'Clipboard operations require a DOM context',
    });
  }
}

The offscreen document is a hidden page that provides a DOM context for background operations. It has the same limitations as service workers (no user-visible UI) but can use DOM APIs.

The Actual Impact

Most of these issues are solvable with a few patterns. The real cost is that MV3 requires more defensive programming. You can't assume your background context is alive, you can't use in-memory state reliably, and you have to be more explicit about when and how you access Chrome APIs.

For simple extensions, MV3 is fine. For complex extensions with long-running operations, you need to design differently.

All my extensions are MV3-native. Source and notes at dev-tools-hub.xyz.

Manifest V3 Migration Pitfalls — Lessons from 17 Chrome Extensions

SHOTA — Mon, 04 May 2026 00:00:00 +0000

Manifest V3 Is Here — And It Broke Everything

Google's Manifest V3 migration deadline has come and gone. After migrating 17 Chrome extensions from MV2 to MV3, I've compiled every pitfall, workaround, and lesson learned.

If you're still migrating — or building new extensions — this guide will save you weeks of debugging.

Pitfall 1: Service Workers Die Without Warning

The problem: MV3 replaces persistent background pages with service workers. Service workers are terminated after ~30 seconds of inactivity. Any state stored in global variables is lost.

What broke: My subscription checking code stored the user's payment status in a variable. After the service worker restarted, the variable was undefined, and paid users saw free-tier limitations.

The fix: Never store state in global variables. Use chrome.storage for everything:

// BAD: Lost when service worker restarts
let userIsPaid = false;

// GOOD: Persisted across restarts
async function isPaid(): Promise<boolean> {
  const { subscriptionCache } = await chrome.storage.local.get('subscriptionCache');
  return subscriptionCache?.paid ?? false;
}

Bonus pitfall: chrome.storage.session exists but is only accessible from the service worker by default. If you need it in popup/content scripts, you must call chrome.storage.session.setAccessLevel({ accessLevel: 'TRUSTED_AND_UNTRUSTED_CONTEXTS' }) in the service worker.

Pitfall 2: webRequest Blocking Is Gone

The problem: chrome.webRequest.onBeforeRequest with blocking capability no longer exists. Extensions that modified or blocked requests must use declarativeNetRequest.

What broke: FocusGuard used webRequest to redirect blocked sites. The entire blocking mechanism stopped working.

The fix: Migrate to declarativeNetRequest with dynamic rules:

await chrome.declarativeNetRequest.updateDynamicRules({
  addRules: [{
    id: 1,
    priority: 1,
    action: {
      type: 'redirect',
      redirect: { extensionPath: '/blocked.html' }
    },
    condition: {
      urlFilter: '*://*.twitter.com/*',
      resourceTypes: ['main_frame']
    }
  }],
  removeRuleIds: [1]
});

Gotcha: Dynamic rules have a limit of 5,000 rules per extension. If your extension needs to block thousands of URLs, use the rule_resources approach with static rulesets instead.

Pitfall 3: Alarm Minimum Is 1 Minute

The problem: chrome.alarms.create enforces a minimum period of 1 minute in production (30 seconds in development).

What broke: My subscription refresh used a 30-second polling interval. In production, it silently upgraded to 60 seconds, causing stale data.

The fix: Design around the 1-minute minimum. For anything that needs sub-minute precision, use setTimeout inside the service worker — but remember the worker can be terminated. For critical timing, accept the 1-minute granularity.

Pitfall 4: Content Script Communication Changes

The problem: When the service worker is inactive, chrome.runtime.sendMessage from a content script can fail silently or throw.

What broke: Content scripts in my extensions would call the background for subscription status. If the service worker was sleeping, the Promise would hang forever.

The fix: Always add timeouts and fallbacks:

async function getSubscription(): Promise<SubscriptionInfo> {
  // Check cache first
  const cache = await chrome.storage.local.get('subscriptionCache');
  if (cache.subscriptionCache?.timestamp > Date.now() - 300000) {
    return cache.subscriptionCache;
  }

  // Ask background with timeout
  return new Promise((resolve) => {
    const timeout = setTimeout(() => resolve(cache.subscriptionCache || DEFAULT), 3000);
    try {
      chrome.runtime.sendMessage({ action: 'getSubscription' }, (res) => {
        clearTimeout(timeout);
        if (chrome.runtime.lastError || !res) {
          resolve(cache.subscriptionCache || DEFAULT);
          return;
        }
        resolve(res);
      });
    } catch {
      clearTimeout(timeout);
      resolve(cache.subscriptionCache || DEFAULT);
    }
  });
}

Pitfall 5: Downloads API Requires User Gesture

The problem: chrome.downloads.download() now requires a user gesture in some contexts. Programmatic downloads from background scripts may fail.

What broke: DataPick's export feature triggered downloads from the content script via the background. It worked in MV2 but silently failed in MV3.

The fix: Trigger downloads from the content script directly using a Blob URL and an anchor click, or ensure the background download is in direct response to a user action message.

Pitfall 6: executeScript Changes

The problem: chrome.tabs.executeScript is replaced by chrome.scripting.executeScript with a different API shape.

The old way:

chrome.tabs.executeScript(tabId, { code: 'document.title' });

The new way:

const [result] = await chrome.scripting.executeScript({
  target: { tabId },
  func: () => document.title,
});
console.log(result.result); // The page title

Gotcha: The func parameter must be a serializable function. It cannot reference variables from the outer scope. Pass data via the args parameter.

Pitfall 7: Extension Size and Permissions Scrutiny

The problem: MV3 extensions face stricter review. Google now flags extensions with broad permissions (<all_urls>, tabs, etc.) and large bundle sizes.

What broke: Two of my extensions were rejected for requesting activeTab + <all_urls> together, which was considered redundant.

The fix:

Request minimum permissions
Use activeTab instead of host permissions where possible
Provide permission justifications in the CWS developer dashboard
Keep bundle sizes small (tree-shake aggressively)

My MV3 Migration Checklist

After 17 migrations, here's my go-to checklist:

[ ] Replace all global state with chrome.storage
[ ] Migrate webRequest to declarativeNetRequest
[ ] Replace chrome.tabs.executeScript with chrome.scripting.executeScript
[ ] Add timeout/fallback to all runtime.sendMessage calls
[ ] Test with service worker restart (chrome://serviceworker-internals)
[ ] Verify alarms work with 1-minute minimum
[ ] Review and minimize permissions
[ ] Test content script ↔ background communication after SW sleep
[ ] Verify downloads work without persistent background

Key Takeaway

MV3 is a fundamentally different programming model. The service worker lifecycle changes everything. Design for statelessness from day one, and treat the service worker as an unreliable intermediary that might not be running when you need it.

Built by S-Hub — 17 Chrome extensions, all running on Manifest V3.

Explore S-Hub Extensions

Procshot — Auto-capture browser steps
DataPick — Extract data from any webpage
FocusGuard — Block distracting sites

See all extensions at dev-tools-hub.xyz

CWS Listing SEO: What Actually Moved the Needle After Publishing 18 Extensions

SHOTA — Sat, 02 May 2026 14:47:08 +0000

Chrome Web Store SEO is poorly documented. Google's official guidance is sparse. There's no Ahrefs for CWS search ranking. Most advice comes from forum posts that are 3-4 years old and may or may not still apply.

After publishing 18 extensions and iterating on listings for 6 months, here's what I've found actually moves install numbers.

The Title Is Everything

The CWS title is the single most important ranking factor. It functions like an HTML <h1> — the primary signal for what this extension does.

What doesn't work: Brand names or clever names without keywords. "ReadMark" tells the CWS search algorithm nothing. "ReadMark — Scroll Position Saver for Chrome" tells it exactly what the extension does.

What works: Primary keyword first, then clarification:

❌  Procshot
✅  Procshot — Auto Step-by-Step Screenshot Manual Creator

❌  DataPick
✅  DataPick — Click-to-Extract Web Scraper (No Code)

❌  Japanese Font Finder
✅  Japanese Font Finder — Click to Identify & Copy Web Fonts

The character limit for CWS titles is 75 characters. Use most of them. Don't pad with fluff, but don't leave ranking signals on the table.

Short Description: The SEO Body Copy

The short description (132 characters max) appears in search results and category listings. It's the second most important field for ranking.

Pack it with semantically related terms — the words people would use to search for your extension:

Before:
"Identify fonts on any webpage and copy CSS font-family syntax."

After:
"Click any element to identify the rendered font, copy CSS syntax, detect web fonts (Google/Adobe). Free font inspector for designers."

The second version includes: font inspector, rendered font, CSS syntax, Google Fonts, Adobe Fonts, designers — all search-relevant terms without being spammy.

Long Description: Depth Over Breadth

The long description doesn't seem to rank for individual keywords the way a web page does, but it influences whether users install after they click through. High click-to-install conversion improves ranking indirectly.

What converts:

1. Lead with the problem, not the solution.

❌  "DataPick is a Chrome extension that extracts web data."

✅  "Copying data from websites to Excel shouldn't require writing code.
    DataPick lets you click on any element to extract it — tables,
    prices, names, links — and export directly to Google Sheets."

2. Use bullet points with verbs.

"View fonts" is weaker than "Click any element to instantly reveal its rendered font." Action-oriented bullets communicate value more clearly.

3. Include the free/paid boundary explicitly.

Users are suspicious of extensions that don't clarify pricing. State it clearly: "Free: 3 scans/month. Pro ($9.99/month): unlimited scans + AI analysis."

4. List what the extension does NOT do.

This sounds counterintuitive but it builds trust: "DataPick does not send your data to external servers. All extraction runs locally." Users who almost clicked away because of data concerns will install.

Screenshot Quality Is a Ranking Factor

Chrome Web Store A/B tests screenshot carousels for conversion. High-converting listings get better placement.

My screenshots follow a formula:

Screenshot 1: The core action (click something → get result)
Screenshot 2: The output or result state
Screenshot 3: Settings or Pro features

1280×800 is the standard size. Use a real browser with realistic content, not placeholder text. Annotations (arrows, callouts) help but should be minimal.

I've measured approximately 20-30% higher CTR for listings with annotated screenshots vs. plain browser screenshots.

Category Selection

Most extensions fit multiple categories. The category affects which browse pages you appear on, which affects discovery separate from search.

My rules:

If it's for developers: Developer Tools
If it's for productivity: Productivity
Don't use Other unless nothing fits

Developer Tools has less competition than Productivity for most queries, but smaller total audience. Pick based on where your target user is browsing.

Review Velocity Matters More Than Review Count

A fresh 4.8-star extension with 15 reviews can rank above a 4.9-star extension with 150 reviews if the 15 reviews came in the last 30 days. CWS appears to weight recency.

This means: if your extension is growing, make sure your review request is well-timed and converts.

I prompt for reviews after a "success moment" — after the user has successfully completed the core action for the third time. Not on first launch, not on a timer. After they've experienced value.

The prompt text matters: "If DataPick saved you time today, a quick review helps other people find it." Specific, honest, no-pressure. I've measured about 12% conversion rate from prompt shown to review left.

The Permission Warning Problem

Extensions that request broad permissions show a warning during install: "This extension can read all your browser data." This is accurate but alarming phrasing.

Two things help:

Request only the permissions you actually need
Explain permissions in your listing description: "DataPick requires access to all sites because you can use it on any website. We never collect or transmit your data."

Extensions with unexplained broad permissions have measurably lower install rates. The listing is where you explain, not the install dialog.

What Doesn't Move the Needle

Keyword stuffing in the description. The algorithm seems to penalize this now, and it hurts conversion anyway.

Promo images. The 1400×560 marquee image is shown in promotional spots (featured sections), not in regular search. Unless you're getting featured, it doesn't matter.

Video demos. I've tested with and without. No measurable install difference from search. Videos do help for extensions with complex UX that's hard to show in a screenshot.

Tracking What Works

CWS provides an Insights dashboard with impressions, clicks, and installs broken down by traffic source (search, browse, referral). Use it. Track which source drives installs, then optimize for that source.

For me, CWS search accounts for ~70% of installs. That's where the SEO work pays off.

I publish Chrome extensions at dev-tools-hub.xyz. These notes are based on 6 months of iteration across 18 extensions.

Chrome Web Store SEO: How I Optimized 17 Extensions for Search

SHOTA — Sat, 02 May 2026 00:00:00 +0000

Chrome Web Store Has a Search Engine — and Nobody Optimizes for It

Most Chrome extension developers publish their extension and hope for the best. But the Chrome Web Store has its own search algorithm, and optimizing for it can dramatically increase your install rate.

After publishing 17 extensions and experimenting with different approaches, here's everything I've learned about CWS SEO.

How CWS Search Works

The Chrome Web Store search algorithm considers:

Extension name (highest weight)
Short description (the 132-character summary)
Full description (the detailed listing text)
Category selection
User ratings and review count
Weekly active users (WAU)
Install/uninstall ratio

Let me break down each factor with real examples from my extensions.

Factor 1: Extension Name — Keyword First

The single biggest SEO lever is your extension name. CWS heavily weights the name field for search ranking.

Before optimization:

"Procshot" → Ranked nowhere for "screenshot chrome extension"
"ZenRead" → Invisible for "reader mode chrome"

After optimization (keyword-first format):

"Procshot — Automatic Procedure Capture & Step-by-Step Guide Maker"
"ZenRead — Reader Mode & Read Aloud for Chrome"

Results: Average search impression increase of 340% across 17 extensions after switching to keyword-first names.

The Formula

[Brand] — [Primary Keyword] [Secondary Keyword] [Modifier]

Examples:

DataPick — Web Data Extractor & Scraper for Chrome
CookieJar — Cookie Editor, Manager & Privacy Analyzer
FocusGuard — Website Blocker & Focus Timer

Factor 2: Short Description (132 Characters)

The short description appears in search results and listing cards. Every character matters.

Rules:

Lead with the primary benefit, not the feature
Include your top 2-3 keywords naturally
End with a differentiator

Example for DataPick:

"Extract tables, lists & text from any webpage. Export to CSV, Excel, JSON or Google Sheets. No coding required."

This hits: extract, tables, webpage, CSV, Excel, JSON, Google Sheets, no coding — all high-volume search terms.

Factor 3: Full Description

The full description supports long-tail keywords. Structure it as:

Opening paragraph — Problem statement with keywords
Feature list — Each feature is a keyword opportunity
Use cases — "Perfect for [persona] who need to [action]"
Technical details — Manifest V3, permissions explanation
Privacy statement — Builds trust and conversion

Localization Multiplier

CWS supports localized listings. I localize into 8 languages:

English, Japanese, Chinese (Simplified), Korean, Spanish, French, German, Portuguese

Each localization creates a new surface for search in that language. My Japanese Font Finder extension gets 40% of installs from Japanese-language searches.

Factor 4: Screenshots and Promo Images

Screenshots don't directly affect search ranking, but they massively impact click-through rate from search results to your listing page.

What works:

First screenshot should show the extension in action (not a marketing slide)
Include text overlays explaining what's happening
Use consistent branding across all screenshots
1280x800 resolution, clean and professional

What doesn't work:

Generic mockups
Too much text, too little product
Inconsistent styling between screenshots

Factor 5: Ratings and Reviews

CWS algorithm favors extensions with:

Higher average rating (4.0+ is the threshold for good ranking)
More total reviews (even 5-10 reviews make a difference for new extensions)
Recent reviews (recency matters)

Win-Ask Review Strategy

I implemented a "Win-Ask" review prompt in all my extensions:

Trigger after a successful action (not on install, not randomly)
For Procshot: After capturing 5 procedures successfully
For DataPick: After 10 successful data extractions
Two buttons: "Rate on Chrome Web Store" and "Not now"
"Not now" dismisses permanently (no nagging)

This approach respects users while still generating reviews.

Factor 6: Weekly Active Users

WAU is a ranking signal. Extensions with higher WAU rank better, creating a flywheel: better ranking → more installs → higher WAU → better ranking.

How to improve WAU:

Reduce uninstall rate (better onboarding, deliver value fast)
Cross-promote between your extensions
Content marketing (Dev.to, Zenn, Reddit)
Keep the extension lightweight (slow extensions get uninstalled)

My CWS SEO Checklist

For every extension I publish, I run through this checklist:

[ ] Keyword-first name format
[ ] 132-char description with top keywords
[ ] Full description with structured sections
[ ] 5 screenshots with text overlays
[ ] Small tile (440x280) with brand consistency
[ ] 8-language localization
[ ] Category selection optimized
[ ] Win-Ask review prompt implemented
[ ] Cross-promotion banner added
[ ] GA4 tracking for install/update/feature_used events

Results

After applying these optimizations across all 17 extensions:

Metric	Before	After (30 days)
Total weekly installs	120	380
Average search impressions	2,400/week	8,100/week
Average CTR from search	2.1%	3.8%
Average rating	4.2	4.5

The biggest winner was DataPick, which went from 15 installs/week to 65 after the keyword-first name change alone.

Key Takeaway

CWS SEO isn't complicated, but almost nobody does it. The extension name is 80% of the battle. Get that right, and everything else follows.

Built by S-Hub — 17 Chrome extensions for developers and productivity enthusiasts.

Explore S-Hub Extensions

Procshot — Auto-capture browser steps
DataPick — Extract data from any webpage
CookieJar — Cookie editor and privacy analyzer

See all extensions at dev-tools-hub.xyz

How I Cross-Promote 18 Chrome Extensions Without Annoying Users

SHOTA — Thu, 30 Apr 2026 15:48:07 +0000

I publish Chrome extensions as a solo developer. I currently have 18 live extensions across two Chrome Web Store accounts, with more in development.

Each extension runs in isolation. A user who installs ReadMark has no reason to know that Japanese Font Finder exists — unless I tell them. This is the cross-promotion problem.

Done badly, cross-promotion is spammy: "You might also like..." banners competing with the actual UI, persistent notifications pushing other products, or promotional modals that appear on first launch. These damage trust and hurt retention.

Done well, cross-promotion is genuinely useful: surfacing a related tool at the moment a user is most likely to want it, in a way that doesn't interrupt their workflow.

Here's what I've implemented across my extensions and what actually works.

Where Cross-Promotion Lives

The four legitimate places I've found:

1. The onboarding screen

Every new extension I build has a welcome screen that appears once on first install. This is the highest-engagement moment — the user has just installed, they're curious, and they have no workflow to interrupt.

The bottom of the onboarding screen includes a "You might also like" section showing 2-3 related extensions from my portfolio. The slot is populated based on the category of the extension they just installed:

Productivity extensions → show other productivity tools
Developer tools → show developer tools
Japanese-language tools → show other Japan-focused tools

const RELATED_BY_CATEGORY: Record<Category, ExtensionInfo[]> = {
  productivity: [
    { name: 'ReadMark', cws: 'https://chromewebstore.google.com/...', icon: '...' },
    { name: 'FocusGuard', cws: 'https://chromewebstore.google.com/...', icon: '...' },
  ],
  'developer-tools': [
    { name: 'Japanese Font Finder', cws: '...', icon: '...' },
    { name: 'DataBridge', cws: '...', icon: '...' },
  ],
  // ...
};

Conversion rate on this slot: ~8%. It's the best-performing placement I have, and it requires zero additional interruption — the user is already looking at an onboarding screen.

2. The settings/options page

My extensions all have a settings page accessible via the popup or options page. At the bottom, a small "Other tools by the same developer" section.

This placement has low visibility — most users never open settings — but high intent. Someone exploring settings is an engaged user. Conversion here is ~4%.

3. Post-export or post-action moments

Some extensions have natural completion moments. Procshot, for example, has a "Guide created" state after the user finishes recording a workflow. At this point, the task is done and the user has a second of cognitive slack.

I show a single inline suggestion: "Looking for complementary tools? Try [X]."

This feels contextually relevant rather than promotional. If someone just created a procedure guide, they might also like a tool that helps them organize notes or manage their workflow.

4. The Chrome Web Store listing itself

I include links to related extensions in the long description text of each CWS listing. The format:

---
Other tools you might find useful:
• ReadMark (save scroll position): [link]
• Procshot (create step-by-step guides): [link]

CWS listing descriptions don't support hyperlinks that are clickable, but the URLs are visible and some users do copy and search them. More importantly, these listings show up in Google Search, which occasionally drives cross-traffic.

What I Don't Do

Push notifications: I have notifications permission on some extensions for functional purposes (session timers, etc.). I never use this for promotions. Push notifications are for urgent, functional information only.

In-session banners: No banners appear while the user is actively using the extension. The active state is for doing the thing, not for advertising other things.

Frequency-based nudges: No "You've been using this for 30 days — here are our other products" messages. I've seen this pattern from larger companies and I find it manipulative.

Email capture for cross-promotion: Chrome extensions don't have a natural email capture point, and I don't manufacture one. My extensions work without accounts.

Measuring It

I track cross-promotion clicks with GA4 events:

function trackCrossPromoClick(source: string, targetExtension: string): void {
  gtag('event', 'cross_promo_click', {
    source_location: source,      // 'onboarding' | 'settings' | 'post_action'
    target_extension: targetExtension,
  });
}

The conversion from click to install is hard to measure directly — I can see the click in GA4 but I can't easily track what happens in the CWS after the user navigates there. I proxy this with CWS install trends: when I add a cross-promotion slot pointing to Extension X, does Extension X's weekly installs increase?

Over 12 weeks, the answer has been yes, modestly — about a 15-20% lift in weekly installs for extensions that are actively promoted from related extensions. Not explosive growth, but it compounds.

The Principle

Cross-promotion works when it answers the question "what else can help me with what I'm already trying to do?" It fails when it answers "what else can I sell this user?"

The onboarding screen converts at 8% not because users are gullible but because the recommended extensions are actually useful to someone who just installed a related tool. The relevance makes the difference.

I write about solo Chrome extension development at dev-tools-hub.xyz.

Forem: SHOTA

Building a Cookie Manager Chrome Extension: What I Learned From the MV3 Transition

The cookies API in MV3

Real-Time Cookie Monitoring Without a Persistent Background

Cookie Editing: The Session/Persistent Distinction

The httpOnly Problem

Search and Filter

Import/Export

The MV3 Lesson

Building a Cookie Editor Chrome Extension — Why I Built CookieJar After EditThisCookie Died

EditThisCookie Is Gone — Now What?

What CookieJar Does Differently

1. Automatic Cookie Classification

2. Privacy Score

3. Profile Management

4. Export Formats

Technical Architecture

MV3 Cookie Access

Real-Time Updates

Performance

8-Language Localization

Privacy Commitment

Installation

More Developer Tools from S-Hub

Real Numbers: Freemium Chrome Extension Monetization After 6 Months

The Portfolio

Conversion Rates

The Limit Design Matters More Than the Price

The Upgrade Prompt Matters

ExtensionPay Observations

The Revenue Reality

What I'd Do Differently

Monetizing Chrome Extensions with Freemium — Real Numbers from 7 Paid Extensions

Can You Actually Make Money with Chrome Extensions?

The Portfolio

The Freemium Model

Why Freemium Over Paid-Only?

The Reverse Trial Approach

Setting Free Tier Limits

Payment Infrastructure

ExtensionPay + Stripe

Subscription Management in MV3

What I've Learned

Pricing Insights

Conversion Patterns

What Doesn't Work

Revenue Growth Strategy

Key Takeaways

Explore S-Hub Extensions

I Built a Chrome Extension That Checks Japanese Subscription Terms with AI

What It Analyzes

Architecture

Extracting Terms Text

The GPT Analysis Prompt

Free Tier Limits

The Proxy Requirement

What I Learned About Freemium for Utility Extensions

I Built a Chrome Extension That Auto-Fills Any Form — Encrypted, No Cloud

The problem is more specific than it sounds

The technical part I found interesting: storing encrypted data in chrome.storage.local

The form filling part: matching fields without a schema

What the extension actually is

I Built an AI-Powered Japanese Trade Law Compliance Checker as a Chrome Extension

What the Law Actually Requires

Architecture: Extension + Vercel API Proxy

Extracting Contract Text from the DOM

The Analysis Prompt

Rendering Results

Handling Japanese Legal Text

Try ToritekiCheck

Manifest V3 Migration: The Gotchas Nobody Warned Me About

1. Service Workers Die at Inopportune Times

2. chrome.alarms Is the Only Reliable Timer

3. chrome.storage Race Conditions at Startup

4. chrome.runtime.lastError Must Be Checked

5. Content Script Injection Timing Changed

6. The host_permissions Split

7. eval() and new Function() Are Forbidden

8. The offscreen API Is for Background Media

The Actual Impact

The `cookies` API in MV3

The `httpOnly` Problem

2. `chrome.alarms` Is the Only Reliable Timer

3. `chrome.storage` Race Conditions at Startup

4. `chrome.runtime.lastError` Must Be Checked

6. The `host_permissions` Split

7. `eval()` and `new Function()` Are Forbidden

8. The `offscreen` API Is for Background Media