DEV Community: SHOTA

190 Countries, Zero API Calls: Shipping Static Data in a Chrome Extension

SHOTA — Sat, 23 May 2026 15:01:23 +0000

Most Chrome extensions that need data fall into one of two patterns: they call an external API, or they store a small amount of user-specific data locally. EntryCheck does neither. It bundles a static dataset of visa requirements for 190+ passport/destination combinations directly into the extension and resolves every lookup client-side with zero network requests.

This tradeoff — large bundle, instant lookups, no API dependency — turns out to be the right call for travel data. Here's why, and how it works.

Why Static Over API

Visa requirements don't change often. A country might update its visa-on-arrival list two or three times a year. An API would add latency, require authentication, and create a failure mode (network unavailable, API down, rate-limited) in a context where the user is typically trying to quickly check something before booking a flight.

More practically: there's no reliable free public API for visa requirements. The data sources are government websites and reference databases. Scraping or licensing these for a real-time API isn't worth it for a tool whose value is speed and simplicity.

A local JSON file loaded at extension startup sidesteps all of this.

Data Structure

The core dataset is a JSON object keyed by two-letter ISO passport code, then by two-letter destination code:

type VisaStatus =
  | 'visa_free'
  | 'visa_on_arrival'
  | 'e_visa'
  | 'visa_required'
  | 'not_admitted';

interface EntryRequirement {
  status: VisaStatus;
  maxStay?: number;        // days, undefined if no limit
  notes?: string;
}

type VisaMatrix = Record<string, Record<string, EntryRequirement>>;

A lookup is just two array accesses:

function lookup(matrix: VisaMatrix, passport: string, destination: string): EntryRequirement | null {
  return matrix[passport]?.[destination] ?? null;
}

The matrix itself compresses well: visa_free and visa_required cover the majority of combinations, so the JSON has a lot of repeated structure. Gzipped, the full dataset is under 30KB.

Bundling with WXT

The matrix lives in public/visa-matrix.json. WXT (the extension framework) copies the public/ directory to the output root verbatim. The background service worker loads it once on install and caches the result:

let cachedMatrix: VisaMatrix | null = null;

async function getMatrix(): Promise<VisaMatrix> {
  if (cachedMatrix) return cachedMatrix;
  const url = chrome.runtime.getURL('visa-matrix.json');
  const resp = await fetch(url);
  cachedMatrix = await resp.json();
  return cachedMatrix;
}

chrome.runtime.getURL converts the relative path to the extension's internal chrome-extension:// URL. This is the standard pattern for accessing bundled assets from a service worker — it works in MV3 without any special permissions.

Content Script Injection on Google Flights

The lookup popup works fine on its own, but the more useful feature is automatic injection on Google Flights. When a user searches for a flight and the page shows a destination, EntryCheck's content script detects the destination, looks up the requirements for the user's saved passport, and injects a badge next to the search results.

The content script reads the current destination from the URL parameters and page DOM, calls the background for a lookup via chrome.runtime.sendMessage, and renders a small badge component inline.

chrome.runtime.sendMessage(
  { type: 'VISA_LOOKUP', passport: savedPassport, destination: detected },
  (response: EntryRequirement | null) => {
    if (response) renderBadge(response);
  }
);

The background receives this, calls getMatrix(), and returns the result. Because the matrix is in memory after the first load, the response is synchronous from the content script's perspective.

The Maintenance Problem

Static data has one obvious downside: it goes stale. My current approach is to update the JSON file with each extension version bump and push it as a normal CWS update. This is manual but tractable — visa requirements change infrequently enough that quarterly checks cover 95% of changes.

For something that updates more frequently (exchange rates, business hours), this model breaks down and an API makes more sense. Visa requirements are the rare case where static actually wins.

🔗 EntryCheck on Chrome Web Store: Install

How to detect ghost jobs in 2026 — a developer's guide

SHOTA — Wed, 20 May 2026 16:52:37 +0000

I got tired of applying to LinkedIn postings that had been "active 4 days ago" for three months straight. Turns out I wasn't paranoid — the data backs it up. So I built a Chrome extension to flag them, and along the way I worked out how to detect a "ghost job" from inside the browser without hitting any external API. Sharing the playbook here.

The numbers (so you know this isn't rare)

Nearly 4 in 10 hiring managers admit their company has posted jobs with no real plan to fill — Resume Builder 2024 hiring-manager survey, widely reported by WSJ, NYT, and BBC throughout 2024–2025
18% of recruiters say they're actively doing it right now (same survey)
40% of job seekers cite ghost-job frustration as a top complaint (Indeed 2025 candidate sentiment data)
Why it happens: market research, résumé pipeline collection, ATS auto-reposts of already-filled roles, recruiters who quit without removing their open reqs

If you apply to 50 jobs a week and ~40% are ghosts, you're spending around 20 cover letters worth of effort on postings that were never going to convert. At ~12 minutes per tailored application, that's about four hours of your week — every week — burned. Annualized, you're losing two-and-a-half working weeks per year to listings that don't exist.

This is a tractable problem from inside the browser. Here's how.

What "ghost job" actually means

It's not just "a job that didn't reply to me." That's regular job-search reality. A ghost job specifically means one of these:

The role isn't open — posted to pipeline candidates, signal investors the company is growing, or placate an internal stakeholder
The role was open and is now filled, but the posting is still up
The role exists but the hiring manager isn't actively reviewing — auto-rejects only

A good detector doesn't try to read minds. It looks at artifacts of these behaviors that show up in the DOM.

The four signals I use

Signal 1: Posting age

Resume Builder's data puts the median real posting at ~30 days before it's either filled or pulled. Postings still active past 60 days are statistically much more likely to be ghosts.

LinkedIn obfuscates this — it'll show "Posted 4 days ago" even when the underlying post ID has been alive for months. The trick is to parse the <time> element's datetime attribute, not the relative human-readable text.

function getPostingAgeDays(node) {
  const timeEl = node.querySelector('time[datetime]');
  if (!timeEl) return null;
  const posted = new Date(timeEl.getAttribute('datetime'));
  return Math.floor((Date.now() - posted.getTime()) / (1000 * 60 * 60 * 24));
}

If the relative text says "Posted today" but the datetime attribute reads four months ago, that's your first red flag. In my scoring, weight scales linearly past 30 days and hits 2x at 60.

Signal 2: Repost frequency (Levenshtein distance)

Clever recruiters know about the age signal. So they delete a stale posting and re-create it with a new job ID — same description, slightly tweaked title. The relative timestamp resets, the listing looks fresh, and the candidate pool starts over.

You can't catch this with job IDs alone. You need content similarity.

import levenshtein from 'fast-levenshtein';

function isLikelyRepost(currentDescription, historicalDescriptions) {
  for (const past of historicalDescriptions) {
    const distance = levenshtein.get(currentDescription, past);
    const ratio = distance / Math.max(currentDescription.length, past.length);
    if (ratio < 0.05) return true; // <5% character difference = same posting
  }
  return false;
}

Threshold matters. I went with < 5% after testing on ~30 known ghost reposts I'd manually catalogued. <10% gave too many false positives (postings that legitimately got minor edits). <2% missed reposts where the recruiter changed only the location header.

Storage strategy: I keep the last 90 days of descriptions per company in chrome.storage.local with an LRU cap at 1,000 entries. The 10MB quota is plenty for that.

Signal 3: Hidden salary in disclosure-mandatory states

Since 2023, seven US states require salary-range disclosure for any role that could be performed in that state: CA, CO, NY, NJ, WA, MD, RI. (NYC has its own version, and it technically covers any job that could be performed remotely from NYC — which is most knowledge work.)

If a US-targeted posting has no salary range and the company has any operations in those states, that's a real signal. Either:

They're non-compliant (rare for large companies that have legal teams)
The role is targeted at non-covered states only (specific intent — worth checking)
The posting predates the law (which loops back to signal 1)

const DISCLOSURE_STATES = ['CA', 'CO', 'NY', 'NJ', 'WA', 'MD', 'RI'];

function flagMissingSalary(posting) {
  const hasSalary = /\$\d{2,3},?\d{3}/.test(posting.description);
  const inDisclosureState = DISCLOSURE_STATES.some(s =>
    posting.locationHeader.includes(s)
  );
  return inDisclosureState && !hasSalary;
}

Signal 4: Company-level repost rate

If a company has posted 30 roles in the last 6 months and 18 of them have shown age + repost signals, your prior on the next role from that company should be high. This is just Bayesian sanity.

I track this per company in extension storage. After ~10 postings observed per company, the company-level ghost rate becomes a meaningful weight in the score. Below 10 observations, I don't use it — too few samples to be anything but noise.

Putting it together

Final score is a weighted blend, capped at 100:

function ghostScore(posting, history) {
  let score = 0;
  if (posting.ageDays > 60) score += 35;
  else if (posting.ageDays > 30) score += 15;

  if (isLikelyRepost(posting.description, history.descriptions)) score += 25;
  if (flagMissingSalary(posting)) score += 15;
  if (history.companyGhostRate > 0.5) score += 20;
  if (/easy apply/i.test(posting.applyType)) score += 5; // weak signal

  return Math.min(100, score);
}

Bucket the score:

0–30: Likely Real (green)
31–60: Caution (yellow)
61–100: Likely Ghost (red)

These thresholds are arbitrary. I picked them by hand-labelling ~200 postings and tuning until precision on the red bucket sat around 80%. There's no ground truth here — only your tolerance for false positives.

Architecture: MV3, no servers

I wanted this to be 100% client-side. No data leaves the browser, no backend to run, no privacy policy to defend.

content script  →  reads DOM on indeed.com / linkedin.com/jobs / glassdoor.com
       ↓
background SW   →  maintains posting history + company stats in chrome.storage.local
       ↓
popup           →  reads the current job's score and shows the breakdown

The trap I fell into: MV3 service workers go dormant after ~30s of idle. If you're keeping any state in module-level globals, it's gone next time the SW wakes up. Everything has to live in chrome.storage.local. I burned half a day on this — the symptom was scores resetting to "no history" between sessions even though I was clearly calling the store function.

The fix:

// Bad — gone when SW goes dormant
const history = new Map();

// Good — survives dormancy
chrome.storage.local.get(['history'], ({ history = {} }) => {
  // mutate, then write back
  history[companyId] = updated;
  chrome.storage.local.set({ history });
});

Related gotcha: register your event listeners at the top level synchronously. The MV2 "register inside an init callback" pattern silently breaks on MV3 — your listener won't be re-bound when the SW wakes from dormancy, and you'll spend an afternoon wondering why the alarm fires once and never again.

What I'd do differently

Started with two job boards, not three. Maintaining DOM parsers for Indeed, LinkedIn, and Glassdoor is brutal — they each change their layout every 6–8 weeks. If I were starting over I'd ship LinkedIn-only and let user demand drive the second board.
Built the company-level signal first. Per-posting heuristics get noisy. The company-level prior is the thing that actually moves the score meaningfully on repeat offenders — and it's also the signal that gets stronger the longer a user has the extension installed. That's the right kind of moat.
Skipped Levenshtein initially. Useful but expensive — I underestimated how often I'd hit chrome.storage.local on a single page render. For ~1,000-entry history it's fine; if you push past that you'll want a cheap hash-based similarity pre-filter (e.g., shingling) before paying for full Levenshtein.

The product

I shipped this as GhostJob on the Chrome Web Store:

→ https://chromewebstore.google.com/detail/ghostjob/mdjchaohgneaiflafheajamfomeccach

Free for 10 scans/day, with the full score breakdown and recent-checks history. Pro is $6/month or $59 lifetime — unlimited checks, salary insights backed by the public US Bureau of Labor Statistics API, and priority support. Currently scores Indeed, LinkedIn, and Glassdoor postings. English UI is shipping next week (5/29), and the Levenshtein repost-detection update lands the week after (6/5).

If you want to skip the read-and-build path and just use it, that link is the fastest way. If you'd rather take the four signals above and roll your own, that works too — that's why I wrote the post. The hard part of this problem isn't the algorithm. It's keeping the DOM parsers alive against three companies that each rev their job-search UI on a different cadence. If you're going to maintain that yourself, budget for it.

Question for you

What signal am I missing? "Easy Apply" without a follow-up flow is on my list but I haven't tuned its weight enough to commit. Same with recruiter profile age and number of currently-open reqs per recruiter — both feel signal-bearing but I can't isolate them from the company-level signal cleanly yet.

If you've shipped anything in this space — or just have strong opinions about what makes a posting feel like a ghost — drop it in the comments.

What do you use to filter your job search?

Ghost Jobs Are Wasting Your Time — I Built a Chrome Extension to Detect Them

SHOTA — Tue, 19 May 2026 16:51:32 +0000

A ghost job is a job listing that exists but isn't actively hiring. The company posted it months ago, probably isn't reviewing applications, and might not even have a live opening. Estimates put ghost job listings at anywhere from 20% to 40% of what you see on LinkedIn and Indeed on any given day.

The problem is that they look identical to real listings. You can't tell from the title, the company name, or the description. You only figure it out after sending a tailored resume into a void.

I built GhostJob to surface the signal that's already in the listing — you just have to look.

What actually signals a ghost job

Before writing a single line of detection logic, I spent time thinking about what distinguishes a ghost job from a real one given only the information visible on the listing card.

Three signals turned out to be the most reliable:

1. Posting age. This is the strongest signal. A job posted 90+ days ago that hasn't been taken down is almost certainly either abandoned or evergreen (always hiring, always up). Both are forms of ghost job from the applicant's perspective. Real, time-sensitive openings get filled or closed.

2. Description vagueness. Ghost jobs are often templated or copied from old postings. They tend to be short, generic, and missing specific technical requirements. "Strong communication skills and attention to detail" isn't describing a real open role — it's describing every job posting from 2012.

3. Duplicate postings. Some companies maintain permanent listings for roles they hire for occasionally or not at all. If a company has five "Senior Product Manager" postings across different locations that all use identical copy, none of them may be real.

The scoring model

I implemented a simple additive score from 0 to 100:

function daysScore(daysSincePosted: number): number {
  if (daysSincePosted >= 90) return 60;
  if (daysSincePosted >= 60) return 40;
  if (daysSincePosted >= 30) return 20;
  if (daysSincePosted >= 14) return 10;
  return 0;
}

function vaguenessScore(descriptionLength: number, hasSpecificRequirements: boolean): number {
  let score = 0;
  if (descriptionLength < 200) score += 15;
  else if (descriptionLength < 400) score += 8;
  if (!hasSpecificRequirements) score += 10;
  return score;
}

"Specific requirements" means the description mentions a concrete technology, skill level, or credential — React, Python, "3+ years of experience", a certification. Generic descriptions add points; specific ones don't.

The output maps to three tiers: 0–30 is Likely Real, 31–60 is Caution, 61+ is Likely Ghost. I deliberately avoid calling anything definitively a ghost job — the user is making the final call, and false positives have a real cost.

Parsing dates from three different sites

LinkedIn, Indeed, and Glassdoor each have their own date formats and DOM structures. The content script handles each site separately, but they all route through the same date parser:

export function parseDaysAgo(dateText: string): number {
  const text = dateText.toLowerCase().trim();
  if (/today|just posted|now/.test(text)) return 0;
  const dayMatch = text.match(/(\d+)\s*day/);
  if (dayMatch) return parseInt(dayMatch[1], 10);
  const weekMatch = text.match(/(\d+)\s*week/);
  if (weekMatch) return parseInt(weekMatch[1], 10) * 7;
  const monthMatch = text.match(/(\d+)\s*month/);
  if (monthMatch) return parseInt(monthMatch[1], 10) * 30;
  if (/30\+/.test(text)) return 35;
  return 0;
}

Indeed shows "30+ days ago" — a deliberately vague label that hides just how old a listing is. The 30+ match handles that case specifically, mapping it to 35 days.

The SPA problem

LinkedIn and Indeed are single-page applications. They load job cards dynamically as you scroll or filter results. A content script that only runs on document.ready would miss everything loaded after the initial render.

The fix is a MutationObserver that re-runs the scan whenever the DOM changes:

activeObserver = new MutationObserver(() => {
  scanAndInject();
});
activeObserver.observe(document.body, { childList: true, subtree: true });

// Clean up on SPA navigation
window.addEventListener('pagehide', () => activeObserver?.disconnect(), { once: true });

A processing flag prevents concurrent scans from piling up. Each scored card gets data-ghostjob-scored="true" so re-scans skip already-processed cards efficiently.

Injecting badges without breaking the page

The score badge injects as a plain div using insertAdjacentElement('afterend', target) right after the job title. Inline styles instead of injected CSS to avoid specificity battles with each site's stylesheet:

badge.style.cssText = `
  display: inline-flex; align-items: center; gap: 5px;
  padding: 3px 8px; border-radius: 4px;
  background: ${bg}; border: 1px solid ${color}40;
  font-size: 11px; font-weight: 600; color: ${color};
`;
badge.innerHTML = `👻 <span>${label}</span><span style="opacity:0.6"> · ${score}</span>`;
badge.title = `GhostJob Score: ${score}/100`;

The three-tier color system (green/amber/red) makes the signal legible at a glance without requiring the user to read a number.

What the extension is

GhostJob adds a score badge to every job listing on LinkedIn, Indeed, and Glassdoor. Free plan: 20 checks per day. Pro removes the limit and adds a history view.

Available on the Chrome Web Store: https://chromewebstore.google.com/detail/mdjchaohgneaiflafheajamfomeccach

If you're actively job searching, install it and tell me which signals you think are missing from the scoring model — the current weights are a starting point, not a final answer.

More Chrome extension builds at dev-tools-hub.xyz.

How to Avoid Chrome Web Store 'Red Nickel' Rejection: What I Found After Auditing 18 Extensions

SHOTA — Tue, 19 May 2026 16:50:36 +0000

I got my Chrome extension rejected from the Chrome Web Store last week for a 4-letter word: "Free."

Not a permission issue. Not a CSP violation. Not a manifest field. Just the word "Free" sitting in a small badge on my listing image. The Chrome Web Store calls this a Red Nickel violation — their internal name for prohibited promotional language in extension listings.

I run 18 extensions on the store. After the rejection I ran an audit across all of them. 9 had image violations. 14 had description copy violations. Combined, about 80% of my listings tripped at least one Red Nickel rule.

Here's the audit framework I built so this doesn't happen again, plus the categorization that came out of running it.

What "Red Nickel" Actually Is

The public policy text from the Chrome Web Store Developer Program is short:

Listings must not include promotional language or claims about your product, including but not limited to discount notifications, "free" promotions, ratings, awards, or rankings.

Words like "Free", "Best", "Top", "#1", "Award-winning" — even if they're factually true — are not allowed in listing copy, titles, or screenshot images.

"Red Nickel" itself appears to be the internal flag name reviewers use. It isn't in the public documentation. Most developers first hear about it when their extension gets rejected, which is exactly how I learned.

The Two-Hour Audit

After the rejection I wanted to find every remaining violation before the next CWS submission deadline. The audit ran in two passes.

Pass 1 — Image scanning (grep over HTML sources)

All my listing assets are rendered from HTML templates (store-screenshots/html/*.html) before being converted to PNG. That made it easy to grep:

grep -rniE '\b(free|best|top[ -]?rated|#\s*1|無料|最高)\b' \
  extensions/*/store-screenshots/html/

This caught 9 hits across small tiles (440×280) and marquee images (1400×560).

Pass 2 — Description copy (CWS Webstore API)

Listing descriptions live on CWS, not in my repo, so I pulled them via the Chrome Web Store Webstore API for each item and ran the same regex.

14 hits, most of them a trailing "Free." or "Free forever." at the end of feature lists. Easy to miss when you write 18 of them at the same time.

The Four Categories That Came Out of It

The hits clustered into four patterns. I'll walk through them in order of rejection risk.

1. Image badges (highest risk)

This is what got me rejected.

<!-- The line that triggered the rejection -->
<span class="chip">Free</span>

<!-- What I replaced it with -->
<span class="chip">Instant preview</span>

Image text seems to be what reviewers (or automated scanners) check most aggressively. Promotional adjectives here are essentially auto-flagged. Replace them with a functional descriptor that says what the extension does, not how much it costs.

2. Description tail (the "Free." kiss of death)

NG: "Get SEO scores, find issues & export reports. Free forever."
OK: "Get SEO scores, find issues & export reports. Unlimited scans."

Lower review priority than images and currently still passing in many cases, but the policy is the policy. Fix on the next publish cycle so you don't get caught when CWS tightens enforcement.

3. UI mockup labels (gray zone)

If your screenshot mocks a real product UI (Google Flights, Gmail, etc.) and that UI happens to use the word "Best", you're playing a 60/40 game on whether the reviewer reads the context.

<!-- Gray — the original Google Flights label -->
<div class="header">Best departing flights · JPN passport</div>

<!-- Safe side -->
<div class="header">Departing flights · JPN passport</div>

I went with the safe side everywhere. The fix takes 5 minutes; a surprise rejection costs 3-5 days of resubmission. Asymmetric trade — always take the cheap side.

4. Pricing tier names (these are OK)

<div class="plan-name">Free</div>
<div class="plan-price">$0</div>

A pricing table where "Free" sits next to "$0" reads as a tier name, not a promotional claim. Freemium is explicitly allowed by CWS, and the convention is industry standard (Notion, Linear, dozens more). I left these alone, and they've continued to pass review.

The Semantic Edge Case

One pattern I found that confused me: "distraction-free reading."

ZenRead and a few other reading-mode extensions in my portfolio use this. "Free" here is part of a compound adjective ("distraction-free" = "not interrupted by distractions"), not a price claim.

CWS has been letting these through. The judgment seems to be:

If "free" stands alone next to a product noun, it's promotional → NG
If "free" is the second half of a compound that refers to a function or experience, it's semantic → OK

I kept "distraction-free" intact in 2 listings. No issues so far.

The Replacement Framework

The rule I distilled was simple: replace price-attribute words with function-attribute words.

Promotional (NG)	Functional (OK)
Free / Free Forever	"No account" / "Instant" / "Local only"
Free to try / Free to use	"Start immediately" / "No sign-up"
Free Chrome Extension	"MV3 Chrome Extension"
Best / Top-rated	"Complete" / "Built-in" / drop entirely

Functional descriptors are what CWS actively wants in listings. They're more specific (better for the user), they're more honest (better for trust), and they sidestep Red Nickel entirely. A genuine win/win.

The Pre-Publish Gate

After the audit I built a small gate into my publishing workflow:

const RED_NICKEL_PATTERNS: RegExp[] = [
  /\bfree\b/i,
  /\bbest\b/i,
  /\btop[\s-]?rated\b/i,
  /#\s*1\b/,
  /\b無料\b/,
  /\b最高\b/,
];

const SEMANTIC_ALLOWLIST = [
  /distraction-free/i,
  /hands-free/i,
  /lag-free/i,
];

export function scanRedNickel(text: string): RegExp[] {
  if (SEMANTIC_ALLOWLIST.some((p) => p.test(text))) return [];
  return RED_NICKEL_PATTERNS.filter((p) => p.test(text));
}

Before every CWS submission I run this over:

the listing description
the listing title
alt text on each screenshot
the HTML sources for screenshot templates
locale messages.json files (multi-language listings)

If any pattern hits, and the context isn't a pricing tier name ($0 adjacent) or a compound adjective, I fix it before the upload. Five minutes of automation that would have saved me a week of submission churn if I'd written it earlier.

What's Your Trigger Word?

Curious what trips up other CWS publishers. What words got your extension flagged? Drop them in the comments — I'll add the ones I haven't seen to the gate above.

I've been documenting the marketing side of running 18 Chrome extensions at dev-tools-hub.xyz. The CWS SEO learnings have shipped more installs than any paid acquisition channel I've tried — and dodging Red Nickel is now lesson #1 in the pre-publish checklist.

Detecting YouTube SPA Navigation in a Chrome Extension Content Script

SHOTA — Thu, 14 May 2026 16:11:12 +0000

YouTube is a single-page application. The page never fully reloads when you click a video. The URL changes, the DOM updates, but DOMContentLoaded fires exactly once — when Chrome first loads the tab.

This breaks the most natural assumption in Chrome extension development: that your content script runs once per page. For YouTube, "once per page load" means once for the entire session.

I hit this while building LectureLoop — an extension that injects a side panel and loop replay controls onto YouTube lecture videos. When a user navigates from one video to another, the extension needs to reset, re-detect the video element, and reinitialize its state. Without handling SPA navigation, it just… stops working after the first video.

The Problem with `window.location`

The naive fix is to watch window.location.href for changes. Chrome content scripts can read window.location freely. The issue is timing: YouTube uses the History API (history.pushState) to update the URL. There's no event you can listen to directly — popstate only fires on back/forward navigation, not on pushState calls.

You could poll with setInterval, but polling is inaccurate by definition and wastes CPU even when nothing is happening.

MutationObserver on `document.body`

The approach that actually works is watching document.body for DOM subtree changes and comparing the URL on each mutation:

let lastUrl = location.href;

const navObserver = new MutationObserver(() => {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    setTimeout(init, 1500);
  }
});

navObserver.observe(document.body, { childList: true, subtree: true });

window.addEventListener('pagehide', () => navObserver.disconnect(), { once: true });

The setTimeout(init, 1500) gives YouTube's React app time to finish rendering the new video element before init() tries to query it. Without the delay, document.querySelector('video') returns null — YouTube has updated the URL but hasn't yet replaced the DOM.

The pagehide cleanup matters: if the tab is closed or navigated away from, you want to disconnect the observer rather than leaving it running against an unmounted document.

The Loop Replay Implementation

Once the content script reliably re-runs on navigation, implementing loop replay is straightforward. The side panel sends a message to the content script to jump to a specific timestamp:

chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'JUMP_TO_TIMESTAMP' && typeof msg.sec === 'number') {
    const video = document.querySelector('video');
    if (video) video.currentTime = msg.sec;
  }
});

The side panel tracks the loop start and end points. When the video's timeupdate event fires and the current time exceeds the loop end, it sends JUMP_TO_TIMESTAMP with the loop start time. This gives users a way to replay a specific section of a lecture repeatedly without scrubbing the timeline by hand.

Why Not `scripting.executeScript`?

An alternative is to use chrome.scripting.executeScript from the background service worker instead of keeping long-lived listeners in a content script. The tradeoff: executeScript requires the scripting permission, which triggers a warning in the Chrome Web Store review process about "reading browsing history." Using a content script with matches: ["https://www.youtube.com/*"] avoids this — it's a declared, static permission that reviewers understand at a glance.

It's a minor point, but CWS reviewers look at permissions carefully. Keeping the injection in the content script declaration rather than calling executeScript from background kept the permission list clean.

Lessons

Three things I'd do differently on the next extension that needs SPA navigation handling:

Set the URL guard at the start of init(), not just in the observer. If init() is async and runs while the user clicks to a third video, you can end up with two concurrent initializations racing each other.
Use a cancellation token. Start each init() with an incrementing ID, and bail out of the async steps if a newer ID has been issued.
Log every navigation event in development. YouTube's SPA navigation is fast and the delay is imprecise — having a visible indicator that the observer fired makes the timing problem much easier to debug.

🔗 LectureLoop on Chrome Web Store: Install

I Built a Price History Tracker for Japan's 4 Major E-Commerce Sites (Amazon.co.jp, Rakuten, Yahoo!, Mercari)

SHOTA — Tue, 12 May 2026 16:20:43 +0000

Keepa tracks Amazon price history. It works well for Amazon.com. For Amazon.co.jp it has gaps — delayed updates, missing products, no Rakuten/Yahoo!/Mercari support at all.

If you shop regularly on Japanese e-commerce, you're working across four very different sites with no unified price history. I wanted to know: was this ¥9,800 laptop stand expensive last month, or is it always ¥9,800? Is this Mercari listing a fair price compared to last week?

I built PricePulse JP to answer that. The interesting engineering problem was getting consistent price data out of four sites that don't look anything alike.

The four-site parsing problem

The naive approach to price extraction is: find the DOM element that shows the price, read textContent. That works until Amazon quietly renames its CSS classes (which it does, routinely), or you're on a Rakuten shop that a merchant themed themselves.

Each site needed a different strategy.

Amazon.co.jp mutates its DOM frequently enough that a single selector is a liability. I maintain a fallback chain of 8 selectors in priority order:

const priceSelectors = [
  '#corePriceDisplay_desktop_feature_div .a-price .a-offscreen',
  '#corePrice_feature_div .a-price .a-offscreen',
  '#apex_desktop .a-price .a-offscreen',
  '#priceblock_ourprice',
  '#priceblock_dealprice',
  '#priceblock_saleprice',
  'span.a-price.apexPriceToPay .a-offscreen',
  '.a-price .a-offscreen',  // last resort
];

The first selector that returns a non-zero price wins. This survives most Amazon layout changes because at least one selector in the chain is usually current.

Rakuten is harder. Rakuten Ichiba lets merchants customize shop layouts, so DOM selectors vary wildly across shops. The saving grace: Rakuten enforces schema.org Product metadata platform-wide. Every item page has <meta itemprop="price" content="...">. Merchant themes can't change that. I parse metadata first and only fall back to DOM selectors if the metadata is absent.

Yahoo! Shopping has two URL patterns (store.shopping.yahoo.co.jp and shopping.yahoo.co.jp/products/) and also reliably exposes schema.org meta[itemprop="price"]. Same approach as Rakuten: metadata first.

Mercari also uses schema.org metadata — meta[itemprop="price"] and meta[property="product:price:amount"]. The Mercari-specific edge case is that sold items don't have a price. When an item sells, the price meta disappears. The parser returns null in this case instead of writing a zero, which preserves the last known price in the watchlist rather than recording a false "price dropped to 0."

Why one parser runs in two contexts

There's a common architecture question with Chrome extensions: do you parse in the content script (runs in the page's tab) or in the background service worker (runs separately)?

Content scripts have direct DOM access. Service workers can use fetch() and DOMParser but don't have live DOM. For price tracking you want both: parse on page load (for immediate feedback) and re-check in the background on a schedule (for alerts when you're not browsing).

The solution is to write each parser as a pure function that takes a Document argument:

export function parseAmazonDoc(doc: Document, sourceUrl: string): ParsedProduct | null

The content script passes document. The background refresh task passes the result of:

const res = await fetch(url, { headers: { 'Accept': 'text/html' } });
const html = await res.text();
const doc = new DOMParser().parseFromString(html, 'text/html');

Same logic, two inputs. No code duplication.

Storing price history without external dependencies

Price history needs a proper database — not chrome.storage.local (5 MB quota, slow on large reads) and not a remote server (I wanted this fully local).

IndexedDB fits. Two object stores:

watchlist: keyed by product ID, indexed by site. Stores the product title, URL, current price.
history: compound key [watchId, timestamp], append-only. Each price check writes a new point.

const DB_NAME = 'pricepulse';

// watchlist: { id, site, title, url, currentPrice, addedAt }
const watchlistStore = db.createObjectStore('watchlist', { keyPath: 'id' });
watchlistStore.createIndex('site', 'site', { unique: false });

// history: append-only price log per product
db.createObjectStore('history', { keyPath: ['watchId', 't'] });

I wrote this without the idb wrapper library to keep bundle size small. The raw IndexedDB API is verbose but the transaction pattern is manageable once you wrap it:

function tx<T>(store: string, mode: IDBTransactionMode, run: (tx: IDBTransaction) => T): Promise<T>

Price drop alerts

The background check runs on a chrome.alarms schedule. Alarms fire even when no tab is open. When the fetched price is lower than the stored targetPrice threshold, it triggers a desktop notification:

chrome.alarms.create('priceCheck', { periodInMinutes: 60 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name !== 'priceCheck') return;
  const watchlist = await db.getAllWatching();
  for (const item of watchlist) {
    const updated = await fetchPriceForWatch(item);
    if (updated && item.targetPrice && updated.price <= item.targetPrice) {
      chrome.notifications.create({ /* ... price drop alert ... */ });
    }
  }
});

What it is

PricePulse JP tracks prices across Amazon.co.jp, Rakuten, Yahoo! Shopping, and Mercari. Add items to your watchlist, set a target price, and get a notification when they drop. Price history chart is visible in the popup. Free plan: 10 items. Pro removes the limit and adds CSV export.

Available on the Chrome Web Store: [PricePulse JP — coming soon]

Part of my series on building Chrome extensions for the Japanese market. More at dev-tools-hub.xyz.

I Built a Chrome Extension That Catches Japanese Ad Law Violations in Real Time

SHOTA — Sun, 10 May 2026 14:52:48 +0000

Japanese advertising law is a minefield.

If you work in Japanese digital marketing, you know the anxiety. A single word like 最高 (best) or 必ず (guaranteed) could technically violate 景品表示法 (Keihyo-ho). A beauty product description mentioning skin improvement might run afoul of 薬機法 (Yakki-ho). An influencer post without a clear "PR" disclosure triggers ステルスマーケティング (stealth marketing) regulations.

I was helping a friend review ad copy for a cosmetics brand when I realized: there is no tooling for this. No browser extension, no real-time checker, nothing. You either know the rules by heart or you pay a lawyer.

So I built one.

What AdLegalCheck Does

AdLegalCheck is a Chrome extension that automatically scans any webpage you visit and flags potential violations across three Japanese legal frameworks:

景品表示法 (Keihyo-ho) — Misleading claims, exaggerated benefits, prohibited comparative advertising
薬機法 (Yakki-ho) — Health and beauty claims that are illegal for cosmetics and quasi-drugs
ステルスマーケティング規制 — Undisclosed sponsored content or paid reviews

When you open a product page or ad landing page, the extension:

Scans the visible text for 68 high-risk keywords and patterns
Highlights risky words directly on the page
Opens a side panel with a risk score (0-100) and findings sorted by severity
(Pro) Runs GPT-4o-mini AI analysis for context-aware evaluation

The Technical Stack

Built with WXT + React + TypeScript — WXT gives you a proper build system with HMR, TypeScript out of the box, and sensible MV3 defaults.

adlegalcheck/
├── entrypoints/
│   ├── content.ts        # Page scanner + keyword highlighter
│   ├── sidepanel/        # React UI for results
│   └── background.ts     # Message bus + usage tracking
├── lib/
│   ├── keywords.ts       # 68 NG keyword database
│   ├── scanner.ts        # Regex matching engine
│   └── ai-analyzer.ts    # GPT proxy client
└── wxt.config.ts

The Keyword Database

The core is a curated list of 68 expressions organized by violation type and severity:

type KeywordEntry = {
  pattern: RegExp;
  law: "keihyo" | "yakki" | "stealth";
  severity: "high" | "medium" | "low";
  reason: string;
};

const keywords: KeywordEntry[] = [
  {
    pattern: /日本一|No\.?\s*1|ナンバーワン/g,
    law: "keihyo",
    severity: "high",
    reason: "Absolute superiority claims require substantiation",
  },
  {
    pattern: /必ず|絶対に|100%/g,
    law: "keihyo",
    severity: "high",
    reason: "Guarantee expressions violate 景表法 §5",
  },
  {
    pattern: /美白|シミが消|肌が若返/g,
    law: "yakki",
    severity: "high",
    reason: "Prohibited efficacy claims for cosmetics",
  },
];

Content Script: Highlighting Without Breaking the Page

The trickiest part was highlighting keywords inside arbitrary DOM trees without corrupting the page structure. I use a TreeWalker to find text nodes, then wrap matches in <mark> elements:

function highlightInNode(node: Text, matches: Match[]): void {
  const text = node.textContent ?? "";
  if (matches.length === 0) return;

  const fragment = document.createDocumentFragment();
  let lastIndex = 0;

  for (const match of matches) {
    if (match.start > lastIndex) {
      fragment.appendChild(
        document.createTextNode(text.slice(lastIndex, match.start))
      );
    }
    const mark = document.createElement("mark");
    mark.className = `adlc-highlight adlc-${match.severity}`;
    mark.textContent = text.slice(match.start, match.end);
    mark.title = match.reason;
    fragment.appendChild(mark);
    lastIndex = match.end;
  }

  if (lastIndex < text.length) {
    fragment.appendChild(document.createTextNode(text.slice(lastIndex)));
  }

  node.parentNode?.replaceChild(fragment, node);
}

AI Analysis via Vercel Proxy

The Pro feature sends the page text to GPT-4o-mini for context-aware analysis. A keyword matcher cannot understand nuance — "最高の気分" (feeling great) is fine; "最高の効果" (highest efficacy) is not.

I route all AI calls through a Vercel serverless function so the OpenAI API key never touches the client:

const response = await fetch(
  "https://s-hub-dashboard.vercel.app/api/llm/chat",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      messages: [
        {
          role: "system",
          content: `You are a Japanese advertising law compliance expert.
            Analyze the provided text for violations of:
            1. 景品表示法 (misleading claims, absolute superiority)
            2. 薬機法 (prohibited health/beauty efficacy claims)
            3. ステルスマーケティング規制 (undisclosed sponsorship)
            Return JSON: { riskScore: 0-100, findings: Finding[], summary: string }`,
        },
        { role: "user", content: pageText.slice(0, 4000) },
      ],
    }),
  }
);

Risk Score Calculation

The 0-100 risk score combines keyword density and AI analysis:

function calculateRiskScore(
  keywordFindings: Finding[],
  aiScore?: number
): number {
  const keywordScore = Math.min(
    keywordFindings.reduce((acc, f) => {
      const weights = { high: 20, medium: 10, low: 5 };
      return acc + weights[f.severity];
    }, 0),
    70
  );

  if (aiScore !== undefined) {
    return Math.round(keywordScore * 0.4 + aiScore * 0.6);
  }
  return keywordScore;
}

Freemium Design

Free tier: 3 page scans per month, keyword matching only.
Pro ($9.99/month): Unlimited scans + AI analysis + CSV export.

Monetization via ExtensionPay — no backend needed for payments.

Who Is This For?

Japanese marketing teams and copywriters who need a quick gut-check before publishing:

Draft ad copy, put it on a staging page
Open the extension, hit scan
Red highlights = fix before legal review
Ship with confidence

Not a replacement for a lawyer — the disclaimer is built into the UI. But catching obvious violations before they reach legal review saves time and money.

What is Next

Better pattern matching for idiomatic expressions
Support for 特定商取引法 (e-commerce disclosure requirements)
Batch scanning via CSV upload (Pro roadmap)

The extension is live on the Chrome Web Store.

Built with WXT + React + TypeScript. AI analysis powered by GPT-4o-mini via Vercel serverless.

I Built a Chrome Extension That Remembers Where You Stopped Reading

SHOTA — Sun, 10 May 2026 09:00:00 +0000

Long articles are everywhere — documentation, research papers, Substack posts, long-form journalism. And browser tabs are how we "save" them. We pin them. We bookmark them. We email ourselves links. Then we come back hours later, scroll frantically trying to remember where we left off, give up, and close the tab.

I got tired of this workflow and built ReadMark, a Chrome extension that automatically saves your scroll position on any page and restores it when you return. This article covers the technical challenges of building a reliable reading position tracker.

The Core Problem: Scroll Position Is Not a URL

The naive solution is to store window.scrollY per URL. But this immediately runs into problems:

Infinite scroll pages shift content as you scroll, so the same scrollY value points to different content after more items load.
SPAs change the URL without reloading, so you get position restoration at the wrong logical scroll depth.
Dynamic content (ads, lazy-loaded images) causes layout shifts that make absolute pixel positions unreliable.

The more reliable approach is document fraction position:

function getScrollFraction(): number {
  const scrollTop = window.scrollY || document.documentElement.scrollTop;
  const scrollHeight = document.documentElement.scrollHeight;
  const clientHeight = document.documentElement.clientHeight;
  const scrollable = scrollHeight - clientHeight;
  if (scrollable <= 0) return 0;
  return Math.min(scrollTop / scrollable, 1.0);
}

function restoreScrollFraction(fraction: number): void {
  const scrollable =
    document.documentElement.scrollHeight -
    document.documentElement.clientHeight;
  window.scrollTo({ top: fraction * scrollable, behavior: 'instant' });
}

Challenge 1: Restoration Timing

The first version restored position on DOMContentLoaded. This broke on almost every modern site because CSS, images, and third-party widgets shift the layout after DOMContentLoaded fires.

The solution is to wait for visual stability using a cascade:

async function waitForStability(): Promise<void> {
  await new Promise<void>(resolve => {
    if (document.readyState === 'complete') {
      setTimeout(resolve, 200);
    } else {
      window.addEventListener('load', () => setTimeout(resolve, 200), { once: true });
    }
  });

  const pendingImages = Array.from(document.querySelectorAll('img'))
    .filter(img => !img.complete);

  if (pendingImages.length > 0) {
    await Promise.race([
      Promise.all(pendingImages.map(img =>
        new Promise(resolve => {
          img.addEventListener('load', resolve, { once: true });
          img.addEventListener('error', resolve, { once: true });
        })
      )),
      new Promise(resolve => setTimeout(resolve, 2000))
    ]);
  }

  await new Promise(resolve => requestAnimationFrame(resolve));
}

The 200ms delay after load catches most synchronous layout shifts. The image wait covers hero images that push content down. The final requestAnimationFrame ensures we are after the browser's next paint cycle.

Challenge 2: SPA Navigation Detection

For React/Vue/Next.js sites, history changes are invisible to standard event listeners. I intercept history.pushState and history.replaceState:

function monkeyPatchHistory(): void {
  const originalPushState = history.pushState.bind(history);
  history.pushState = function(...args) {
    const result = originalPushState(...args);
    window.dispatchEvent(new Event('readmark:navigation'));
    return result;
  };
  window.addEventListener('popstate', () =>
    window.dispatchEvent(new Event('readmark:navigation'))
  );
}

Key insight: save before navigating, not just on scroll. If the user clicks a link before the debounce fires, you lose their position.

Challenge 3: Auto-Save Without Spamming Storage

Scroll events fire at ~60Hz. Writing to chrome.storage.local on every event would saturate the API. I use a 1500ms debounce with a synchronous flush on beforeunload:

class PositionTracker {
  private pendingPosition: number | null = null;
  private saveTimer: ReturnType<typeof setTimeout> | null = null;

  onScroll(): void {
    this.pendingPosition = getScrollFraction();
    if (this.saveTimer) clearTimeout(this.saveTimer);
    this.saveTimer = setTimeout(() => this.flush(), 1500);
  }

  onBeforeUnload(): void {
    if (this.pendingPosition !== null) {
      chrome.runtime.sendMessage({
        type: 'SAVE_POSITION_SYNC',
        url: location.href,
        position: this.pendingPosition
      });
    }
  }

  private flush(): void {
    if (this.pendingPosition === null) return;
    chrome.storage.local.set({
      [storageKey(location.href)]: { position: this.pendingPosition, savedAt: Date.now() }
    });
    this.pendingPosition = null;
  }
}

Challenge 4: Storage Key Normalization

https://example.com/article?utm_source=twitter and https://example.com/article are the same article. I strip tracking parameters before generating storage keys:

const TRACKING_PARAMS = new Set([
  'utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term',
  'fbclid', 'gclid', 'ref', 'source',
]);

function normalizeUrl(url: string): string {
  try {
    const parsed = new URL(url);
    for (const param of TRACKING_PARAMS) {
      parsed.searchParams.delete(param);
    }
    parsed.pathname = parsed.pathname.replace(/\/$/, '') || '/';
    return parsed.toString();
  } catch {
    return url;
  }
}

UX Decision: When to Show the Restore Banner

Silent immediate restoration is startling. Instead, I show a banner only after the user starts scrolling:

window.addEventListener('scroll', async () => {
  if (getScrollFraction() < 0.05) return;
  const saved = await getSavedPosition(location.href);
  if (!saved || saved.position < 0.1) return;
  showRestoreBanner(saved);
}, { passive: true, once: true });

Banner conversion rate in testing: ~70%. Users who have started scrolling and haven't found their spot are genuinely happy to see the offer.

Try ReadMark

ReadMark is free for up to 10 saved positions. The Pro plan ($4.99 one-time) removes the limit and adds export/import, tag organization, and full-text search across saved bookmarks.

View on Chrome Web Store

Other tools I've built:

View on Chrome Web Store
View on Chrome Web Store

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

DEV Community: SHOTA

190 Countries, Zero API Calls: Shipping Static Data in a Chrome Extension

Why Static Over API

Data Structure

Bundling with WXT

Content Script Injection on Google Flights

The Maintenance Problem

How to detect ghost jobs in 2026 — a developer's guide

The numbers (so you know this isn't rare)

What "ghost job" actually means

The four signals I use

Signal 1: Posting age

Signal 2: Repost frequency (Levenshtein distance)

Signal 3: Hidden salary in disclosure-mandatory states

Signal 4: Company-level repost rate

Putting it together

Architecture: MV3, no servers

What I'd do differently

The product

Question for you

Ghost Jobs Are Wasting Your Time — I Built a Chrome Extension to Detect Them

What actually signals a ghost job

The scoring model

Parsing dates from three different sites

The SPA problem

Injecting badges without breaking the page

What the extension is

How to Avoid Chrome Web Store 'Red Nickel' Rejection: What I Found After Auditing 18 Extensions

What "Red Nickel" Actually Is

The Two-Hour Audit

Pass 1 — Image scanning (grep over HTML sources)

Pass 2 — Description copy (CWS Webstore API)

The Four Categories That Came Out of It

1. Image badges (highest risk)

2. Description tail (the "Free." kiss of death)

3. UI mockup labels (gray zone)

4. Pricing tier names (these are OK)

The Semantic Edge Case

The Replacement Framework

The Pre-Publish Gate

What's Your Trigger Word?

Detecting YouTube SPA Navigation in a Chrome Extension Content Script

The Problem with window.location

MutationObserver on document.body

The Loop Replay Implementation

Why Not scripting.executeScript?

Lessons

I Built a Price History Tracker for Japan's 4 Major E-Commerce Sites (Amazon.co.jp, Rakuten, Yahoo!, Mercari)

The four-site parsing problem

Why one parser runs in two contexts

Storing price history without external dependencies

Price drop alerts

What it is

I Built a Chrome Extension That Catches Japanese Ad Law Violations in Real Time

What AdLegalCheck Does

The Technical Stack

The Keyword Database

Content Script: Highlighting Without Breaking the Page

AI Analysis via Vercel Proxy

Risk Score Calculation

Freemium Design

Who Is This For?

What is Next

I Built a Chrome Extension That Remembers Where You Stopped Reading

The Core Problem: Scroll Position Is Not a URL

Challenge 1: Restoration Timing

Challenge 2: SPA Navigation Detection

Challenge 3: Auto-Save Without Spamming Storage

Challenge 4: Storage Key Normalization

UX Decision: When to Show the Restore Banner

Try ReadMark

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

The Problem with `window.location`

MutationObserver on `document.body`

Why Not `scripting.executeScript`?

The `cookies` API in MV3

The `httpOnly` Problem