Forem: SHOTA

I Built a Chrome Extension That Transfers Data Between Web Pages Visually

SHOTA — Thu, 16 Apr 2026 01:31:56 +0000

Here is a workflow I used to do ten times a day: open a CRM page, find a customer's name, address, and email, switch to an invoice generator, type all three fields manually. Or: open a spreadsheet export in the browser, copy a cell value, switch to an admin panel form, paste it, go back, copy the next cell, switch again, paste again. Repeat for every row.

The data already exists on one page. I just need it on another page. But browsers do not have a built-in way to move data between tabs. Copy-paste is the only tool, and it handles one field at a time.

So I built DataBridge -- a Chrome extension that lets you visually select elements on a source page, visually select target fields on a destination page, and transfer all the data with one click. You click elements, they get numbered badges, and the numbers tell the extension which source maps to which target. Then you hit transfer and everything fills in.

The Mental Model: Numbered Badges

The core UX concept is borrowed from screen recording tools that annotate click targets. When you enter selection mode on a source page, every element you click gets a numbered badge: 1, 2, 3. Then you switch to the target page, enter selection mode there, and click the target fields in the same order. Source element 1 maps to target element 1, source 2 to target 2, and so on.

This is more intuitive than building a mapping table with CSS selectors. Users do not need to know anything about the DOM. They just click what they see.

The content script manages the visual state:

let isSelectionMode = false;
let currentMode: SelectionMode = null;
let selectedElements = new Map<number, Element>();
let elementToIndex = new Map<Element, number>();
let nextIndex = 1;

function selectElement(element: Element): void {
  const index = nextIndex++;
  selectedElements.set(index, element);
  elementToIndex.set(element, index);

  addHighlight(element, index);

  const selectorResult = generateSelector(element);
  const value = getElementValue(element);
  const label = findNearbyLabel(element);

  chrome.runtime.sendMessage({
    type: 'ELEMENT_SELECTED',
    data: {
      index,
      selector: selectorResult.primary,
      fallbackSelectors: selectorResult.fallbacks,
      value,
      tagName: element.tagName.toLowerCase(),
      label,
    },
  });
}

Two maps maintain the bidirectional relationship between elements and their indices. This enables both lookup directions: given an index, find the element (for data transfer); given an element, find its index (for deselection on second click). The deselection triggers a reindex operation that renumbers all remaining elements sequentially, so there are never gaps in the numbering.

CSS Selector Generation: The Hard Problem

When the user clicks an element on the source page, DataBridge needs to generate a CSS selector that can reliably find the same element later -- even after a page refresh. This is harder than it sounds.

The naive approach -- using the element's class names -- breaks on any site that uses CSS Modules, styled-components, or Tailwind's JIT mode. The class text-display--3jedW or css-1abc2de will change on the next build.

DataBridge uses a multi-strategy selector generator that detects and avoids unstable class names:

function isUnstableClass(className: string): boolean {
  // State classes and framework-specific classes
  if (/^(active|selected|hover|focus|ng-|v-|react-|dt-|css-|sc-|emotion-)/.test(className)) {
    return true;
  }
  // CSS Modules hash suffix (e.g., text-display--3jedW)
  if (/--[a-zA-Z0-9]{3,}$/.test(className)) {
    return true;
  }
  // Styled-components / Emotion hash classes
  if (/^(css|sc|emotion)-[a-zA-Z0-9]+$/.test(className)) {
    return true;
  }
  return false;
}

When all class names are unstable, the generator falls back to structural selectors: nth-child paths anchored to the nearest ancestor with a stable ID. The algorithm walks up the DOM tree looking for an element with an ID, then builds a path back down using nth-child indices. This is less readable but more reliable.

Every selector is generated with a confidence score. The primary selector (the most specific one) is used first, but fallback selectors are generated too. During data transfer, if the primary selector fails, the system tries each fallback in order:

for (const { index, selector, fallbackSelectors } of selectors) {
  let element = document.querySelector(selector);

  if (!element && fallbackSelectors?.length > 0) {
    for (const fallback of fallbackSelectors) {
      try {
        element = document.querySelector(fallback);
        if (element) break;
      } catch { /* invalid selector */ }
    }
  }
}

This fallback chain means that even if the page structure changes slightly between selection and transfer (which happens on dynamic SPAs), the data usually lands in the right place.

Setting Values: Framework-Aware Input

Finding the target element is only half the problem. Setting its value needs to work with React, Angular, Vue, and plain HTML. Just setting element.value is not enough -- React maintains its own internal state and ignores direct DOM mutations.

The solution is to dispatch synthetic events after setting the value:

function setElementValue(element: Element, value: string): void {
  const tag = element.tagName.toLowerCase();

  if (tag === 'input') {
    const input = element as HTMLInputElement;
    if (input.type === 'checkbox' || input.type === 'radio') {
      input.checked = value === 'true';
    } else {
      input.value = value;
    }
    input.dispatchEvent(new Event('input', { bubbles: true }));
    input.dispatchEvent(new Event('change', { bubbles: true }));
  } else if (tag === 'textarea') {
    const textarea = element as HTMLTextAreaElement;
    textarea.value = value;
    textarea.dispatchEvent(new Event('input', { bubbles: true }));
    textarea.dispatchEvent(new Event('change', { bubbles: true }));
  } else if (tag === 'select') {
    const select = element as HTMLSelectElement;
    select.value = value;
    select.dispatchEvent(new Event('change', { bubbles: true }));
  }
}

Both input and change events are dispatched with bubbles: true. React's synthetic event system listens for bubbled events at the root, so the bubbles flag is essential. Without it, React controlled components silently reject the value change.

Select elements only need the change event -- they do not fire input events in normal browser behavior, and dispatching one could confuse framework event handlers.

For elements that are not standard form controls -- like contentEditable divs used by rich text editors -- we fall back to setting textContent directly. This works for simple cases but will not trigger framework reactivity in all editors. It is an honest limitation.

Template System: Save and Reuse Mappings

The badge-based selection is fast for one-time transfers, but many data transfer tasks are repetitive. You move data from the same type of source page to the same type of target page, day after day.

DataBridge lets you save a mapping as a template:

interface Template {
  id: string;
  name: string;
  sourceUrlPattern: string;
  targetUrlPattern: string;
  sourceTitle?: string;
  targetTitle?: string;
  mappings: Array<{
    sourceSelector: string;
    targetSelector: string;
    label?: string;
    savedValue?: string;
  }>;
  createdAt: string;
  updatedAt: string;
}

Templates store URL patterns (not exact URLs) for source and target pages, so they match across different records on the same site. When you load a template, the extension highlights the matched source and target elements on the current pages, so you can verify the mapping before executing the transfer.

The savedValue field is a fallback mechanism. Some source pages load data dynamically, and the element might be empty at the moment the transfer executes. By storing the value captured at template creation time, the user has the option to transfer saved values when live values are unavailable.

The Side Panel Architecture

DataBridge uses Chrome's Side Panel API for its main interface. The side panel contains the mode switcher (source/target), the list of selected elements, template management, and the transfer button. The choice of side panel over popup is intentional -- the user needs to interact with the web page and the extension simultaneously.

The architecture follows a message-passing pattern:

Side panel sends commands to the background service worker
Background routes commands to the appropriate content script (source tab or target tab)
Content script executes DOM operations and sends results back
Background forwards results to the side panel for display

This three-layer architecture handles the cross-tab requirement. The source page and target page are in different tabs, each with their own content script instance. The background service worker knows which tab is which and routes messages accordingly.

// Background service worker routes messages to the correct tab
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  switch (message.type) {
    case 'EXECUTE_TRANSFER':
      executeTransfer(); // Reads from source tab, writes to target tab
      break;
    case 'ELEMENT_SELECTED':
      // Forward to side panel for display
      updateSidePanel(message.data);
      break;
  }
});

Smart Label Detection

When an element is selected, DataBridge tries to find a human-readable label for it. This is displayed in the side panel so users can verify their selections without memorizing index numbers.

The label detection walks through several strategies:

function findNearbyLabel(element: Element): string | undefined {
  // 1. Explicit <label for="...">
  const id = element.id;
  if (id) {
    const label = document.querySelector(`label[for="${CSS.escape(id)}"]`);
    if (label) return label.textContent?.trim();
  }

  // 2. Wrapping <label>
  const parent = element.closest('label');
  if (parent) return parent.textContent?.trim();

  // 3. Adjacent <label>
  const prev = element.previousElementSibling;
  if (prev?.tagName.toLowerCase() === 'label') {
    return prev.textContent?.trim();
  }

  return undefined;
}

The CSS.escape() call on the ID is a subtle but important detail. Some sites use IDs with characters that are valid in HTML but invalid in CSS selectors (like colons or dots). Without escaping, querySelector would fail or match the wrong element.

The Notepad Mode

Not all data transfer starts from a structured web page. Sometimes you have data in your head, in a text file, or in a chat message. For these cases, DataBridge includes a notepad mode -- a plain text area where you can type or paste values, one per line, and transfer them to form fields on a target page.

interface NotepadData {
  content: string;           // Newline-separated values
  sourceTabId: number | null;
  sourceElements: SelectedElement[];
}

Each line in the notepad maps to a target field by position. Line 1 goes to target element 1, line 2 to target element 2, and so on. The notepad can also be saved as a template with isNotepad: true, creating reusable fill-in templates for forms you fill out frequently.

Technical Challenges and Solutions

Handling iframes. The content script runs in all frames ("all_frames": true in the manifest), but element selection is restricted to the top frame. Cross-frame CSS selectors are not a thing -- a selector generated in an iframe would be meaningless in the top frame. This is a practical limitation: forms inside iframes cannot be targeted. Most modern sites avoid iframes for form content, so this rarely matters in practice.

React's controlled components. Setting input.value directly does not update React state. React listens for the native input event fired by the browser, but only if the event follows the internal event pipeline. Dispatching a synthetic input event with bubbles: true tricks React into processing the new value. This works with React 16+, but there are edge cases with React 19's concurrent features where event ordering can differ. In testing, the approach has been reliable.

Element reindexing on deselection. When the user deselects element 2 out of [1, 2, 3], the remaining elements need to become [1, 2]. The reindex operation clears both maps, iterates over the remaining elements in order, and rebuilds the indices from 1. It also updates the DOM badges to show the new numbers. This keeps the mapping intuitive -- source 1 always maps to target 1.

Highlight positioning. The numbered badges are positioned using position: fixed with coordinates from getBoundingClientRect(). This works well on static pages, but breaks when the page scrolls -- the badges stay in their initial viewport positions while the elements move with the scroll. A MutationObserver or scroll listener could update badge positions, but this adds complexity. The current approach works because users typically select elements that are visible and do not scroll while in selection mode.

The Tech Stack

React 18 for the side panel UI
Zustand for state management
TypeScript throughout
Tailwind CSS for styling
Vite with the CRXJS plugin for hot-reload during development
webextension-polyfill for cross-browser compatibility (future-proofing for Firefox/Edge ports)

The CRXJS Vite plugin deserves a mention. It makes Chrome extension development feel like regular web development -- hot module replacement works in the side panel, and manifest changes are picked up automatically. The @crxjs/vite-plugin handles the complex build output required by Manifest V3.

Try It Out

If you regularly copy data between web pages -- filling invoices from CRMs, transferring spreadsheet data to admin panels, populating forms from other forms -- DataBridge eliminates the repetitive copy-paste cycle. Select your source elements, select your target fields, and transfer. Save templates for workflows you repeat.

DataBridge - Copy & Transfer Data Between Web Pages - Chrome Web Store

Copy and transfer data between web pages easily. Select fields, save reusable templates, and automate repetitive data entry.

chromewebstore.google.com

Other tools I've built:

Web Scraper & Data Extractor — DataPick - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

SEO Analyzer & Meta Tag Checker — OnPageX - Chrome Web Store

Analyze meta tags, headings, schema markup, images & links in one click. Get SEO scores, find issues & export reports. Free forever.

chromewebstore.google.com

I Built a One-Click SEO Analyzer Chrome Extension with Scoring, Schema Detection, and SERP Preview

SHOTA — Thu, 16 Apr 2026 00:00:00 +0000

Every time I published a new page, I would open the browser DevTools, dig through the <head> section, manually check if I had a title, meta description, canonical URL, Open Graph tags, Twitter Card tags, structured data, and proper heading hierarchy. Then I would check the images for alt attributes. Then the links. Every. Single. Time.

I wanted a tool that would do all of this in one click and give me a score. Not a cloud-based crawler that takes minutes. Not a SaaS dashboard that requires a login. Just a Chrome extension that instantly analyzes the page I am looking at and tells me what is good, what is missing, and what needs fixing.

So I built OnPageX, a Chrome extension that extracts every SEO-relevant signal from the current page, scores it on a 0-100 scale, and presents the results in a clean tabbed interface. It covers meta tags, Open Graph, Twitter Cards, heading structure, structured data (JSON-LD), image alt attributes, link analysis, and more.

The Tech Stack

OnPageX is built with the WXT framework, React 19, TypeScript, and Tailwind CSS. WXT is a modern Chrome extension framework that provides a development experience similar to Next.js -- file-based entrypoints, hot module replacement, TypeScript out of the box, and a clean build pipeline. If you are starting a new extension in 2026, I would strongly recommend it over manual Vite or Webpack configurations.

The project structure follows WXT conventions:

src/
  entrypoints/
    background.ts       # Service worker
    popup/
      App.tsx           # Main popup UI
      main.tsx          # Entry point
  components/
    MetaOverview.tsx    # Meta tags + score
    HeadingTree.tsx     # Heading hierarchy
    SchemaViewer.tsx    # JSON-LD viewer
    LinkAnalysis.tsx    # Internal/external links
    ImageAudit.tsx      # Image alt check
    SerpPreview.tsx     # SERP preview (Pro)
    CompareView.tsx     # Page comparison (Pro)
  lib/
    extractor.ts        # SEO data extraction
    scoring.ts          # Scoring engine
    types.ts            # TypeScript types
    export-pdf.ts       # PDF export
    export-csv.ts       # CSV export
  hooks/
    useAnalysis.ts      # Main analysis hook

The Extractor: Pulling SEO Data from the DOM

The heart of the extension is the extractSeoData() function. It runs in the context of the page (via chrome.scripting.executeScript) and extracts every piece of SEO-relevant information from the document.

Here is the core extraction logic:

export function extractSeoData(): SeoData {
  const doc = document;

  const meta = (name: string): string => {
    const el = doc.querySelector<HTMLMetaElement>(
      `meta[name="${name}"]`
    ) ?? doc.querySelector<HTMLMetaElement>(
      `meta[name="${name}" i]`
    );
    return el?.content?.trim() ?? '';
  };

  const metaProp = (prop: string): string => {
    const el = doc.querySelector<HTMLMetaElement>(
      `meta[property="${prop}"]`
    );
    return el?.content?.trim() ?? '';
  };

  const title = doc.title?.trim() ?? '';
  const metaDescription = meta('description');
  const canonical =
    (doc.querySelector('link[rel="canonical"]')
      as HTMLLinkElement)?.href ?? '';
  const robots = meta('robots');

  // ... Open Graph, Twitter, headings, schema,
  //     images, links extraction
  return { url, title, metaDescription, canonical,
           robots, hreflang, og, twitter,
           headings, schemas, images, links };
}

A key design decision: this function is a pure function with zero external imports. That is because chrome.scripting.executeScript can only run functions that are self-contained -- you cannot import modules inside an injected function. Everything the extractor needs is defined inline.

Meta Tag Extraction

The extractor checks both name and property attributes because different standards use different conventions. Standard meta tags like description and robots use name, while Open Graph tags use property:

<!-- name-based -->
<meta name="description" content="..." />
<meta name="robots" content="index, follow" />

<!-- property-based -->
<meta property="og:title" content="..." />
<meta property="og:image" content="..." />

The Twitter Card specification is particularly inconsistent -- some implementations use name, others use property. The extractor checks both:

const twitter: TwitterData = {
  card: meta('twitter:card') || metaProp('twitter:card'),
  title: meta('twitter:title') || metaProp('twitter:title'),
  description: meta('twitter:description')
    || metaProp('twitter:description'),
  image: meta('twitter:image') || metaProp('twitter:image'),
  site: meta('twitter:site') || metaProp('twitter:site'),
};

Heading Hierarchy

The extension collects all headings (H1 through H6) with their level and text content:

const headings: HeadingEntry[] = Array.from(
  doc.querySelectorAll('h1,h2,h3,h4,h5,h6'),
).map((el) => ({
  level: parseInt(el.tagName[1], 10),
  text: (el.textContent ?? '').trim().slice(0, 200),
}));

The heading tree component renders these as a nested outline, making it easy to spot structural issues like multiple H1 tags, skipped heading levels, or headings that are too long.

Structured Data Detection

JSON-LD structured data is extracted from <script type="application/ld+json"> elements. The extractor parses the JSON to identify the schema type:

const schemas: SchemaEntry[] = Array.from(
  doc.querySelectorAll(
    'script[type="application/ld+json"]'
  ),
).map((el) => {
  const raw = el.textContent ?? '';
  let type = '(unknown)';
  try {
    const parsed = JSON.parse(raw);
    type = parsed['@type']
      ?? parsed?.['@graph']?.[0]?.['@type']
      ?? '(unknown)';
  } catch { /* ignore malformed JSON-LD */ }
  return { type, raw };
});

It handles both flat schemas (with a top-level @type) and graph-based schemas (where the schema is nested inside an @graph array, as commonly generated by Yoast SEO and similar WordPress plugins).

Image Audit

Every <img> element is checked for its alt attribute, dimensions, and source URL:

const images: ImageEntry[] = Array.from(
  doc.querySelectorAll<HTMLImageElement>('img'),
).map((el) => ({
  src: el.src || el.dataset.src || '',
  alt: el.alt ?? '',
  width: el.getAttribute('width') ?? '',
  height: el.getAttribute('height') ?? '',
}));

The el.dataset.src fallback catches lazy-loaded images that store the real URL in a data attribute. Missing alt text and missing explicit dimensions are both flagged in the UI.

Link Analysis

Links are categorized as internal or external by comparing their origin to the page's origin:

const links: LinkEntry[] = Array.from(
  doc.querySelectorAll<HTMLAnchorElement>('a[href]'),
).map((el) => {
  let isExternal = false;
  try {
    isExternal = new URL(el.href).origin !== origin;
  } catch { /* relative URL */ }
  return {
    href: el.href,
    text: (el.textContent ?? '').trim().slice(0, 120),
    rel: el.rel ?? '',
    isExternal,
  };
});

The try/catch handles relative URLs that would throw when passed to new URL(). The link analysis view shows internal vs. external link counts, identifies links with nofollow attributes, and flags any broken or empty href values.

The Scoring Engine

Once the data is extracted, it goes through a scoring engine that evaluates nine SEO factors and produces an overall score from 0 to 100.

Each factor is evaluated as "good," "warning," or "critical":

function level(
  ok: boolean, warn: boolean
): ScoreLevel {
  if (ok) return 'good';
  if (warn) return 'warning';
  return 'critical';
}

Here is how the title is scored, for example:

const tLen = data.title.length;
items.push({
  label: 'Title',
  value: tLen > 0 ? `${tLen} chars` : 'Missing',
  level: level(
    tLen >= 30 && tLen <= 60,
    tLen > 0 && tLen < 70
  ),
  tip: tLen === 0
    ? 'Add a <title> tag'
    : tLen < 30
      ? 'Title is too short (aim for 30-60 chars)'
      : tLen > 60
        ? 'Title may be truncated in SERPs (>60 chars)'
        : 'Good title length',
});

The nine scoring factors are:

Title -- Should exist, ideally 30-60 characters.
Meta Description -- Should exist, ideally 120-160 characters.
H1 -- Exactly one H1 heading should be present.
Open Graph -- og:title, og:description, and og:image should all be set.
Canonical URL -- Should be defined to prevent duplicate content issues.
Image Alt Attributes -- All images should have alt text.
Structured Data -- At least one JSON-LD schema should be present.
Twitter Card -- twitter:card and twitter:title should be set.
Robots Directive -- Should not contain noindex (unless intentional).

The overall score is calculated as a weighted average:

const goodCount = items.filter(
  (i) => i.level === 'good'
).length;
const warnCount = items.filter(
  (i) => i.level === 'warning'
).length;
const overall = Math.round(
  ((goodCount * 1 + warnCount * 0.5) / items.length) * 100,
);

Good items contribute 1.0, warnings contribute 0.5, and critical items contribute 0. A page with all nine factors in good standing scores 100. A page with all warnings scores 50. This gives a quick at-a-glance reading of the page's SEO health.

The Type System

The TypeScript types define the contract between the extractor and the rest of the application:

export interface SeoData {
  url: string;
  title: string;
  metaDescription: string;
  canonical: string;
  robots: string;
  hreflang: HreflangEntry[];
  og: OgData;
  twitter: TwitterData;
  headings: HeadingEntry[];
  schemas: SchemaEntry[];
  images: ImageEntry[];
  links: LinkEntry[];
}

export interface ScoreResult {
  overall: number;
  items: ScoreItem[];
}

export interface ScoreItem {
  label: string;
  value: string;
  level: 'good' | 'warning' | 'critical';
  tip: string;
}

Having a strict SeoData interface means the extractor and the scorer are always in sync. If I add a new extraction field, TypeScript forces me to handle it everywhere it is consumed.

The Popup UI: React with Tabs

The popup is a React application rendered in the extension's popup window. It uses a tabbed interface with six sections: Overview, Headings, Schema, Links, Images, and Pro.

export default function App() {
  const [tab, setTab] = useState<TabKey>('overview');
  const { data, score, loading, error, analyze } =
    useAnalysis();
  const { t } = useI18n();

  return (
    <div className="flex flex-col h-full">
      <TabNavigation active={tab} onChange={setTab} />
      <div className="flex-1 overflow-y-auto">
        {tab === 'overview' &&
          <MetaOverview data={data} score={score} />}
        {tab === 'headings' &&
          <HeadingTree headings={data.headings} />}
        {tab === 'schema' &&
          <SchemaViewer schemas={data.schemas} />}
        {tab === 'links' &&
          <LinkAnalysis links={data.links} />}
        {tab === 'images' &&
          <ImageAudit images={data.images} />}
        {tab === 'pro' &&
          <ProPanel data={data} score={score} />}
      </div>
    </div>
  );
}

The useAnalysis hook manages the lifecycle: it triggers chrome.scripting.executeScript with the extraction function, receives the raw data, passes it through the scoring engine, and exposes the results to the UI. All of this happens when the popup opens, typically completing in under 100ms.

Internationalization: Eight Languages

OnPageX supports eight languages: English, Japanese, Korean, Spanish, French, German, Italian, and Portuguese. The i18n system uses Chrome's built-in _locales mechanism for the extension name and description, plus a custom translation layer for the popup UI.

This was an important decision for reach. SEO is a global concern, and making the extension accessible to non-English speakers significantly expanded the potential user base.

Pro Features

The free tier covers everything described above -- full analysis with scoring across all nine factors, heading tree, schema viewer, link analysis, and image audit.

The Pro tier (powered by ExtensionPay) adds:

SERP Preview: Shows how the page would appear in Google search results, with title truncation preview and meta description length visualization.
Page Comparison: Fetch and analyze a competitor's page side-by-side with yours, with a diff view highlighting differences.
Bulk Analysis: Analyze multiple URLs from a list and export the results.
Analysis History: Track SEO scores over time with timestamped snapshots.
PDF and CSV Export: Generate reports for clients or stakeholders.

The comparison feature is particularly interesting technically. It fetches the competitor's page HTML via a background script (to avoid CORS restrictions), parses it into a Document using DOMParser, and runs the same extraction function on it:

export function extractFromDocument(
  doc: Document, baseUrl: string
): SeoData {
  let origin = '';
  try {
    origin = new URL(baseUrl).origin;
  } catch {}

  const meta = (name: string): string => {
    const el = doc.querySelector<HTMLMetaElement>(
      `meta[name="${name}"]`
    );
    return el?.content?.trim() ?? '';
  };

  // ... same extraction logic, operating on
  // the fetched document instead of the live page
}

Having an extractFromDocument variant that takes a Document parameter (instead of using the global document) makes the extraction logic reusable for both live pages and fetched HTML.

Export: PDF and CSV

The export system uses jsPDF with the jspdf-autotable plugin for PDF generation and a custom CSV builder for spreadsheet export.

The PDF export creates a formatted report with the site URL, timestamp, overall score, and a table of all scoring items with their values and recommendations. This is useful for SEO auditors who need to deliver reports to clients.

The CSV export produces a flat table that can be opened in Excel or Google Sheets for further analysis, filtering, and comparison across multiple pages.

Why WXT?

I initially considered building this with a raw Vite setup and the CRXJS plugin, which is what I used for some of my other extensions. But WXT offered several advantages:

File-based entrypoints. Drop a file in src/entrypoints/ and WXT automatically generates the manifest entry for it. No manual manifest configuration.
React module. The @wxt-dev/module-react package handles React integration with no boilerplate.
Built-in browser targeting. wxt build --browser firefox produces a Firefox-compatible build from the same source code.
Dev server with HMR. The popup reloads when you save a file. This is a huge productivity boost when iterating on UI.
TypeScript by default. Path aliases, type checking, and module resolution just work out of the box.

Lessons Learned

chrome.scripting.executeScript has constraints. The injected function must be self-contained. No imports, no closures over external variables. This forced me to write the extractor as a pure function, which turned out to be a good architectural decision since it made the code easy to test and reuse.
Meta tag conventions are inconsistent. Some sites use name, others use property, and some use both. Always checking both is the safe approach. Case-insensitive matching (the i flag in the CSS selector) catches sites that use Name or DESCRIPTION.
SERP character limits are guidelines, not rules. Google truncates titles at different lengths depending on pixel width, not character count. The 60-character title guideline and 160-character description guideline are approximations. The scoring reflects this by using ranges rather than hard cutoffs.
Structured data is messier than you expect. Some sites have malformed JSON-LD that fails parsing. Some use @graph arrays. Some embed multiple schemas. The extractor needs to handle all these cases gracefully without crashing.
Eight-language support multiplied the maintenance burden. Every new feature or changed message requires updating eight translation files. I considered using machine translation but found that SEO-specific terminology needs careful human review. Incorrect translations for technical terms would undermine credibility.

If you do SEO work -- whether for your own sites or for clients -- and you want instant page-level analysis without leaving your browser, give OnPageX a try.

SEO Analyzer & Meta Tag Checker — OnPageX - Chrome Web Store

Analyze meta tags, headings, schema markup, images & links in one click. Get SEO scores, find issues & export reports. Free forever.

chromewebstore.google.com

Other tools I've built:

Web Scraper & Data Extractor — DataPick - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

Font Finder & Japanese Font Detector — JFF - Chrome Web Store

Detect and identify fonts on any webpage, including 150+ Japanese fonts. Supports Google Fonts, Adobe Fonts, and TypeSquare.

chromewebstore.google.com

How to Take Notes on Any Web Page — Free Chrome Extension

SHOTA — Tue, 14 Apr 2026 00:00:00 +0000

More Chrome Extensions from S-Hub

If you found this useful, check out my other free tools at dev-tools-hub.xyz — 20+ Chrome extensions for developers, writers, and productivity nerds. No signup, no tracking.

I Built a Chrome Extension That Automatically Creates Step-by-Step Guides from Your Browser Actions

SHOTA — Sun, 12 Apr 2026 00:00:00 +0000

Documentation is the thing everyone agrees is important and nobody wants to write. Especially step-by-step guides. You know the type -- those internal wiki pages that show new team members how to configure the CI pipeline, or the customer support articles that walk users through a multi-step process with screenshots at every turn.

Writing these guides by hand is miserable. You do the task. You take a screenshot. You crop it. You write a description. You do the next step. You take another screenshot. You crop it. You write another description. The process of documenting the process takes five times longer than the process itself.

So I built Procshot (short for Procedure Shot) -- a Chrome extension that records your browser actions and automatically generates a step-by-step guide with annotated screenshots. You click "Record," do the thing, click "Stop," and you have a guide ready to export as HTML, Markdown, or PDF.

How It Works: Action Capture Pipeline

The extension has three main pieces: a content script that detects user actions, a background service worker that captures screenshots, and a popup UI for managing recordings and guides.

When recording starts, the content script attaches event listeners to the page:

type ActionType =
  | "click"
  | "input"
  | "select"
  | "navigation"
  | "scroll"
  | "keypress"
  | "start";

Each action type maps to a different user interaction. Clicks on buttons and links, text input into fields, dropdown selections, page navigations, scroll events, and keypress events are all captured. The "start" action is a special initial capture that screenshots the starting state before any interaction.

For each action, the content script analyzes the target DOM element and sends the information to the background service worker:

interface UserActionPayload {
  actionType: ActionType;
  elementInfo: ElementInfo;
  url: string;
  pageTitle: string;
  timestamp: number;
  elementRect?: ElementRect;
  viewportSize?: ViewportSize;
  preScreenshot?: string;
}

The preScreenshot field handles a tricky timing problem. When a user clicks a link that triggers navigation, the screenshot needs to capture the page before the navigation happens, not after. The content script captures a screenshot immediately on click and sends it along with the action payload, so the background service worker has the before-state even if the page has already navigated by the time it processes the event.

DOM Analysis: Turning Raw Clicks into Readable Descriptions

The hardest engineering challenge was generating meaningful step descriptions from raw DOM events. When a user clicks a <div class="css-1abc2de">Submit</div>, the guide should say "Click the Submit button," not "Click the div element."

The DOM analyzer resolves raw click targets up and down the DOM tree:

function resolveActionTarget(rawEl: Element): Element {
  // 1. Walk UP to find an interactive ancestor
  const ancestor = findInteractiveAncestor(rawEl);
  if (ancestor) return ancestor;

  // 2. If raw element is generic, walk DOWN for meaningful child
  const tag = rawEl.tagName.toLowerCase();
  if (GENERIC_TAGS.has(tag)) {
    const directText = getDirectText(rawEl);
    if (directText.length > 0 && directText.length <= 60) {
      return rawEl;
    }
    const child = findMeaningfulChild(rawEl);
    if (child) return child;
  }

  return rawEl;
}

This two-direction resolution is essential. Consider this common HTML pattern:

<button class="submit-btn">
  <svg>...</svg>
  <span>Submit Order</span>
</button>

If the user clicks the SVG icon inside the button, the raw event target is the <svg>. Walking UP finds the <button> ancestor, which is the semantically meaningful element. Conversely, if the user clicks a large <div> container, walking DOWN finds the first button, link, or heading inside it.

The label extraction uses a priority chain: aria-label, then aria-labelledby reference, then <label for="...">, then placeholder text, then the title attribute, and finally clean text content. For links, there is special handling that checks inner image alt text, SVG title elements, and even derives readable text from the URL path as a last resort.

Noise filtering is critical. Modern pages are full of icon fonts and CSS ligature names -- elements whose "text content" is open_in_new or chevron_right or arrow_forward. The analyzer strips these out:

const NOISE_TEXT_PATTERNS = [
  /^(open_in_new|close|menu|search|arrow_\w+|chevron_\w+|expand_\w+|navigate_\w+|more_\w+|add|remove|delete|edit|star|favorite|share|thumb_up|visibility|check|check_circle)$/i,
  /^\d+$/,
];

The result is that <button><span class="material-icons">close</span> Cancel</button> produces the label "Cancel" rather than "close Cancel" or just "close."

Multilingual Step Descriptions: 8 Languages from One Action

Every step description is generated in the user's language. Procshot supports Japanese, English, Spanish, Portuguese, French, German, Korean, and Simplified Chinese. The step generator uses template functions for each action type and language combination:

// Click -- button with label
const clickButtonLabel: Record<StepLang, (label: string) => string> = {
  ja: (l) => `${l}ボタンをクリックします`,
  en: (l) => `Click the ${l} button`,
  es: (l) => `Haz clic en el boton ${l}`,
  fr: (l) => `Cliquez sur le bouton ${l}`,
  de: (l) => `Klicken Sie auf die Schaltflache ${l}`,
  ko: (l) => `${l} 버튼을 클릭합니다`,
  zh_CN: (l) => `点击${l}按钮`,
  pt_BR: (l) => `Clique no botao ${l}`,
};

There are templates for every combination of action type and context: click with label, click without label, link clicks, checkbox toggles, input fields with different types (email, password, search, phone), dropdown selections, navigation events, scroll directions, and generic clicks on unknown elements.

The quoting function adapts to language conventions -- Japanese uses corner brackets, while Western languages use straight double quotes:

function q(lang: StepLang, label: string): string {
  switch (lang) {
    case "ja": return `「${label}」`;
    case "ko": return `"${label}"`;
    default: return `"${label}"`;
  }
}

This attention to typographic detail makes the generated guides look polished in every language, not like machine-translated English.

Screenshot Capture and Storage with IndexedDB

Each step includes a full-page screenshot captured at the moment of the action. The background service worker uses chrome.tabs.captureVisibleTab() to take the screenshot, then stores it as a Blob in IndexedDB.

interface ProcshotDB extends DBSchema {
  guides: {
    key: string;
    value: GuideData;
    indexes: { "by-date": number };
  };
  screenshots: {
    key: string;
    value: Blob;
  };
}

Why IndexedDB instead of chrome.storage.local? Size. A single screenshot at full resolution is typically 200-500KB as a PNG. A guide with 15 steps means 3-7.5MB of image data. Chrome's storage API was not designed for this volume of binary data -- it serializes everything to JSON, which doubles the size for binary blobs. IndexedDB stores Blobs natively and handles large datasets efficiently.

The guide metadata (steps, descriptions, timestamps) lives in the guides object store, while the actual screenshot Blobs are in a separate screenshots store. This separation means listing all guides is fast -- you only load the metadata, not the images.

Annotations: Highlight, Arrow, Text, and Blur

Raw screenshots are informative, but annotated screenshots are instructive. Procshot includes annotation tools that let you mark up screenshots after recording:

type AnnotationType = "highlight" | "arrow" | "text" | "blur";

interface Annotation {
  id: string;
  type: AnnotationType;
  startX: number;  // Relative coordinates (0-1)
  startY: number;
  endX: number;
  endY: number;
  text?: string;
  color: string;
  strokeWidth: number;
}

Annotations are stored as relative coordinates (0 to 1 range) rather than pixel values. This makes them resolution-independent -- if the guide is exported at a different resolution or the screenshot is resized, the annotations scale correctly.

The rendering uses Canvas 2D:

function renderAnnotations(
  ctx: CanvasRenderingContext2D,
  width: number,
  height: number,
  annotations: Annotation[]
): void {
  for (const ann of annotations) {
    const x1 = ann.startX * width;
    const y1 = ann.startY * height;
    const x2 = ann.endX * width;
    const y2 = ann.endY * height;

    switch (ann.type) {
      case "highlight":
        drawHighlight(ctx, x1, y1, x2 - x1, y2 - y1, ann.color, ann.strokeWidth);
        break;
      case "arrow":
        drawArrow(ctx, x1, y1, x2, y2, ann.color, ann.strokeWidth);
        break;
      case "text":
        drawText(ctx, x1, y1, ann.text ?? "", ann.color, width);
        break;
      case "blur":
        applyBlur(ctx, x1, y1, x2 - x1, y2 - y1);
        break;
    }
  }
}

The blur annotation is particularly useful for documentation that will be shared externally -- it lets you hide sensitive information (emails, account numbers, personal data) directly in the screenshot without post-processing in an image editor.

Auto-highlighting is also built in. Since the content script captures the bounding rectangle of the clicked element (elementRect and viewportSize), the guide viewer can automatically draw a highlight box around the action target on each screenshot. Users see exactly where to click without any manual annotation.

Export Formats: HTML, Markdown, and PDF

A guide is only useful if it can be shared. Procshot exports to three formats:

HTML generates a self-contained HTML file with inline CSS and base64-encoded images. No external dependencies. You can drop it into a wiki, attach it to an email, or host it on any static file server. The exported HTML includes step numbers, descriptions, and annotated screenshots in a clean, printable layout.

Markdown produces a .md file with image references. This is ideal for developers who want to drop guides into GitHub repos, Confluence pages, or static site generators. The images are exported as separate files referenced from the Markdown.

PDF uses html2pdf.js to render the HTML export into a PDF document. This is the most portable format for non-technical users -- customers, stakeholders, and team members who just need to follow instructions.

The PDF export is a Pro feature, along with annotations. The free tier allows up to 5 guides per month with HTML and Markdown export. This creates a natural upgrade path: users who find value in the tool for personal use can unlock professional features when they need to share polished documentation.

The Freemium Model with ExtensionPay

Procshot uses ExtensionPay for payment processing. The paywall logic runs in the background:

// Free tier: 5 guides per month
// Pro: Unlimited guides + PDF export + annotations

The free tier is generous enough to be genuinely useful. Five guides per month covers most personal documentation needs. The Pro upgrade makes sense for people who create guides regularly -- support teams, technical writers, trainers, and developers documenting processes for their teams.

The monthly guide count resets on the first of each month. When a user hits the limit, the extension shows an upgrade prompt with a clear count of remaining guides rather than a hard block. This respects the user's workflow -- they can still view and export existing guides, they just cannot start new recordings.

The Content Script: Capturing Actions Without Breaking Pages

The content script needs to intercept user actions without interfering with the page's functionality. A click on a "Submit Order" button must still submit the order -- the extension just needs to know it happened.

The approach is entirely passive. Event listeners are attached in capture phase but never call preventDefault() or stopPropagation(). The content script observes events, extracts information from the target element, sends a message to the background, and lets the event continue its normal propagation.

document.addEventListener('click', handleClick, true);  // Capture phase

Using the capture phase (the true parameter) ensures the extension sees events even on elements where the page has called stopPropagation(). This is important for SPAs that use event delegation patterns where clicks are handled at the root and never propagate normally.

For input events, the content script waits for the user to stop typing (debounced) before recording the step. Recording every keystroke would produce a guide with 50 steps just for typing a URL. The debounce captures the final value after a pause.

Navigation events are detected through the chrome.webNavigation API in the background service worker rather than through content script events. This catches both same-page navigations (History API pushes) and full page loads.

Building with React 19, Vite, and Tailwind v4

The extension is built with React 19, Vite 6, and Tailwind CSS v4. The Tailwind v4 integration uses the @tailwindcss/vite plugin, which is the new first-class Vite integration that replaces the PostCSS-based approach from v3.

TypeScript is used throughout the project. The type definitions for Chrome APIs come from @types/chrome. The idb library provides typed wrappers for IndexedDB, and jszip handles bundling multiple files for the Markdown export (images + .md file in a single .zip download).

The build pipeline has a post-build step (scripts/post-build.js) that processes the output for Chrome Web Store submission. Service workers need special bundling treatment in Manifest V3, and the post-build script ensures all paths are correct in the final output.

Technical Lessons Learned

1. Screenshot timing is everything. When a user clicks a navigation link, you need the screenshot before the page unloads. The content script pre-captures a screenshot on the click event and sends it with the action payload. If the navigation is fast (which it usually is), the chrome.tabs.captureVisibleTab() call in the background would capture the new page, not the old one. The pre-capture solves this.

2. IndexedDB in service workers has quirks. The idb library (which wraps IndexedDB with Promises) works in service workers, but you need to handle the case where the service worker terminates mid-transaction. Transactions that span an await boundary can fail silently if the worker is killed. The solution is to keep transactions short and to not await across transaction boundaries.

3. DOM analysis requires defense in depth. No single strategy works for extracting element labels. Some pages use aria-label, others use <label for>, others have text content, and others have none of the above. The priority chain in the DOM analyzer handles these cases gracefully, always falling back to the next strategy rather than returning an empty label.

4. Relative coordinates for annotations were the right call. Storing annotation positions as percentages rather than pixels means they survive resolution changes, zoom levels, and export to different formats. The math is trivial (multiply by width/height), and the flexibility is significant.

5. Blob storage in IndexedDB outperforms chrome.storage for binary data by an order of magnitude. A test with 20 screenshots showed chrome.storage taking 4-5 seconds for a round trip (serialize to base64, store, retrieve, deserialize) versus under 200ms for IndexedDB with native Blob storage. For a tool that captures screenshots on every user action, this difference is visible to the user.

Try It Out

If you have ever spent an afternoon screenshotting and annotating a step-by-step guide that could have been recorded in three minutes, Procshot is for you. Hit record, do the task, stop recording, and export. The guide writes itself.

The free tier gives you 5 guides per month with HTML and Markdown export. Pro adds unlimited guides, PDF export, and screenshot annotations with highlight boxes, arrows, text labels, and blur for sensitive data.

Procshot - Auto-Generate Step-by-Step Guides | Free Chrome Extension | S-Hub

Auto-record browser actions to create step-by-step guides with annotated screenshots. Export as PDF, Markdown, or HTML. Save 90% documentation time.

dev-tools-hub.xyz

Other tools I've built:

PageMemo – Web Page Notes

SnippetVault – Code Snippet Manager

I Built a VS Code-Style Snippet Manager That Lives in Your Browser

SHOTA — Fri, 10 Apr 2026 00:00:00 +0000

Every developer has a folder of code snippets somewhere. Maybe it is a Notion page, a GitHub Gist collection, a random .txt file on the desktop, or a pile of sticky notes in the back of your IDE. The problem is not saving snippets -- it is finding them again when you need them. And more importantly, getting them into the place where you actually write code: the browser.

I spend a lot of my coding time inside browser-based tools. GitHub PRs, CodeSandbox, StackBlitz, Jupyter notebooks, CMS editors, CI/CD config panels. Whenever I needed a snippet, the flow was always the same: switch to VS Code, open the snippets file, copy, switch back, paste. Over and over.

So I built SnippetVault -- a Chrome extension that brings VS Code-style snippet management directly into the browser, complete with syntax highlighting, slash commands, smart variables, and fuzzy search.

The Architecture: React + Zustand + Prism.js in Manifest V3

SnippetVault is built on Chrome's Manifest V3 platform. The tech stack is React 18 for the popup UI, Zustand for state management, Prism.js for syntax highlighting, and Fuse.js for fuzzy search. The build tooling is Vite with TypeScript.

The extension has three main components:

Popup UI -- The main interface where you create, edit, search, and organize snippets
Background service worker -- Handles storage operations and manages the ExtensionPay license state
Content script -- Injects the slash command handler into every page

Here is how the snippet data model looks:

interface Snippet {
  id: string;
  title: string;
  code: string;
  language: string;
  tags: string[];
  category: 'code' | 'prompt' | 'template';
  createdAt: number;
  updatedAt: number;
  isFavorite: boolean;
  isPinned: boolean;
  usageCount: number;
  lastUsedAt: number | null;
  trigger?: string;           // Slash command trigger
  variables?: SnippetVariable[];  // Smart variable definitions
  links?: string[];           // Bidirectional links to other snippets
}

Three things worth calling out here. First, the category field distinguishes between raw code snippets, AI prompts, and text templates. Developers keep all three kinds of reusable text, and mixing them together makes search results noisy. Second, the usageCount and lastUsedAt fields let the search ranking prioritize frequently-used snippets. Third, trigger is the key to the slash command system, which I will get into next.

Slash Commands: The Feature That Changed Everything

The popup works fine for browsing and organizing, but the real productivity gain comes from slash commands. Type / in any text input on any webpage, and SnippetVault shows an autocomplete popup with your snippets. Select one and it gets inserted directly.

The content script is injected at document_idle on all URLs. It listens for input events on text fields and textareas:

function handleInput(e: Event): void {
  if (isComposing) return;

  const target = e.target as HTMLInputElement | HTMLTextAreaElement;
  if (!isTextInput(target)) return;

  const value = target.value;
  const cursorPos = target.selectionStart || 0;
  const textBefore = value.substring(0, cursorPos);
  const lastSlash = textBefore.lastIndexOf('/');

  if (lastSlash >= 0) {
    const charBefore = lastSlash > 0 ? textBefore[lastSlash - 1] : ' ';
    if (charBefore === ' ' || charBefore === '\n' || lastSlash === 0) {
      const query = textBefore.substring(lastSlash + 1);

      // Don't trigger on URLs or paths
      if (query.includes('://') || query.includes('\\')) {
        hidePopup();
        return;
      }

      currentInput = target;
      triggerStart = lastSlash;
      showPopup(target, query);
      return;
    }
  }
  hidePopup();
}

There are a few subtle decisions here. The slash must appear at the start of the line or after whitespace -- this prevents false positives inside URLs, file paths, and regular text that happens to contain slashes. The isComposing check handles IME input for CJK languages, where keystrokes during composition should not trigger the popup.

The popup positions itself near the caret using getBoundingClientRect(), and for textareas it estimates the caret line by counting newlines in the text before the cursor. The popup itself is a <div> injected into the page DOM with z-index: 2147483647 -- the maximum value -- to ensure it appears above everything else on the page.

Smart Variables: Dynamic Snippet Expansion

Static snippets are useful, but real power comes when snippets can include dynamic content. SnippetVault supports built-in variables that expand at insertion time:

const BUILT_IN_VARIABLES: Record<string, () => string | Promise<string>> = {
  DATE: () => new Date().toISOString().split('T')[0],
  TIME: () => new Date().toTimeString().split(' ')[0],
  DATETIME: () => new Date().toISOString(),
  CLIPBOARD: async () => await navigator.clipboard.readText(),
  SELECTION: () => window.getSelection()?.toString() || '',
  URL: () => window.location.href,
  TITLE: () => document.title,
};

So a snippet like this:

// File: ${TITLE}
// Date: ${DATE}
// Source: ${URL}

Gets expanded to real values when inserted. The CLIPBOARD variable is particularly useful -- you can build snippets that incorporate whatever you just copied.

On top of built-in variables, there are tab-stops using VS Code syntax: ${1:placeholder}, ${2:name}. The parser handles them in two passes -- first expanding built-in variables, then locating tab-stop positions so the cursor can jump between them.

Fuzzy Search with Fuse.js

With dozens or hundreds of snippets, search performance matters. I chose Fuse.js for client-side fuzzy matching. It runs against the snippet title, tags, trigger name, and even the code body. The search results are weighted so that trigger matches rank highest, title matches come next, and code body matches are lowest priority.

The filtering happens entirely in memory since all snippets live in chrome.storage.local. For most users this is fast enough even with hundreds of snippets, since the data fits comfortably in the browser's storage quota. The unlimitedStorage permission removes the default 10MB cap.

Syntax Highlighting with Prism.js

Each snippet is displayed with proper syntax highlighting. SnippetVault supports 18 languages out of the box: JavaScript, TypeScript, Python, HTML, CSS, SQL, JSON, Markdown, Go, Rust, Java, C#, PHP, Ruby, Shell, YAML, XML, and plain text.

Prism.js was chosen over alternatives like Shiki or Highlight.js because it is lightweight (much smaller bundle size), works synchronously (no async loading of language grammars), and renders quickly in the popup where startup time matters.

Organizing Snippets: Tags, Categories, and Favorites

The UI offers multiple ways to organize your collection:

Categories: Code, Prompt, and Template -- filter by the type of content
Tags: Freeform labels attached to each snippet
Favorites: Star important snippets for quick access
Pinned: Pin your most-used snippets to the top of the list

The popup has a tab bar at the top that switches between these views. This was a deliberate UX decision -- rather than forcing users to think in folders or hierarchies, the extension lets them slice the same collection multiple ways.

One-Click Copy and Usage Tracking

The most common action is copying a snippet to the clipboard. Every snippet card has a copy button that uses the clipboardWrite permission to write to the system clipboard. The extension tracks how many times each snippet has been copied or inserted via slash commands, and the usageCount feeds back into search ranking.

This creates a virtuous cycle: the more you use a snippet, the easier it becomes to find. Over time, your most frequently needed snippets float to the top naturally.

The Hard Part: Content Script Isolation

One challenge with injecting UI into arbitrary web pages is CSS isolation. The popup that appears during slash commands needs to look consistent regardless of the host page's styles. Some sites apply aggressive global CSS resets. Others use CSS frameworks that target common class names.

The solution was to use highly specific CSS selectors prefixed with snippetvault- and sv- class names, combined with explicit property declarations that override any inherited values. The popup also supports both light and dark modes via prefers-color-scheme media queries, so it blends naturally with the user's system preference.

.snippetvault-popup {
  position: absolute;
  z-index: 2147483647;
  width: 320px;
  max-height: 320px;
  background: #1a1a1a;
  border: 1px solid #404040;
  border-radius: 8px;
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.4);
  font-family: system-ui, -apple-system, BlinkMacSystemFont,
               'Segoe UI', Roboto, sans-serif;
  font-size: 13px;
}

Every property is set explicitly -- no reliance on inheritance from the page. This is defensive CSS for hostile environments.

Freemium with ExtensionPay

SnippetVault uses a freemium model powered by ExtensionPay. The free tier gives you full snippet management. Pro unlocks advanced features. ExtensionPay handles payment processing and license verification through a content script that runs on extensionpay.com/*.

One lesson learned: always verify the payment state from the background service worker, not from the popup. The popup can be opened and closed freely, and checking license state every time it opens adds unnecessary latency. Instead, the service worker caches the license state and pushes updates to the popup when it changes.

What I Learned Building This

1. Manifest V3 service workers are not persistent. Unlike Manifest V2 background pages, service workers can be terminated at any time. All state must be persisted to chrome.storage and reloaded on activation. This affected the design of the usage tracking system -- every increment writes to storage immediately rather than batching.

2. Content scripts run in an isolated world, but share the DOM. The slash command popup is part of the page DOM but runs in the content script's JavaScript context. This means event handlers attached to popup elements work normally, but the popup must be careful not to interfere with the page's own event handling. The stopPropagation() call on click events inside the popup prevents the host page from intercepting clicks meant for snippet selection.

3. Keyboard shortcut conflicts are real. The extension registers Ctrl+Shift+S as the default shortcut to open the popup. But many websites and other extensions also use this combination. Chrome's commands API handles the conflict resolution, but users may need to change the shortcut via chrome://extensions/shortcuts.

4. The clipboard API is async and requires user gesture. navigator.clipboard.readText() needs a recent user interaction to work. When expanding the ${CLIPBOARD} variable during slash command insertion, the user has just pressed Enter or Tab to select a snippet, which counts as a user gesture. But if you try to read the clipboard during a background timer or storage change event, it will fail silently.

Try It Out

If you spend time writing code in browser-based tools -- whether it is GitHub, online IDEs, CMS platforms, or anywhere else -- SnippetVault puts your snippet library right where you need it. The slash command system means you never have to leave the page to grab a snippet.

The extension supports 18 programming languages, smart variables, fuzzy search, and one-click copy. It is free to install and use.

Install SnippetVault on Chrome Web Store

Other tools I've built:

SnapReply for Gmail - Email Templates - Chrome Web Store

Save & insert Gmail templates in one click. Canned responses, variables, rich text & shortcuts. Boost email productivity for free.

chromewebstore.google.com

PageMemo – Web Page Notes

I Built a Chrome Extension to Filter Low-Quality News on Yahoo Japan

SHOTA — Wed, 08 Apr 2026 10:00:56 +0000

If you live in Japan or read Japanese news online, you probably use Yahoo! JAPAN. It is the most visited website in the country, and its news portal aggregates stories from hundreds of sources. The problem is that a large percentage of those stories are what Japanese internet culture calls "kotatsu articles" -- low-effort content written without any original reporting, usually assembled by rewriting social media posts or celebrity gossip into clickbait headlines.

The term comes from the image of a journalist who never leaves their kotatsu (a heated table common in Japanese homes) to do actual reporting. They just sit there, scroll Twitter, and churn out articles with titles like "Fans react with shock!" or "This went viral on social media!" These articles are everywhere on Yahoo News, and they crowd out the actual journalism from NHK, Asahi Shimbun, Reuters, and other legitimate outlets.

I got tired of scrolling past them. So I built Yahoo Comfort Mode (Yahoo快適モード), a Chrome extension that filters out low-quality articles, removes ads, and gives you a cleaner browsing experience on Yahoo! JAPAN.

The Architecture: Content Script with Multiple Filter Layers

The extension is built with TypeScript, React, Vite, and the CRXJS Vite plugin for Chrome extension development. The core logic lives in a content script that runs on Yahoo! JAPAN pages and applies multiple filtering layers to each article it finds in the DOM.

Here is the main class that orchestrates everything:

class YahooKaitekiMode {
  private keywordFilter: KeywordFilter;
  private sourceFilter: SourceFilter;
  private kotatsuDetector: KotatsuDetector;
  private cleanMode: CleanMode;
  private isEnabled: boolean = true;
  private settings: Settings | null = null;

  async init(): Promise<void> {
    this.settings = await getSettings();
    this.isEnabled = this.settings.enabled;

    if (!this.isEnabled) return;

    this.configureFilters(this.settings);

    onDomReady(() => {
      this.filterPage();
      initDomObserver(() => this.filterPage());

      if (this.settings?.cleanModeEnabled) {
        this.cleanMode.setEnabled(true);
      }
    });

    this.unsubscribeSettings = onSettingsChange(
      (newSettings, oldSettings) => {
        this.handleSettingsChange(newSettings, oldSettings);
      }
    );
  }
}

The design uses four independent filter classes that each evaluate articles against different criteria. When a page loads, the content script collects all article elements, parses them, and runs each one through the filter chain.

Page-Specific DOM Selectors

Yahoo! JAPAN is not a single-page app. It is a collection of different properties -- the main portal at www.yahoo.co.jp, the news section at news.yahoo.co.jp, and the sports section at sports.yahoo.co.jp. Each has a different DOM structure for displaying articles.

The extension detects which Yahoo property the user is on and applies the appropriate selectors:

private getArticleElements(): HTMLElement[] {
  const hostname = window.location.hostname;

  if (hostname.includes('news.yahoo.co.jp')) {
    return getYahooNewsArticles();
  } else if (hostname === 'www.yahoo.co.jp') {
    return getYahooTopArticles();
  } else if (hostname.includes('sports.yahoo.co.jp')) {
    return getYahooSportsArticles();
  }

  return Array.from(
    document.querySelectorAll(
      'article, [class*="article"], [class*="news"]'
    )
  ) as HTMLElement[];
}

Each selector module knows how to find article containers, extract titles, source names, and content snippets from the specific DOM structure of that Yahoo property. The fallback at the end catches edge cases where Yahoo rolls out new page layouts.

The Kotatsu Detector: Scoring Low-Quality Articles

This is the part I am most proud of. Rather than relying on simple keyword matching, the kotatsu detector uses a multi-factor scoring system to evaluate whether an article is likely low-quality content.

Each article gets a score based on several signals:

calculateScore(
  title: string, content: string, source: string
): number {
  let score = 0;

  if (this.isKotatsuSource(source)) {
    score += this.config.sourceScore;
  }
  if (this.isGossipSource(source)) {
    score += this.config.gossipScore;
  }

  const titleMatches = this.countPatternMatches(
    title, KOTATSU_PATTERNS.titlePatterns
  );
  score += titleMatches * this.config.titlePatternScore;

  const contentMatches = this.countPatternMatches(
    content, KOTATSU_PATTERNS.contentPatterns
  );
  score += contentMatches * this.config.contentPatternScore;

  if (this.hasSocialEmbed(content)) {
    score += this.config.socialEmbedScore;
  }

  score += this.checkAdditionalPatterns(title, content);
  return score;
}

The scoring factors include:

Source reputation: Known kotatsu sources (like content aggregators that rewrite social media posts) and gossip tabloids get high base scores.
Title patterns: Regex patterns that match common clickbait formulas in Japanese, such as sensationalist brackets, viral claims, and shock-value phrases.
Content patterns: Phrases commonly found in low-effort articles, like the infamous "How was it?" (いかがでしたか) closing line that plagues Japanese web content.
Social media embeds: Articles that are mostly embedded tweets or Instagram posts with a thin wrapper of text score higher.
Clickbait indicators: Multiple exclamation marks, bracket-enclosed labels, sensationalist vocabulary.

The detector has three strength levels (low, medium, high) with different thresholds and score weights. On the "low" setting, only articles scoring 70 or above get filtered. On "high," the threshold drops to 30, catching more borderline content.

Importantly, trusted sources like NHK, major national newspapers, and international wire services are whitelisted -- they never get filtered regardless of their score.

Keyword and Source Filtering

Beyond the kotatsu detector, users can set up their own filters:

Keyword filtering uses a combination of simple string matching and TinySegmenter, a lightweight Japanese text segmentation library. Japanese text does not use spaces between words, so naive substring matching produces false positives. TinySegmenter breaks Japanese text into word-level tokens before matching, which significantly reduces incorrect matches:

shouldBlock(text: string): FilterResult {
  if (!text || this.normalizedKeywords.length === 0) {
    return { shouldFilter: false };
  }

  const normalizedText = text.toLowerCase();

  for (let i = 0; i < this.normalizedKeywords.length; i++) {
    const keyword = this.normalizedKeywords[i];

    if (normalizedText.includes(keyword)) {
      return {
        shouldFilter: true,
        reason: 'keyword',
        matchedValue: this.keywords[i],
      };
    }

    if (containsKeyword(text, this.keywords[i])) {
      return {
        shouldFilter: true,
        reason: 'keyword',
        matchedValue: this.keywords[i],
      };
    }
  }

  return { shouldFilter: false };
}

Source filtering lets users block specific news sources by name. The extension also ships with preset filter groups -- gossip magazines, inflammatory media outlets, and content aggregators -- that users can toggle on with a single click. The presets are curated lists of sources known for producing low-quality content.

Clean Mode: Ad Removal via CSS Injection

The clean mode feature removes advertisements from Yahoo! JAPAN pages using CSS injection. Rather than using an aggressive approach that might break page layout, I opted for targeted selectors that only match known ad containers:

private injectStyles(): void {
  this.styleElement = document.createElement('style');
  this.styleElement.id = 'yahoo-kaiteki-clean-mode';
  this.styleElement.textContent = `
    .yjAd,
    .yads,
    iframe[src*="yads.yjtag.yahoo.co.jp"],
    iframe[src*="doubleclick.net"],
    iframe[src*="googlesyndication"] {
      display: none !important;
    }

    .yahoo-kaiteki-ad-hidden {
      display: none !important;
    }
  `;

  document.head.appendChild(this.styleElement);
}

The selectors target Yahoo's own ad classes (yjAd, yads) and common third-party ad iframes. Each Yahoo property also has its own ad selector function that handles property-specific ad containers. The extension marks hidden elements with a data attribute so they can be restored if the user disables clean mode.

Handling Dynamic Content with MutationObserver

Yahoo! JAPAN loads content dynamically as users scroll. New articles appear in the feed without a full page reload. To catch these, the extension uses a MutationObserver that triggers the filter pipeline whenever the DOM changes:

onDomReady(() => {
  this.filterPage();
  initDomObserver(() => this.filterPage());
});

The observer watches for added nodes in the main content area. When it detects new elements, it calls filterPage() again, but the function skips elements that have already been processed by checking for a data attribute marker.

Real-Time Settings with chrome.storage

All settings are persisted using chrome.storage.sync so they follow the user across devices. The extension listens for storage changes and reacts in real time -- if a user adds a new keyword in the options page, the content script picks it up immediately and re-filters the page:

private handleSettingsChange(
  newSettings: Settings, oldSettings: Settings
): void {
  if (newSettings.enabled !== oldSettings.enabled) {
    this.isEnabled = newSettings.enabled;
    if (this.isEnabled) {
      this.configureFilters(newSettings);
      this.filterPage();
      initDomObserver(() => this.filterPage());
    } else {
      this.showAllArticles();
      stopDomObserver();
    }
    return;
  }

  this.showAllArticles();
  this.filterPage();
}

When settings change, the extension first restores all previously hidden articles, then re-runs the filter pipeline with the updated criteria. This ensures that loosening a filter immediately reveals previously hidden content.

Statistics Tracking

The extension tracks filtering statistics -- how many articles were filtered today, this week, this month, and all time, broken down by source and keyword. This data is stored locally and displayed in the popup UI using Recharts for visualization.

Users can see which sources produce the most filtered content and which keywords catch the most articles. This feedback loop helps users refine their filtering setup over time.

The Type System

The TypeScript type system ties everything together. The FilterResult type is returned by every filter and contains the verdict plus metadata about what triggered it:

interface FilterResult {
  shouldFilter: boolean;
  reason?: 'keyword' | 'source' | 'kotatsu' | 'preset';
  matchedValue?: string;
}

The Settings type captures the full configuration surface:

interface Settings {
  enabled: boolean;
  keywords: string[];
  blockedSources: string[];
  cleanModeEnabled: boolean;
  kotatsuEnabled: boolean;
  filterStrength: 'low' | 'medium' | 'high';
  presets: {
    gossip: boolean;
    inflammatory: boolean;
    aggregator: boolean;
  };
}

This strict typing caught several bugs during development, especially around the message-passing protocol between the content script, background script, and popup.

Freemium Model

The extension uses a freemium model powered by ExtensionPay (which wraps Stripe). The free tier includes basic filtering with limits on the number of blocked sources and keywords. Premium unlocks unlimited filters, the kotatsu detector, detailed statistics, regex-based filters, and data export/import.

What I Learned

Building this extension taught me a few things about working with content scripts on large, complex websites:

DOM structures change. Yahoo! JAPAN has updated their page layout several times since I started. Having page-specific selector modules makes it easy to update selectors without touching the core filtering logic.
Japanese text processing is hard. You cannot just split on spaces. TinySegmenter is a lightweight solution, but it is not perfect. For a Chrome extension where bundle size matters, it is a practical compromise.
Scoring beats binary classification. A simple blocklist would be too aggressive or too lenient. The multi-factor scoring approach lets users tune the sensitivity to match their tolerance for borderline content.
MutationObserver is essential for modern web pages. Without it, the extension would only filter content visible on the initial page load and miss everything that loads dynamically.
Settings reactivity matters. Users expect changes to take effect immediately. The combination of chrome.storage.onChanged and a handler that restores then re-filters the page creates a seamless experience.

If you use Yahoo! JAPAN and want a cleaner news experience, give it a try.

Yahoo快適モード - Yahoo!ニュースフィルター | 煽り記事・こたつ記事を非表示 | S-Hub

Yahoo!ニュースの低品質記事を自動フィルタリングする無料Chrome拡張機能。煽り記事・こたつ記事・週刊誌ゴシップを非表示にして快適閲覧。

dev-tools-hub.xyz

Other tools I've built:

X Detox - Clean Twitter/X Feed, Hide For You & Trends - Chrome Web Store

Remove For You tab, trends & promoted tweets from X/Twitter. Enjoy a clean, chronological Following feed. Customize what you hide.

chromewebstore.google.com

ZenRead - Reader Mode & Distraction Free - Chrome Web Store

Remove ads & clutter from any webpage with one click. Enjoy distraction-free reading with bionic speed reading, dark mode, and TTS.

chromewebstore.google.com

Scraping Japan's Largest Real Estate Site with a Chrome Extension: Building an Automated Property Scoring Engine

SHOTA — Tue, 07 Apr 2026 09:59:23 +0000

If you've ever apartment-hunted in Japan, you know the drill. You open SUUMO -- the country's dominant real estate portal, think Zillow but with near-monopoly status -- and you're immediately staring at dozens of property listings. Each card shows rent, area, station distance, building age. But the numbers that actually matter for making a decision? Those aren't there. You have to calculate them yourself, mentally, for every single listing.

Price per square meter. Total move-in cost (which in Japan includes a dizzying mix of deposits, "key money," brokerage fees, insurance, and lock replacement charges). Two-year total cost of living. Whether the asking price is reasonable compared to the neighborhood average.

I got tired of doing this math on paper, so I built Bukken Scouter -- a pair of Chrome extensions that inject real-time financial analysis directly into SUUMO's listing pages. One for purchases (condos and houses), one for rentals. Both are built on Manifest V3, React, TypeScript, and Vite, and they solve fundamentally different problems despite sharing an architecture.

Why SUUMO, and Why This Is Harder Than It Looks

SUUMO (suumo.jp) is operated by Recruit Holdings, one of Japan's largest tech conglomerates. It aggregates listings from nearly every real estate agency in the country. If you're looking for a place to live in Japan, you're using SUUMO. There's no real alternative with comparable coverage.

The problem is that SUUMO is designed as a listing aggregator, not an analysis tool. It shows you raw listing data -- price, area, age, station -- but leaves all the comparative analysis to you. There's no yield calculation for purchase properties. No total cost projection for rentals. No way to quickly assess whether a price is fair for the neighborhood.

And the DOM structure is... interesting. SUUMO uses multiple page layouts depending on property type, and the markup differs significantly between them. Condo listings (/chukomansion/), new construction (/ms/), detached houses (/ikkodate/, /chukoikkodate/), and rental listings (/chintai/) each have their own HTML patterns. Some use table layouts with <dt>/<dd> pairs. Others use CSS class-based cards. Detail pages use yet another structure entirely.

This means the content script can't just use one set of selectors. It needs a detection layer, a selector mapping layer, and fallback strategies for each.

Architecture: How the Extension Works

Both extensions follow the same high-level architecture:

Content Script (injected into SUUMO pages)
  -> Page Detector (identifies page type from URL + DOM)
  -> Parser (extracts property data from DOM elements)
  -> Calculator (computes derived metrics)
  -> Injector (renders React components into the page)

Background Service Worker
  -> Storage management (chrome.storage)
  -> Alarm-based notifications
  -> Side panel coordination

Side Panel UI
  -> Favorites list with comparison view
  -> Settings management

The content script is the core of the system. It's declared in manifest.json with specific URL match patterns:

// Purchase version
"content_scripts": [{
  "matches": [
    "https://suumo.jp/ms/*",
    "https://suumo.jp/chukomansion/*",
    "https://suumo.jp/ikkodate/*",
    "https://suumo.jp/chukoikkodate/*",
    "https://suumo.jp/jj/bukken/*"
  ],
  "js": ["content.js"],
  "css": ["content.css"],
  "run_at": "document_idle"
}]

// Rental version
"content_scripts": [{
  "matches": [
    "https://suumo.jp/chintai/*",
    "https://suumo.jp/jj/chintai/*"
  ],
  "js": ["content.js"],
  "css": ["content.css"],
  "run_at": "document_idle"
}]

The separation into two extensions wasn't an arbitrary choice. Purchase and rental properties have fundamentally different data models and calculation needs. A purchase property cares about price-per-tsubo (a traditional Japanese area unit, 1 tsubo = 3.3 sqm), building age depreciation curves, and management/repair reserve fees. A rental property cares about initial move-in costs, annual cost projections, and two-year total costs (Japan's standard lease term). Trying to cram both into one extension would have made the codebase harder to maintain and the UI confusing.

DOM Parsing: The Messiest Part

SUUMO's DOM structure is the most technically challenging aspect of this project. The site uses what I call a "dottable" layout -- a <dl>/<dt>/<dd> pattern where property attributes are rendered as label-value pairs. But the specific CSS classes and nesting patterns change depending on the property category.

Here's how the selector mapping works for the purchase version:

export const SUUMO_SELECTORS = {
  CHUKOMANSION_LIST: {
    propertyCard: '.property_unit, .cassette_list-item, .cassetteitem',
    propertyName: 'dd.dottable-vm, .property_unit-title a, .cassetteitem_content-title a',
    price: 'span.dottable-value, .dottable-value--price, .cassetteitem_price--emphasis',
    area: '.dottable-fix dd, .dottable-value--area, .cassetteitem_menseki',
    age: '.dottable-fix dd, .dottable-value--age',
    // ... more selectors
  },
  DETAIL: {
    propertyName: '.section_h1-header-title, h1.ui-section-header',
    price: '.property_view_main-emphasis, .property_view_note-emphasis',
    infoTable: '.property_view_table, .secti table',
    // ... detail page selectors
  }
};

Each selector field is actually a comma-separated list of fallback selectors. The parser tries them in order until one matches. This handles the reality that SUUMO's frontend team apparently ships different markup structures for different property subtypes, and occasionally updates them.

The parser itself uses a priority system. It first tries the "dottable" structure (the <dt>/<dd> pattern), because that's the most reliable:

function findDottableValue(card: Element, labelText: string): string {
  const dts = card.querySelectorAll('dt');
  for (const dt of dts) {
    if (dt.textContent?.includes(labelText)) {
      const dl = dt.closest('dl');
      if (dl) {
        const dd = dl.querySelector('dd');
        if (dd) return getTextContent(dd);
      }
      const nextSibling = dt.nextElementSibling;
      if (nextSibling?.tagName === 'DD') {
        return getTextContent(nextSibling);
      }
    }
  }
  return '';
}

If the dottable lookup fails, it falls back to CSS class-based selectors. This two-tier approach has proven resilient to minor SUUMO layout changes.

For the rental version, the challenge is slightly different. Rental listings use a building-to-room hierarchy: each .cassetteitem (building card) contains multiple .js-cassette_link rows (individual room listings). The parser needs to extract building-level data (name, address, station) from the parent card and room-level data (rent, area, floor) from each row, then merge them:

function findPropertyRows(): PropertyRowInfo[] {
  const results: PropertyRowInfo[] = [];
  const buildings = document.querySelectorAll('.cassetteitem');

  buildings.forEach((building) => {
    const rows = building.querySelectorAll('.js-cassette_link');
    if (rows.length > 0) {
      rows.forEach((row, index) => {
        results.push({ row, buildingElement: building, rowIndex: index });
      });
    } else {
      results.push({ row: building, buildingElement: building, rowIndex: 0 });
    }
  });
  return results;
}

Japanese Price Parsing: More Complex Than You'd Expect

Japanese real estate prices use a counting system that doesn't map cleanly to Western number formatting. Prices are expressed in units of "man" (10,000) and "oku" (100,000,000). A condo might be listed as "3,980 man-en" (39,800,000 yen) or "1-oku 2,000 man-en" (120,000,000 yen). The parser needs to handle both:

export function parsePrice(priceText: string): number {
  const cleaned = priceText.replace(/\s/g, '');

  // Handle "oku" (hundred millions)
  const okuMatch = cleaned.match(/(\d+(?:,\d+)?)億(?:(\d+(?:,\d+)?)万)?/);
  if (okuMatch) {
    const oku = parseInt(okuMatch[1].replace(/,/g, ''), 10) * 100000000;
    const man = okuMatch[2]
      ? parseInt(okuMatch[2].replace(/,/g, ''), 10) * 10000
      : 0;
    return oku + man;
  }

  // Handle "man" (ten thousands)
  const manMatch = cleaned.match(/(\d+(?:,\d+)?)万/);
  if (manMatch) {
    return parseInt(manMatch[1].replace(/,/g, ''), 10) * 10000;
  }

  return 0;
}

For purchases, the derived metric is "tsubo-tanka" (price per tsubo), which is the standard unit Japanese real estate agents use to compare property values:

export function calculateTsuboPrice(price: number, areaSqm: number): number {
  if (areaSqm <= 0) return 0;
  const areaTsubo = areaSqm * 0.3025; // 1 sqm = 0.3025 tsubo
  return Math.round(price / areaTsubo / 10000); // result in man-en/tsubo
}

For rentals, the key calculation is total move-in cost, which in Japan is substantially higher than in most countries:

static calcInitialCost(
  rent: number,
  managementFee: number,
  depositMonths: number,
  keyMoneyMonths: number,
): number {
  const deposit = rent * depositMonths;
  const keyMoney = rent * keyMoneyMonths;       // non-refundable "gift" to landlord
  const firstMonthRent = rent + managementFee;
  const brokerage = rent * 1.1;                  // agent fee (1 month + tax)
  const guarantee = rent * 0.5;                  // guarantor company fee
  const keyChange = 15000;                       // lock replacement
  const insurance = 15000;                       // fire insurance
  return deposit + keyMoney + firstMonthRent + brokerage
         + guarantee + keyChange + insurance;
}

That "key money" line deserves explanation for international readers. In Japan, many landlords expect a non-refundable payment of 1-2 months' rent simply for the privilege of signing the lease. It's called "reikin" (literally "gratitude money"). Combined with deposits, brokerage fees, and various administrative charges, moving into a new apartment in Tokyo can easily cost 4-6 months' rent upfront. The extension calculates this automatically so users can compare the true cost of different listings at a glance.

Scoring: Rule-Based Market Analysis

Both extensions include an AI-style scoring system that assesses whether a property's price is reasonable for its area, age, and location. Despite the name, the current implementation is rule-based rather than neural-network-based (the TensorFlow.js integration exists as a hook for future model deployment, with a fallback to the rule engine).

The rental version maintains a lookup table of base price-per-sqm rates for every ward in Tokyo's 23 special wards, plus surrounding cities:

const AREA_BASE_PRICE: Record<string, number> = {
  '港区': 5500,    // Minato: Tokyo's most expensive ward
  '渋谷区': 5200,  // Shibuya
  '千代田区': 5000, // Chiyoda
  // ... all 23 wards ranked by market rate
  '足立区': 2500,  // Adachi: more affordable
  '横浜市': 2800,  // Yokohama
  'default': 2500,
};

The scoring applies correction factors for building age, station distance, and layout type:

function getAgeFactor(age: number): number {
  if (age <= 0) return 1.15;  // brand new: 15% premium
  if (age <= 5) return 1.05;
  if (age <= 10) return 1.00; // baseline
  if (age <= 20) return 0.90;
  if (age <= 30) return 0.85;
  return 0.80;                // 30+ years: 20% discount
}

function getWalkFactor(walkMinutes: number): number {
  if (walkMinutes <= 3) return 1.12;
  if (walkMinutes <= 5) return 1.08;
  if (walkMinutes <= 10) return 1.00; // baseline
  if (walkMinutes <= 15) return 0.95;
  return 0.85;
}

The final verdict compares the actual rent against the predicted rent. If the actual price is more than 10% below prediction, it's flagged as a good deal. More than 10% above? Overpriced. The result is injected as a colored badge directly into the listing card.

The purchase version uses a similar approach but with different coefficients -- a base tsubo price of 300 man-en for central Tokyo, with depreciation of roughly 1% per year of building age and 1% per minute of walking distance to the nearest station.

Handling Dynamic Content and SPA Navigation

SUUMO isn't a full SPA, but it does lazy-load content and occasionally updates the DOM without a full page navigation. The extensions handle this with a MutationObserver that watches for new property cards:

function observeDOM(): void {
  const observer = new MutationObserver(() => {
    if (isProcessing) return;

    if (debounceTimer) clearTimeout(debounceTimer);
    debounceTimer = setTimeout(() => {
      const newCards = document.querySelectorAll(
        '.cassetteitem:not([data-scouter-processed])'
      );
      if (newCards.length > 0) processPage();
    }, 2000);
  });

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

A critical detail: the observer must ignore its own DOM mutations. Without this guard, injecting a React component triggers the observer, which re-processes the page, which injects another component, creating an infinite loop. The purchase version solves this by checking if mutations originate from .bukken-scouter-container elements:

const isOurMutation = mutations.every(mutation => {
  for (const node of mutation.addedNodes) {
    if (node instanceof HTMLElement) {
      if (node.classList.contains('bukken-scouter-container')) {
        return true;
      }
    }
  }
  return false;
});
if (isOurMutation) return; // ignore our own injections

The rental version takes a simpler approach: it marks processed rows with a data-scouter-processed attribute and only processes unprocessed cards.

React Injection into Third-Party DOM

Both extensions use React for the injected UI components, but they can't use a standard React app mount point. Instead, they create isolated container elements and mount React roots into them:

const container = document.createElement('div');
container.className = 'bukken-scouter-container';
container.setAttribute('data-property-id', property.id);

targetElement.appendChild(container);

const root = createRoot(container);
root.render(
  <PropertyInfo
    property={property}
    showPricePerSqm={true}
    compact={true}
  />
);

Each property card gets its own React root. This isolation is intentional -- it prevents SUUMO's CSS from breaking the injected components and vice versa, and it means individual cards can be unmounted cleanly without affecting others.

The purchase version renders a panel with tsubo price, building age (color-coded), price history, a favorites button, and a link to Japan's official hazard map portal (useful for earthquake/flood risk assessment). The rental version shows price-per-sqm, initial cost estimate, and the AI deal score.

Additional Features Worth Mentioning

Price tracking: The purchase version monitors favorited properties for price changes over time using chrome.storage. Each time a favorited property's page is visited, the current price is compared against stored history. Price drops trigger notifications via the chrome.alarms and chrome.notifications APIs.

Side panel: Both versions use Chrome's Side Panel API to provide a persistent comparison view. Users can favorite properties from listing pages, then open the side panel to see all saved properties in a sortable, comparable format.

Hazard map integration: The purchase version includes a button that opens Japan's government-operated hazard map portal (disaportal.gsi.go.jp) for the property's location. In a country with frequent earthquakes, typhoons, and flood risks, this is genuinely useful context for a purchase decision.

Export: Both versions support exporting property data, useful for sharing analysis with family members or real estate agents.

What I Learned Building This

Scraping is maintenance. SUUMO's DOM structure has changed at least twice since I started this project. The multi-selector fallback approach has saved me from emergency hotfixes, but it's still a fragile foundation. If SUUMO ever switches to a React-based SPA with obfuscated class names, this approach will need a fundamental rethink.

Japanese number formatting is deceptively tricky. The man/oku system, combined with comma separators and occasional full-width characters, means your price parser needs to handle more edge cases than you'd expect from a "just parse a number" function.

Domain-specific knowledge matters more than clever code. The scoring algorithm is technically simple -- it's just multiplication of correction factors. But the correction factors themselves encode real estate market knowledge: that brand-new buildings in Tokyo command a 15% premium, that station proximity drops off non-linearly, that 1R (studio) apartments have higher per-sqm rates than family-sized units. Getting these coefficients right required actual research into the Tokyo rental market, not just programming skill.

Content script isolation is underrated. Using individual React roots per injected component, rather than one big app, turned out to be the right call. It makes cleanup reliable, prevents cascade failures, and keeps memory usage predictable even on pages with 50+ property cards.

Try It Out

Both extensions are free and available on the Chrome Web Store. Even if you're not apartment hunting in Japan, the codebase is a practical example of building a content-script-heavy Chrome extension that does real-time DOM analysis and data enrichment on a third-party site.

賃貸スカウター - SUUMO物件比較・初期費用計算 | 無料Chrome拡張機能 | S-Hub

SUUMOの賃貸物件を効率比較できる無料Chrome拡張機能。㎡単価・初期費用・年間コストを自動計算。AI賃料判定で「お得/適正/割高」を判定。

dev-tools-hub.xyz

物件スカウター購入版 - SUUMO坪単価自動計算 | 無料Chrome拡張機能 | S-Hub

SUUMOの購入物件で坪単価・㎡単価を自動計算する無料Chrome拡張機能。築年数ハイライト、お気に入り比較、価格履歴トラッキング搭載。

dev-tools-hub.xyz

Other tools I've built:

DataPick - No-Code Web Scraper & Data Extractor - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

Arbitra - せどり価格比較ツール | Amazon・メルカリ・ヤフオク一括比較 | S-Hub

Amazon、メルカリ、ヤフオクの価格を一括比較できる無料Chrome拡張機能。利益計算機能搭載で、手数料・送料込みの正確な利益をワンクリックで計算。

dev-tools-hub.xyz

I Built a Chrome Extension to Remove X/Twitter's Algorithmic Feed and Reclaim My Timeline

SHOTA — Mon, 06 Apr 2026 10:01:28 +0000

I used to open Twitter to check what the people I follow were saying. Somewhere along the way, that stopped being what Twitter showed me.

Instead of tweets from friends and accounts I deliberately chose to follow, my feed was full of rage-bait threads from strangers, promoted tweets disguised as organic content, trending topics I never asked about, and "Who to follow" suggestions based on whatever the algorithm decided would keep me scrolling longest.

I'd open the app to check one thing and surface 20 minutes later, irritated and wondering how I ended up reading a heated debate between two people I've never heard of. The "For You" tab had become the default, and every time I navigated away, X would silently switch me back.

So I built X Detox -- a Chrome extension that strips out X/Twitter's algorithmic recommendation layers and gives you back a chronological timeline of just the people you follow. No trends, no promoted tweets, no suggested users, no Grok AI buttons. Just the feed you curated.

The Problem with Algorithmic Feeds

Algorithmic feeds are optimized for engagement, not for what's good for you. High-engagement content tends to be emotionally provocative -- outrage, fear, controversy. The more time you spend scrolling, the more ad impressions the platform generates. Your attention is the product being sold.

The "For You" tab on X surfaces content designed to maximize time on platform. It mixes in tweets from accounts you don't follow, trending topics, and promoted content. Even if you click the "Following" tab, X resets you back to "For You" on your next visit.

I wanted to break this cycle permanently, without leaving the platform entirely.

The Technical Approach

X Detox takes a two-pronged approach: CSS injection to hide unwanted UI elements, and DOM manipulation with MutationObserver to force the timeline tab selection.

CSS Injection: Hiding the Noise

The simplest and most performant way to hide elements on a web page is CSS. X Detox generates CSS rules dynamically based on user settings and injects them into the page via a <style> element.

Here's how the CSS generation works at a high level:

const STYLE_ID = 'x-detox-styles';

function generateCSS(settings: Settings): string {
  const rules: string[] = [];

  if (settings.hideTrends) {
    rules.push(`
      [aria-label="Timeline: Trending now"],
      [aria-label*="Trending"],
      [data-testid="trend"],
      [data-testid="sidebarColumn"] section,
      [data-testid="sidebarColumn"] aside
      { display: none !important; }
    `);
  }

  if (settings.hidePromotedTweets) {
    rules.push(`
      article:has([data-testid="placementTracking"]),
      [data-testid="placementTracking"],
      [aria-label="Who to follow"],
      [data-testid="sidebarColumn"] [data-testid="UserCell"]
      { display: none !important; }
    `);
  }

  return rules.join('\n');
}

function injectStyles(settings: Settings): void {
  let styleEl = document.getElementById(STYLE_ID) as HTMLStyleElement | null;

  if (!styleEl) {
    styleEl = document.createElement('style');
    styleEl.id = STYLE_ID;
    styleEl.setAttribute('type', 'text/css');
    (document.head || document.documentElement).appendChild(styleEl);
  }

  styleEl.textContent = generateCSS(settings);
}

A few things worth calling out:

Why CSS over DOM removal? Removing elements from the DOM with JavaScript is fragile. If X re-renders a component (which React-based SPAs do constantly), the element comes right back and you have to remove it again. CSS display: none !important is permanent as long as the stylesheet is present. The browser's rendering engine handles it, and re-renders don't break anything.

Why !important? X uses inline styles and high-specificity selectors. Without !important, X's own styles would override our hiding rules.

Why dynamic generation? Each setting controls a group of CSS rules. When the user toggles a setting in the popup, the entire stylesheet is regenerated and replaced. This is cheaper than maintaining individual rules -- the browser only needs to reparse one <style> element.

Selector Strategy: data-testid vs. aria-label

One of the trickiest parts of building a content-hiding extension for a platform like X is finding stable selectors. X uses React and generates dynamic class names that change on every build. You can't rely on .r-1234abcd staying the same next week.

Instead, I use two types of selectors:

data-testid attributes: X's engineering team uses these for their own testing infrastructure. They tend to be stable because internal test suites depend on them. data-testid="placementTracking" reliably identifies promoted tweets, data-testid="trend" marks trend items, and data-testid="sidebarColumn" is the right sidebar container.
aria-label attributes: These are accessibility labels, and they're part of the public contract X makes with screen readers. Changing them would break accessibility compliance. aria-label="Timeline: Trending now" and aria-label="Who to follow" have been stable across multiple X redesigns.

I avoid class-based selectors entirely. If you grep through the X DOM, you'll find classes like css-175oi2r and r-1awozwy -- these are generated by their build system and can change daily.

Forcing the Following Tab: MutationObserver

Hiding sidebar elements with CSS is straightforward. Forcing the timeline to show the "Following" tab instead of "For You" is harder.

X defaults to the "For You" algorithmic tab every time you visit the home page. Even if you manually click "Following," it won't remember your preference across visits. This is clearly a deliberate product decision -- they want you on the algorithmic feed.

My approach uses two MutationObservers: one to watch for DOM changes on the page, and another to detect URL changes (since X is a single-page app and doesn't trigger traditional page loads).

function findFollowingTab(): HTMLElement | null {
  const tabList = document.querySelector('[role="tablist"]');
  if (!tabList) return null;

  const tabs = tabList.querySelectorAll('[role="tab"]');
  for (const tab of tabs) {
    const text = tab.textContent?.toLowerCase() || '';
    if (text.includes('following') || text.includes('\u30d5\u30a9\u30ed\u30fc\u4e2d')) {
      return tab as HTMLElement;
    }
  }
  return null;
}

function isForYouSelected(): boolean {
  const tabList = document.querySelector('[role="tablist"]');
  if (!tabList) return false;

  const tabs = tabList.querySelectorAll('[role="tab"]');
  for (const tab of tabs) {
    const text = tab.textContent?.toLowerCase() || '';
    const isSelected = tab.getAttribute('aria-selected') === 'true';
    if ((text.includes('for you') || text.includes('\u304a\u3059\u3059\u3081')) && isSelected) {
      return true;
    }
  }
  return false;
}

function switchToFollowing(): void {
  if (!window.location.pathname.includes('/home') &&
      window.location.pathname !== '/') {
    return;
  }

  if (!isForYouSelected()) return;

  const followingTab = findFollowingTab();
  if (followingTab) {
    followingTab.click();
  }
}

The logic is simple: check if the "For You" tab is currently selected by reading its aria-selected attribute, find the "Following" tab by its text content, and click it programmatically.

But the timing is everything. X loads its UI progressively. When you navigate to the home page, the tab list might not exist yet. When X re-renders the page (which happens frequently in their React SPA), the "For You" tab might get selected again.

That's where the MutationObserver comes in:

function setupTimelineObserver(): void {
  const observer = new MutationObserver(() => {
    switchToFollowing();
  });

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

This watches the entire DOM for changes. Every time X adds, removes, or modifies a node anywhere in the page, the observer fires and checks whether the tab needs switching. It's aggressive, but it needs to be -- X can switch the tab back at any point during its render cycle.

The second observer handles SPA navigation:

function setupUrlObserver(): void {
  let lastUrl = location.href;

  const urlObserver = new MutationObserver(() => {
    if (location.href !== lastUrl) {
      lastUrl = location.href;
      setTimeout(switchToFollowing, 300);
    }
  });

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

Since X uses client-side routing, the URL changes without a page reload. There's no native browser event for SPA navigation (the popstate event only fires for back/forward, not for programmatic navigation). Watching for DOM mutations and comparing location.href is a reliable way to detect these transitions. The 300ms delay gives X time to render the new page before we try to switch tabs.

Internationalization: Why Text Matching Needs Multiple Languages

X serves its UI in the user's browser language. In English, the tabs say "For you" and "Following." In Japanese, they say "\u304a\u3059\u3059\u3081" and "\u30d5\u30a9\u30ed\u30fc\u4e2d." The tab-switching logic needs to handle both (and more).

I could have checked only the English strings and called it done. But that would break the extension for anyone whose X interface is in a non-English language. So the text matching includes multiple languages:

// English: "following", Japanese: "\u30d5\u30a9\u30ed\u30fc\u4e2d"
if (text.includes('following') || text.includes('\u30d5\u30a9\u30ed\u30fc\u4e2d')) {
  return tab as HTMLElement;
}

The extension's popup UI itself supports 7 languages: English, Japanese, Korean, German, French, Italian, and Spanish. Language is auto-detected from the browser locale and can be changed manually via a dropdown.

The Timing Dance: document_start

The content script runs at document_start, meaning CSS is injected before X's own styles load. The user never sees trending or promoted content flash on screen -- it's invisible from the first paint.

But document_start means document.body doesn't exist yet. So initialization uses a three-stage approach:

Immediate execution: Inject styles right away (attaching to document.documentElement if document.head isn't ready)
DOMContentLoaded: Re-inject once the DOM is parsed
window.load + 1s delay: Re-inject to catch X's lazy-loaded components

init(); // Run immediately

if (document.readyState === 'loading') {
  document.addEventListener('DOMContentLoaded', () => {
    injectStyles(currentSettings);
  });
}

window.addEventListener('load', () => {
  setTimeout(() => injectStyles(currentSettings), 1000);
});

Is triple injection overkill? Maybe. But it prevents visual flicker, and injecting CSS is cheap.

Settings and Real-Time Updates

All settings are stored in chrome.storage.sync, which means they sync across your Chrome instances if you're signed in. Change a setting on your laptop, and it applies on your desktop automatically.

The popup modifies settings, and the content script listens for changes in real time:

function onSettingsChanged(callback: (settings: Settings) => void): () => void {
  const listener = (
    changes: { [key: string]: chrome.storage.StorageChange },
    areaName: string
  ) => {
    if (areaName === 'sync' && changes.settings) {
      callback({ ...DEFAULT_SETTINGS, ...changes.settings.newValue });
    }
  };
  chrome.storage.onChanged.addListener(listener);
  return () => chrome.storage.onChanged.removeListener(listener);
}

When the user toggles "Hide Trends" in the popup, the content script immediately regenerates and replaces the CSS. The trending sidebar vanishes (or reappears) without a page reload.

What Gets Hidden (and What Doesn't)

The free version of X Detox hides three categories of algorithmic content:

1. The "For You" tab. The extension auto-switches to the "Following" tab and keeps you there. You never see algorithmically curated tweets from accounts you don't follow.

2. Trends and the sidebar. The entire trending section, "What's happening" widget, and sidebar recommendations are hidden. The search bar in the sidebar is preserved -- that's actually useful.

3. Promoted tweets and "Who to follow." Ads disguised as tweets and suggested user cards are both hidden. These are identified by their data-testid="placementTracking" and data-testid="UserCell" attributes respectively.

The Pro tier adds four more options: hiding view count analytics, removing Grok AI elements, blocking Premium/Blue subscription upsells, and filtering out retweets to show only original tweets.

I wanted the core detox experience -- removing the algorithmic feed, trends, and ads -- to be free. Those are the features that actually affect your information diet and mental well-being.

The Cat-and-Mouse Game with X's DOM

Here's the uncomfortable truth about building extensions for major platforms: they change their DOM structure regularly. Sometimes it's part of a redesign. Sometimes it's specifically to break extensions.

X's codebase is React-based, and their class names are generated hashes that change frequently. But their data-testid attributes and aria-label values tend to be more stable, because changing them would break their own testing infrastructure and accessibility compliance.

That said, I've still had to update selectors. The sidebar structure has shifted from using direct child selectors to nested sections. The "Who to follow" section has changed its aria-label text. Promoted tweet markers have been reorganized.

My strategy for resilience is layered selectors. Rather than relying on a single selector per element, I use multiple overlapping selectors:

/* Trends: multiple selectors for the same content */
[aria-label="Timeline: Trending now"],
[aria-label*="Trending"],
[data-testid="trend"],
[data-testid="sidebarColumn"] section,
[data-testid="sidebarColumn"] aside
{ display: none !important; }

If X changes one selector, the others still catch it. This redundancy makes the extension more resistant to DOM changes without requiring constant updates.

Performance Considerations

Running MutationObservers on document.body with subtree: true sounds expensive -- every DOM mutation triggers the callback.

In practice, the impact is minimal. The callback functions are lightweight: switchToFollowing() does a few querySelector calls and a string comparison, returning immediately if conditions aren't met. And CSS-based hiding has zero runtime cost after injection -- the browser's layout engine handles display: none natively. The vast majority of the hiding is pure CSS with no JavaScript in the loop.

Digital Well-Being: Why This Matters

Algorithmic feeds create filter bubbles, prioritize engagement over accuracy, and make it harder to have a calm, curated information diet. By switching to a chronological timeline, you're replacing an algorithm's choices with your own. That's a small but meaningful act of digital autonomy.

X Detox doesn't block X or limit your screen time. It removes the manipulative layer of algorithmic curation and gives you the feed you actually signed up for. You still see everything from the people you follow, in the order they posted it.

The Tech Stack

For those who want the full picture:

Component	Technology
Language	TypeScript
Build	Vite + tsc
Manifest	Chrome Extension Manifest V3
Content Script	Injected CSS + MutationObserver
Settings Storage	chrome.storage.sync
Popup	Vanilla HTML/CSS/TypeScript
Payments	ExtPay (ExtensionPay)
i18n	Custom 7-language system
Analytics	GA4 Measurement Protocol

The entire extension is lightweight by design. No React in the content script, no heavy frameworks, no external dependencies at runtime. The content script is a single TypeScript file compiled to plain JavaScript. CSS does the heavy lifting.

What I Learned

CSS is underrated for content modification. My first instinct was to use JavaScript to find and remove elements. CSS display: none is simpler, faster, and more resilient to re-renders. Use JavaScript only for things CSS can't do (like clicking tabs).

data-testid attributes are your best friend. When building extensions for React-based SPAs, test IDs are the most stable selectors available. Class names are generated hashes, IDs are rare, but test attributes persist because the platform's own tests depend on them.

MutationObserver is powerful but needs discipline. Observing document.body with subtree: true fires on every DOM change. Keep your callbacks cheap and bail out early when conditions aren't met.

Internationalization matters from day one. If your extension relies on matching text content in the DOM, you need to handle multiple languages immediately. Adding i18n later means refactoring every text comparison.

Users care about their attention. A lot of people feel the same frustration with algorithmic feeds. They want to use the platform on their own terms. Building tools that give people control over their digital experience is genuinely valued.

If you're tired of X's algorithmic feed deciding what you see, give X Detox a try. It's free for the core features and works instantly -- no account linking, no configuration required. Install it, and your timeline becomes chronological.

X Detox - Clean Twitter/X Feed, Hide For You & Trends - Chrome Web Store

Remove For You tab, trends & promoted tweets from X/Twitter. Enjoy a clean, chronological Following feed. Customize what you hide.

chromewebstore.google.com

If you have questions about the implementation or want to share your own experience with algorithmic feed detox, drop a comment below.

Other tools I've built:

Yahoo快適モード - Yahoo!ニュースフィルター | 煽り記事・こたつ記事を非表示 | S-Hub

Yahoo!ニュースの低品質記事を自動フィルタリングする無料Chrome拡張機能。煽り記事・こたつ記事・週刊誌ゴシップを非表示にして快適閲覧。

dev-tools-hub.xyz

ZenRead - Reader Mode & Distraction Free - Chrome Web Store

Remove ads & clutter from any webpage with one click. Enjoy distraction-free reading with bionic speed reading, dark mode, and TTS.

chromewebstore.google.com

How to Compare Prices for Retail Arbitrage — Amazon vs Mercari Extension

SHOTA — Sun, 05 Apr 2026 09:30:56 +0000

Retail arbitrage is conceptually simple: buy a product on one platform where it's cheap, sell it on another where it's expensive, and pocket the difference. In practice, it's death by browser tabs.

You're looking at a product on Amazon Japan. Is it cheaper on Mercari? What about Yahoo Auctions? You open three more tabs, type the product name into each search bar, scroll through results, mentally calculate fees, and try to remember the original price while comparing. By the time you finish, you've spent ten minutes on a single product and your browser has 47 tabs open.

I went through this cycle hundreds of times before I decided to automate it. The result is Arbitra -- a Chrome extension that sits in the browser's side panel and compares prices across Amazon, Mercari, and Yahoo Auctions in real time. When you visit a product page on any of these platforms, Arbitra scrapes the product data, searches the other two platforms, and shows you a profit score telling you whether the arbitrage opportunity is worth pursuing.

This article covers the technical architecture, the scraping challenges I ran into, and the scoring algorithm that makes buy/pass decisions.

Arbitra - せどり価格比較ツール | Amazon・メルカリ・ヤフオク一括比較 | S-Hub

dev-tools-hub.xyz

The Architecture: Content Scripts, Background Worker, and a Side Panel

Chrome extensions built on Manifest V3 have a specific communication model. You can't just have one monolithic script that does everything. Instead, you get three execution contexts that need to talk to each other:

Content scripts -- injected into web pages, with access to the DOM but limited Chrome API access
Service worker -- runs in the background, handles Chrome APIs and cross-origin requests
UI surfaces -- popup, side panel, or options page, each its own React application

Here's how data flows through Arbitra:

[Amazon page] --> Content Script extracts product data
                     |
                     v
              Background Service Worker
              - Receives product data via chrome.runtime.sendMessage
              - Builds search queries
              - Fetches Mercari + Yahoo Auctions in parallel
              - Calculates relevance scores
              - Stores results in memory
                     |
                     v
              Side Panel (React + Zustand)
              - Receives results via chrome.runtime.onMessage
              - Displays price comparison cards
              - Calculates profit score
              - Shows BUY / CONSIDER / PASS verdict

I chose the side panel over a popup because arbitrage workflows need persistence. A popup closes the moment you click away from it. The side panel stays open while you browse, which means you can navigate between product pages and see the comparison update automatically.

Scraping Product Data from Three Different Platforms

The first real challenge was extracting product information from three platforms that have nothing in common in their HTML structure.

Amazon: The Selector Graveyard

Amazon changes their product page DOM constantly. A selector that works today might break next month. My approach was to build a priority list of selectors and fall through them until one works:

function extractPrice(): number {
  const selectors = [
    '#corePrice_feature_div .a-price .a-offscreen',
    '#corePriceDisplay_desktop_feature_div .a-price .a-offscreen',
    '.priceToPay .a-offscreen',
    '.apexPriceToPay .a-offscreen',
    '#priceblock_ourprice',
    // ... 10+ more selectors
    '.a-price .a-offscreen', // final fallback
  ];

  for (const selector of selectors) {
    const el = document.querySelector(selector);
    if (el?.textContent) {
      const cleaned = el.textContent.replace(/[currency symbols]/g, '');
      const price = parseInt(cleaned, 10);
      if (price > 0) return price;
    }
  }
  return 0;
}

Beyond the price, Arbitra also extracts the ASIN (Amazon's unique product identifier), brand name, model number, and product image. The ASIN comes from the URL, an input element, or a data attribute -- whichever is available. The brand name hides behind selectors that differ between product categories. Model numbers get pulled from the product details table or parsed out of the product title with regex.

Each piece of extracted metadata improves search accuracy on the other platforms. A search for "Sony WH-1000XM5" finds better matches than a search for the full 200-character Amazon product title.

Mercari: SPAs and API Endpoints

Mercari is a single-page application built with Next.js, which means the DOM is rendered client-side and changes frequently. For individual product pages, I use a similar multi-selector approach as Amazon.

But the interesting part is searching for products on Mercari from the background service worker. Since content scripts are sandboxed to their page and can't make cross-origin requests, all search queries run from the background worker. Mercari exposes a search API endpoint that accepts JSON POST requests. When the direct API call succeeds, results come back as structured data with item IDs, names, prices, and thumbnails -- no HTML parsing needed.

When the API approach fails (and it does sometimes -- rate limiting, format changes, authentication requirements), the extension falls back to fetching the HTML search page and parsing it. This involves multiple strategies:

Extracting the __NEXT_DATA__ script tag, which contains the server-side rendered search results as JSON
Searching for item cell patterns in the HTML using regex
Recursively exploring state objects embedded in script tags

I also built what I call a "Hybrid Approach" for Mercari. When you're already on a Mercari search page, a floating button appears that says "Compare with Arbitra." Clicking it triggers the content script to extract search results directly from the rendered DOM -- no need for the background worker to re-fetch the page. Those results get sent to the background worker and merged with data from other platforms.

Yahoo Auctions: Auction-Specific Challenges

Yahoo Auctions adds complexity because items have both a current bid price and an optional buy-now price. The extension tries multiple URL formats (Yahoo has changed their search URL structure over time) and parses HTML to extract auction IDs, prices, and product names.

The parsing logic looks for auction IDs in the HTML using several regex patterns, then searches the surrounding HTML block for price and name information. It's not elegant, but it handles the reality of scraping a platform that wasn't designed for programmatic access.

Building Intelligent Search Queries

The naive approach to cross-platform search is to take the full product name from one platform and paste it into the search box of another. This fails badly. Amazon product titles are stuffed with SEO keywords, size specifications, and marketing language that no human would type into a search box.

Arbitra's query builder uses a priority system:

Brand + model number -- the most precise match. If the content script extracted both, use them.
Brand + cleaned keywords -- extract meaningful words from the product title, strip out noise.
Model number alone -- if the brand wasn't found.
Cleaned product name -- last resort, take the first 3 meaningful words.

The keyword extraction function strips out Japanese e-commerce noise words (shipping info, condition labels, promotional language), removes bracketed content, and filters out size/weight specifications:

function extractKeywords(productName: string): string {
  let cleaned = productName;

  // Remove bracketed content
  cleaned = cleaned.replace(/[brackets with content]/g, ' ');

  // Remove stop words (Japanese e-commerce terms)
  // "free shipping", "in stock", "genuine", "sale", etc.
  stopWords.forEach(word => {
    cleaned = cleaned.replace(new RegExp(word, 'gi'), ' ');
  });

  // Remove measurement specifications
  cleaned = cleaned.replace(/\d+(\.\d+)?\s*(mm|cm|kg|g|ml)/gi, ' ');

  // Take first 3 meaningful words
  const words = cleaned.split(/[\s separators]+/)
    .filter(w => w.length >= 2 && w.length <= 20)
    .slice(0, 3);

  return words.join(' ');
}

Relevance Scoring: Finding the Right Product in Search Results

Cross-platform search results are noisy. Search for "Sony WH-1000XM5" on Mercari and you'll get the headphones, but you'll also get cases, replacement ear pads, cables, and "I'm selling everything in this photo" bundle listings.

Each search result gets a relevance score based on several factors:

Model number match (+100 points) -- if the model number appears in the candidate product name. If the source product has a model number but the candidate doesn't contain it, that's a -30 penalty.
Brand match (+50 points) -- the brand name appears in the candidate.
Word overlap (+5 points per word) -- meaningful words from the source product name that appear in the candidate.
Negative patterns (up to -40 per pattern) -- accessory keywords (case, cover, film), compatibility phrases, bundle terms, and junk condition labels trigger penalties.

The negative pattern check is context-aware. If the source product itself is an accessory (say, a phone case), the penalty doesn't apply. This prevents the system from filtering out the exact type of product being searched for.

Results are sorted by relevance score, and the side panel displays the best match for each platform.

The Profit Scoring Algorithm

Once Arbitra has prices from multiple platforms, it calculates a profit score on a 0-100 scale with three verdicts: BUY (70+), CONSIDER (40-69), and PASS (below 40).

The score combines four components:

Factor	Max Points	Logic
Profit margin	40	30%+ margin = 40pts, 20%+ = 30pts, 10%+ = 20pts
ROI	30	50%+ ROI = 30pts, 30%+ = 20pts, 15%+ = 10pts
Price difference	20	3000+ yen gap = 20pts, 1000+ = 15pts, 500+ = 10pts
Competition	10	Reserved for future implementation

The calculation accounts for platform-specific fees. Amazon charges a referral fee (typically 8-15% depending on category) plus FBA fulfillment fees. Mercari takes a flat 10% cut. Yahoo Auctions charges 8.8% for premium members and 10% for regular members.

The side panel presents this as a color-coded card: green for BUY with a checkmark and the calculated profit amount, yellow for CONSIDER, red for PASS. Below that, a comparison table shows the numbers for both FBA (Fulfillment by Amazon) and self-shipping scenarios, so you can see which fulfillment method gives better margins.

The Watchlist: Tracking Prices Over Time

Arbitrage opportunities are time-sensitive. A price gap that exists today might close tomorrow, or it might widen. Arbitra's watchlist feature lets you track products over time.

When you find a product worth monitoring, you add it to the watchlist. The extension stores the product data -- ASIN, title, image, search query, and current prices across all three platforms -- in Chrome's local storage.

A background alarm fires every 60 minutes and re-checks prices for all active watchlist items. It runs searches against Mercari, Yahoo Auctions, and Amazon using the same search infrastructure, calculates price statistics (min, max, median, average), and stores daily price history entries.

The watchlist panel in the side panel displays each tracked product with its current prices and a price history chart built with Chart.js. If a price changes by more than 10%, the extension sends a Chrome notification. You can also set a target price -- when the average Mercari price drops below your target, you get notified immediately.

Price history is retained for 90 days, which is usually enough to spot seasonal patterns and identify the best timing for purchases.

State Management with Zustand

The side panel is a React application, and I chose Zustand for state management. It's a fraction of the size of Redux, has no boilerplate, and works well with Chrome extension messaging patterns.

The store holds prices, loading states, usage data, subscription status, and user settings. Zustand's selector pattern lets components subscribe to exactly the slice of state they need:

const useAppStore = create<AppState>((set) => ({
  prices: [],
  isLoading: false,
  subscription: { isPro: false },
  settings: {
    defaultCategory: 'default',
    isYahooPremium: false,
    defaultShippingCost: 200,
  },
  setPrices: (prices) => set({ prices }),
  setLoading: (isLoading) => set({ isLoading }),
  // ...
}));

The side panel listens for SEARCH_RESULTS_UPDATED messages from the background worker and updates the store. This triggers re-renders only in components that depend on the changed data. The profit score calculation runs as a callback when results change, comparing the lowest price across platforms against the highest to find the optimal buy-sell pair.

What I Learned About Scraping at Scale

Building Arbitra taught me a few hard lessons about web scraping in a browser extension context:

Rate limiting is real. Each search triggers at least two HTTP requests from the background worker. If a user clicks "analyze" rapidly on multiple products, the extension can get temporarily blocked by Mercari or Yahoo Auctions. I added a 3-second delay between watchlist price checks to avoid triggering rate limits during background updates.

HTML parsing is fragile. I have five different fallback strategies for parsing Mercari search results. The first one (API call) is the most reliable but doesn't always work. Each subsequent fallback handles a different scenario -- NEXT_DATA present, NEXT_DATA absent, different state management patterns, raw HTML with item links. This approach is ugly but resilient.

Content scripts and background workers have different capabilities. Content scripts can access the DOM but can't make cross-origin requests. The background worker can fetch from any domain but can't touch the DOM. The Hybrid Approach for Mercari search pages bridges this gap by having the content script extract DOM data and the background worker handle the aggregation.

SPA navigation breaks content scripts. Amazon, Mercari, and Yahoo Auctions all use client-side navigation in varying degrees. A MutationObserver watching for URL changes handles re-initialization when the user navigates to a different product page without a full page load.

The Tech Stack

For anyone curious about the full setup:

Build: Vite + CRXJS (Chrome extension Vite plugin)
Language: TypeScript throughout
UI: React 19 + Tailwind CSS 4
State: Zustand
Charts: Chart.js for price history visualization
Backend: Supabase (free tier) for price history persistence and user settings sync
Analytics: GA4 Measurement Protocol for install/update tracking
Payments: ExtensionPay for the Pro subscription

CRXJS deserves a mention. It lets you develop a Chrome extension with Vite's hot module replacement, which makes the development loop almost as fast as working on a regular web app. You write your manifest as a JSON import, and the plugin handles all the Chrome extension build gymnastics.

Usage Limits and the Freemium Model

The free tier allows 5 searches per day. Each search checks all three platforms in parallel, so it's 5 complete comparisons. The Pro tier removes this limit and adds price change notifications on the watchlist.

The daily limit is tracked in Chrome's local storage with a simple date-count structure. If the current date doesn't match the stored date, the count resets. Pro status is managed through ExtensionPay, which handles payment processing and license verification through a lightweight API.

Try It Out

If you do retail arbitrage between Japanese marketplaces, or if you're just curious about price differences across Amazon, Mercari, and Yahoo Auctions, give Arbitra a try. The free tier is enough to evaluate whether it fits your workflow.

Arbitra - せどり価格比較ツール | Amazon・メルカリ・ヤフオク一括比較 | S-Hub

dev-tools-hub.xyz

The extension is also available on Microsoft Edge Add-ons for Edge users.

If this was useful, I'd appreciate a like or a bookmark. Got questions about building Chrome extensions or scraping product pages? Drop a comment below.

Other tools I've built:

DataPick - No-Code Web Scraper & Data Extractor - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

DataBridge - Copy & Transfer Data Between Web Pages - Chrome Web Store

Copy and transfer data between web pages easily. Select fields, save reusable templates, and automate repetitive data entry.

chromewebstore.google.com

More Chrome Extensions from S-Hub

If you found this useful, check out my other free tools:

How to OCR Invoices for Free — Chrome Extension with No Cloud — Free Chrome extension

All 20+ tools are free at dev-tools-hub.xyz

How to Scrape Websites to Google Sheets — No Code Chrome Extension

SHOTA — Fri, 03 Apr 2026 09:44:42 +0000

You need competitive pricing data in a spreadsheet. Or a list of job postings filtered by location. Or metadata from dozens of blog articles.

So you reach for IMPORTXML or IMPORTHTML in Google Sheets. It works for about five minutes. Then the XPath breaks, the site updates its layout, or you realize the page is a single-page app that returns nothing useful to a server-side function.

Sound familiar?

In this article, I'll walk through how to use DataPick, a Chrome extension, to send web data directly to Google Sheets with zero code. No Python scripts, no Google Apps Script, no manual copy-paste. Just point, click, and export.

This article focuses specifically on the Google Sheets integration workflow. If you're new to DataPick and want a general overview, check out the introductory article.

The Problem with IMPORTXML and IMPORTHTML

Google Sheets has built-in functions for pulling data from web pages. In theory, =IMPORTXML(url, xpath) is all you need. In practice, these functions hit real-world limitations quickly.

XPath complexity. Writing correct XPath expressions requires inspecting the DOM, understanding the document structure, and often crafting fragile selectors that break when the site changes even slightly.

Static HTML only. IMPORTXML and IMPORTHTML make server-side requests. They receive the raw HTML before any JavaScript executes. If the page is built with React, Vue, Next.js, or any other framework that renders content client-side, these functions return empty results.

No authentication support. Need data from behind a login wall? A dashboard, an admin panel, a members-only directory? Server-side functions cannot access your browser session.

Rate limiting and caching issues. Google Sheets aggressively caches results and can trigger rate limits on target sites. You have limited control over when data refreshes.

No structural intelligence. If the HTML structure changes, your carefully crafted XPath silently returns wrong data or nothing at all. There is no mechanism to detect or adapt to structural changes.

Here's how DataPick compares on each of these points:

Limitation	IMPORTXML / IMPORTHTML	DataPick
Page type	Static HTML only	Works on JavaScript-rendered pages
Selector method	XPath (manual, fragile)	Point-and-click (visual)
Structural changes	XPath breaks silently	Auto-detects similar elements
Authenticated pages	Not supported	Uses your browser session
Data refresh	Automatic (less control)	Manual (on-demand)
Column naming	None	Auto-inferred from content

How DataPick's Google Sheets Integration Works

DataPick runs as a Chrome extension. You browse to any page, click on the data you want, and it identifies similar elements across the page. When you're ready, you export directly to Google Sheets with one click.

The key difference from formula-based approaches: DataPick operates on the rendered DOM. Whatever you see in your browser is what you can extract. This means SPAs, dynamically loaded content, infinite scroll pages, and authenticated dashboards all work.

Setup: Three Steps to Your First Export

Step 1: Install DataPick

Install DataPick from the Chrome Web Store. It works on any Chromium-based browser (Chrome, Edge, Brave, Arc).

Step 2: Select Your Data

Navigate to the page containing the data you want. Click the DataPick icon in your toolbar to activate selection mode.

Now click on any element you want to extract, for example, a product name. DataPick automatically detects similar elements on the page and highlights them. You'll see a widget showing the number of rows detected.

Click additional elements to add more columns. For instance, after selecting a product name, click a price to add a price column. DataPick auto-generates column names based on the content type.

For many popular sites, DataPick has built-in templates that pre-configure the column structure. Job boards, e-commerce sites, and real estate listings often have templates that activate automatically when you visit the page.

Step 3: Export to Google Sheets

At the bottom of the DataPick widget, click the Google Sheets export button. On your first export, you'll see a Google OAuth2 consent screen. Grant the following permissions:

Google Sheets read/write - to create and write data to spreadsheets
Google Drive file creation - to create new spreadsheet files

That's it. Two permissions, clearly scoped.

After authorization, DataPick creates a new spreadsheet named "DataPick Export - (date)" and populates it with your extracted data. A link to the spreadsheet appears immediately so you can open it.

Appending to existing sheets: You can also send data to a spreadsheet you've already created. This is useful for building up a dataset over time, for example, tracking prices weekly or accumulating job listings.

Practical Use Cases

Use Case 1: Job Market Research

Suppose you're tracking remote developer job postings across multiple job boards. Navigate to a job listing page on Indeed, LinkedIn Jobs, or any job board.

DataPick's built-in templates for major job sites auto-configure columns like job title, company, location, salary range, and URL. Select the data, click Google Sheets export, and you have a structured dataset ready for filtering and analysis.

With the pagination detection feature, you can process multi-page listings without manually navigating. Combine data from several pages, then export the full dataset to Sheets.

Once in Google Sheets, you can:

Filter by salary range or location
Create pivot tables by company or job type
Share the sheet with your team for collaborative research
Track new postings over time by appending to the same sheet

Use Case 2: E-Commerce Price Comparison

Price monitoring is a common use case for web data extraction. With DataPick, you can pull product names, prices, ratings, and review counts from e-commerce sites.

Built-in templates exist for major platforms, providing pre-configured column structures. For example, on a product comparison page, you might get columns for product name, lowest price, average price, review count, rating, and product URL.

The diff detection feature is particularly valuable here. When you extract data from the same page again, DataPick highlights what changed since your last extraction: price increases, price drops, new products, and removed listings.

Export to Google Sheets periodically, and you build a price history. Combine this with Google Sheets' built-in charting to visualize trends over time.

DataPick also supports exporting in CSV formats compatible with major e-commerce platforms (Amazon Seller Central, Shopify, etc.), making it useful for sellers who need to monitor competitor pricing.

Use Case 3: Content and Article Metadata Collection

If you're doing content research, competitive analysis, or building a reading list, you often need to extract article titles, URLs, publication dates, and authors from blog listing pages.

Even on sites without built-in templates, the point-and-click interface works well. Select a title, and DataPick identifies all titles on the page. Add a date column, an author column, and a URL column. Column names are auto-inferred from the content.

Save your configuration as a recipe. The next time you visit the same site, the recipe auto-applies, making repeat extractions effortless. Recipes can also be exported as JSON files and shared with team members.

Use Case 4: Aggregating Data from Multiple Sites

The Memo feature lets you collect data across different websites before exporting. Here's the workflow:

Visit Site A, extract product data, and save it to Memo
Visit Site B, extract comparable data, and add it to Memo
Review all collected entries in the Memo panel
Export the combined dataset to Google Sheets in one action

Memo holds up to 100 entries and supports TSV, CSV, and plain text formats in addition to Google Sheets export. This is ideal for cross-site comparison tasks where you need a unified dataset.

Google Sheets vs. Other Export Options

DataPick supports multiple export formats. Here's when to use each:

Export Method	Best For	Key Advantage
Google Sheets	Team collaboration, recurring data collection	Direct integration, no file management
CSV download	Local analysis, importing into other tools	Lightweight, universal compatibility
Excel (.xlsx)	Business reports, formatted documents	Preserves formatting, opens natively in Excel
JSON download	Developer workflows, API mocking	Machine-readable, structured data

Google Sheets is the best choice when you need to:

Share data with non-technical team members
Build up a dataset over multiple extraction sessions
Apply Google Sheets formulas, charts, or pivot tables immediately
Integrate with other Google Workspace tools

CSV or Excel makes more sense when you're working offline, need to import into a non-Google tool, or want a static snapshot.

Free vs. Pro: What You Get

The free tier includes 3 exports per day with a 5-row preview limit. For occasional use, this is sufficient.

If you're doing regular data collection (daily price monitoring, weekly job market research, ongoing competitive analysis), the Pro plan removes these limits and unlocks the full feature set.

A Note on Responsible Scraping

DataPick is a browser-based tool, not an automated bot. It operates within your normal browsing session, so the server load is identical to regular browsing. However, responsible data collection still matters:

Check the site's terms of service before extracting data at scale
Respect robots.txt directives
Be mindful of personal data - if your extracted data contains PII, ensure you comply with applicable privacy regulations (GDPR, CCPA, etc.)
Consider copyright - the intended use of collected data should not infringe on intellectual property rights

Because DataPick requires manual interaction (you click to extract), it naturally avoids the aggressive request patterns that cause issues with automated scrapers.

Wrapping Up

If you've been struggling with broken IMPORTXML formulas, writing Python scrapers you don't want to maintain, or manually copying data into spreadsheets, DataPick's Google Sheets integration offers a practical alternative.

The workflow is straightforward:

Browse to the page with the data you need
Click on the elements to define your columns
Export to Google Sheets with one click

It handles JavaScript-rendered pages, authenticated sessions, and structural changes - the exact scenarios where server-side formulas fail. Built-in templates for popular sites mean zero configuration for common tasks, and recipes let you save and reuse your custom setups.

Give it a try and see how it fits into your data collection workflow.

DataPick - No-Code Web Scraper & Data Extractor - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

Other tools I've built:

DataBridge - Copy & Transfer Data Between Web Pages - Chrome Web Store

Copy and transfer data between web pages easily. Select fields, save reusable templates, and automate repetitive data entry.

chromewebstore.google.com

OnPageX - On-Page SEO Analyzer & Meta Tag Checker - Chrome Web Store

Analyze meta tags, headings, schema markup, images & links in one click. Get SEO scores, find issues & export reports. Free forever.

chromewebstore.google.com

More Chrome Extensions from S-Hub

If you found this useful, check out my other free tools:

Best Cookie Editor for Chrome in 2026 — EditThisCookie Alternative — Free Chrome extension

All 20+ tools are free at dev-tools-hub.xyz

How to OCR Invoices for Free — Chrome Extension with No Cloud

SHOTA — Wed, 01 Apr 2026 10:00:08 +0000

Every freelancer knows the drill. A PDF invoice arrives. You open it, squint at the numbers, then manually type the vendor name, amounts, tax breakdowns, and registration IDs into a spreadsheet or accounting app. Repeat twenty times a month.

Cloud OCR services like Dext (formerly Receipt Bank), Hubdoc, or Veryfi can automate this, but they start at $10-50/month, require uploading your financial documents to third-party servers, and often lock your data behind proprietary formats.

I wanted something different: an invoice reader that runs entirely in the browser, processes everything locally, costs nothing, and works the moment you install it. So I built one as a Chrome extension.

This article covers the technical decisions behind it: how to extract text from PDFs inside a Chrome extension, how to handle scanned invoices with in-browser OCR, how to parse unstructured invoice text into structured data with regex, and how to verify tax registration numbers against a government API in real time.

The Architecture: A 4-Layer Processing Pipeline

The core challenge with invoice PDFs is that they vary wildly. Some have selectable text embedded by the authoring tool. Others are scanned images with no text layer at all. And even when text is present, the quality can be poor -- garbled characters, misaligned columns, or encoding issues.

To handle this reliably, I built a 4-layer fallback pipeline. Each layer attempts extraction, evaluates the result quality, and either returns the data or passes control to the next layer.

Layer 1: PDF.js text extraction (local)
  → quality score >= 50? → done
  ↓
Layer 2: PaddleOCR → Tesseract.js fallback (local)
  → quality score >= 40? → done
  ↓
Layer 3: Proxy AI extraction (optional, cloud)
  → success? → done
  ↓
Layer 4: BYOK - Bring Your Own Key (optional, user's API key)

For the vast majority of digitally-generated invoices, Layer 1 handles everything. Layer 2 kicks in for scanned PDFs. Layers 3 and 4 are optional cloud-assisted paths for edge cases like handwritten invoices or heavily formatted PDFs where local processing falls short.

The important point: Layers 1 and 2 are completely local. No data leaves the browser.

Layer 1: PDF.js Text Extraction in a Chrome Extension

Using PDF.js inside a Chrome extension is not as straightforward as importing it in a web app. Chrome extensions run in a service worker context (Manifest V3), which has no DOM access and no <canvas> element. PDF.js needs a canvas for rendering and a worker thread for parsing.

The solution: an offscreen document. Chrome's Offscreen Documents API (introduced in MV3) lets you create a hidden HTML page with full DOM access. The service worker sends PDF data to the offscreen document, which runs PDF.js with its web worker, and returns the extracted text.

content script (detects PDF)
  → sends URL to service worker
    → service worker fetches PDF as ArrayBuffer
      → converts to base64
        → sends to offscreen document via Port
          → offscreen runs PDF.js with web worker
            → returns extracted text + quality score

The text extraction itself goes beyond a naive getTextContent() call. PDF text items have transform matrices that encode position, and you need to reconstruct the reading order from spatial coordinates. Here is the approach:

Track Y-coordinate changes between text items to detect line breaks
Track X-coordinate gaps within the same line to insert tab separators (for table-like data)
Use font size as a reference for gap thresholds -- a gap wider than 30% of the font size becomes a tab, anything smaller becomes a space

This spatial reconstruction is critical for invoices because they are essentially tables. Without it, you get a flat string where vendor names run into amounts and tax rates blend into dates.

Quality Scoring

Not all PDFs yield usable text. Some have copy-protection that strips text layers. Others encode text as glyph paths. The pipeline needs to know whether to trust the Layer 1 output or fall through to OCR.

I built a quality scoring function that evaluates the extracted text on multiple axes:

Japanese character density: What percentage of characters are CJK? (Since this targets Japanese invoices, a high ratio is a good signal.)
Amount pattern detection: Does the text contain currency patterns like ¥1,234 or comma-separated numbers?
Invoice keyword presence: Are terms like "total," "tax," "subtotal," or "invoice number" present?
Text volume: Is there enough text to represent a complete invoice?

Each axis contributes to a score out of 100. If the score exceeds 50, the text is considered reliable. Below that, Layer 2 takes over.

Layer 2: In-Browser OCR with PaddleOCR and Tesseract.js

For scanned PDFs, the extension renders each page to an image using PDF.js (via OffscreenCanvas in the offscreen document), then feeds those images to an OCR engine.

The OCR pipeline itself has a two-engine fallback:

PaddleOCR runs first. It tends to produce better results for dense CJK text.
If PaddleOCR fails or returns empty output, Tesseract.js (v7, with WASM backend) takes over.

Both engines run entirely in the browser. Tesseract.js loads language models on first use and caches them. There is no server round-trip.

The offscreen document is essential here too -- Tesseract.js needs WASM execution, which requires a document context. The offscreen document's reasons field is set to WORKERS to justify its creation to Chrome.

Parsing Invoice Fields with Regex

Once you have raw text -- whether from PDF.js or OCR -- you need to extract structured fields: vendor name, invoice number, issue date, total amount, tax breakdowns, bank details, and registration numbers.

This is where things get messy. Invoices have no standard format. Every company uses its own layout, terminology, and conventions. I ended up with a regex-first approach: a collection of patterns for each field, tried in priority order.

For example, the total amount extractor tries patterns like:

Japanese keywords followed by amounts: patterns matching "total amount," "invoice amount," "tax-inclusive total," etc.
Yen symbol followed by a number at the end of a line

Each pattern handles both half-width and full-width characters (a common headache in Japanese text processing -- ¥ vs ￥, 0-9 vs ０-９).

Full-Width / Half-Width Normalization

Japanese invoices freely mix full-width and half-width characters. A registration number might appear as Ｔ１２３４５６７８９０１２３ (all full-width) or T1234567890123 (all half-width) or any combination. The field extractor normalizes everything to half-width after matching:

result.registrationNumber = match[0]
  .replace(/Ｔ/, 'T')
  .replace(/[０-９]/g, (ch) =>
    String.fromCharCode(ch.charCodeAt(0) - 0xfee0),
  );

The 0xFEE0 offset is the Unicode distance between full-width digits (０ = U+FF10) and their ASCII equivalents (0 = U+0030).

Vendor Name Extraction: A 5-Pattern Cascade

Extracting the vendor name is the hardest field because there is no universal keyword. Instead, the extractor uses contextual heuristics:

Same-line split: If the text has "Recipient Corp. + honorific + Vendor Corp." on one line, split at the honorific.
Next-line detection: Look for a company name on the line following the recipient's name.
Proximity to registration number: Company names often appear just above the tax registration number.
Global search: Find any line containing a corporate suffix (Inc., Ltd., Corp., LLC, etc.) that is not the recipient.
English company names: Match patterns ending with Inc., LLC, Corp., Ltd., etc.

This cascade handles around 90% of invoice layouts I have tested. The remaining edge cases fall to the AI-assisted layers.

Real-Time Tax Registration Verification

Japan's Qualified Invoice System (introduced in October 2023) requires businesses to verify that their vendors hold a valid tax registration number. The National Tax Agency (NTA) provides a public API for this:

GET https://web-api.invoice-kohyo.nta.go.jp/1/num?id=T1234567890123&type=21

The extension calls this API directly from the service worker. No backend proxy needed -- the NTA API supports CORS and is publicly accessible. The response includes:

Registration status (valid / expired)
Registered business name
Registration date
Expiration date (if revoked)

Results are cached in memory for 24 hours to minimize API calls. The extension validates the format locally first (/^T\d{13}$/) before making any network request.

Why This Matters Beyond Japan

While the specific API is Japan-specific, the pattern is universally applicable. Many countries have similar tax registration verification systems:

EU VAT: VIES (VAT Information Exchange System)
UK: HMRC VAT check
India: GSTIN verification
Australia: ABN Lookup

The architecture -- extract a registration number from an invoice, validate its format locally, then verify against a government API -- translates directly to any of these systems. The regex patterns and API endpoint change, but the pipeline stays the same.

The Chrome Extension Constraints That Shaped the Design

Building this as a Chrome extension rather than a web app introduced several constraints that directly influenced the architecture:

No DOM in Service Workers

Manifest V3 service workers cannot access document, canvas, or any DOM API. PDF.js and Tesseract.js both need DOM access. The offscreen document pattern solves this, but it adds communication overhead -- every PDF operation requires serializing data to base64, sending it through a Port, and deserializing on the other side.

Message Size Limits

Chrome's runtime.sendMessage has undocumented size limits. For large PDFs, the base64-encoded data can exceed these limits. I switched to runtime.connect() (long-lived Ports) for all offscreen communication, which handles larger payloads reliably.

Single Offscreen Document

Chrome only allows one offscreen document at a time per extension. This means PDF.js text extraction and Tesseract.js OCR share the same offscreen document. The document multiplexes requests using a request ID system -- each message gets a unique _id, and responses are routed back to the correct promise via a Map.

Content Script PDF Detection

The content script runs on all URLs and checks three signals to detect PDFs:

URL ends with .pdf
document.contentType === 'application/pdf'
An <embed> element with type="application/pdf" exists

When a PDF is detected, the extension's toolbar icon gets a "PDF" badge, signaling to the user that they can open the side panel to process the invoice.

Privacy-First Design

For an invoice processing tool, privacy is non-negotiable. Financial documents contain bank account numbers, tax IDs, revenue figures, and vendor relationships. Uploading these to a cloud OCR service is a real risk.

The extension's default mode (Layers 1 and 2) keeps everything local:

PDF data is processed in the offscreen document and never leaves the browser
OCR runs via WASM -- no external API calls
Extracted data is stored in IndexedDB (via Dexie.js) on the user's machine
The only external network call is the NTA API for registration verification, which sends only the 14-character registration number

The optional cloud layers (3 and 4) exist for users who need AI-assisted extraction of complex invoices. Layer 3 uses a managed proxy. Layer 4 lets users provide their own OpenAI API key, so the data goes directly from their browser to OpenAI without passing through any intermediary.

Export: Meeting Users Where They Are

Extracted invoice data is only useful if it flows into existing workflows. The extension supports multiple export formats:

CSV with customizable column mappings
Excel (XLSX) via the SheetJS library
JSON for developers and API integrations
Clipboard for quick paste into any application
Accounting software presets for popular Japanese accounting tools (freee, Money Forward, Yayoi)

Each preset maps the extracted fields to the specific column format expected by the target software, so users can import directly without manual column mapping.

The Tech Stack

Component	Technology	Purpose
Framework	WXT (Vite-based)	Chrome extension build tooling
UI	React 18 + Tailwind CSS	Side panel interface
PDF parsing	pdfjs-dist v5	Text extraction + page rendering
OCR (primary)	PaddleOCR	CJK-optimized text recognition
OCR (fallback)	Tesseract.js v7	WASM-based OCR engine
State	Zustand	Lightweight state management
Storage	Dexie.js (IndexedDB)	Local invoice data persistence
Spreadsheet	SheetJS (xlsx)	Excel export
CSV	PapaParse	CSV generation with encoding support
i18n	i18next + react-i18next	Japanese/English interface
Monetization	ExtPay	Payment processing

What I Learned

Quality scoring is essential. Without a way to measure extraction quality, you cannot build a reliable fallback pipeline. The scoring function was one of the earliest pieces I wrote and has been the most stable.

Offscreen documents are powerful but awkward. The communication pattern between service worker and offscreen document adds significant complexity. If Chrome ever adds DOM access to service workers (unlikely), this entire layer would collapse into something much simpler.

Regex beats ML for structured extraction -- sometimes. For fields with clear syntactic patterns (dates, amounts, registration numbers), regex is faster, more predictable, and requires no model loading. ML/AI shines for unstructured fields (vendor names, line item descriptions) where context matters more than syntax.

Full-width/half-width normalization is not optional in Japanese text processing. Every string comparison, every regex match, every format validation needs to handle both character widths. This was a source of subtle bugs early on.

Try It

The extension is free on the Chrome Web Store:

請求書よみとり - AI-OCR PDF請求書データ抽出 | インボイス制度・電帳法対応 | 無料Chrome拡張機能 | S-Hub

PDF請求書をAI-OCRで自動読み取り。金額・日付・取引先・登録番号を抽出しCSV/Excelにエクスポート。インボイス制度対応・電子帳簿保存法対応。2026年10月控除率変更にも対応の無料Chrome拡張機能。

dev-tools-hub.xyz

It works on any Chromium-based browser (Chrome, Edge, Brave, Arc). Open a PDF invoice in your browser, click the extension icon to open the side panel, and it extracts the data automatically. No account creation, no cloud upload, no subscription.

If you are building Chrome extensions that process documents, I hope the patterns described here -- offscreen document communication, quality-based fallback pipelines, spatial text reconstruction -- are useful starting points.

Questions or feedback? Drop a comment below or open an issue on the project.

Other tools I've built:

DataPick - No-Code Web Scraper & Data Extractor - Chrome Web Store

Scrape data from any website with point-and-click. Export to CSV, Excel, or Google Sheets. No coding required.

chromewebstore.google.com

DataBridge - Copy & Transfer Data Between Web Pages - Chrome Web Store

Copy and transfer data between web pages easily. Select fields, save reusable templates, and automate repetitive data entry.

chromewebstore.google.com

More Chrome Extensions from S-Hub

If you found this useful, check out my other free tools:

All 20+ tools are free at dev-tools-hub.xyz

How to Use Email Templates in Gmail — Free Chrome Extension

SHOTA — Mon, 30 Mar 2026 10:08:29 +0000

If you've ever built a Chrome extension that touches Gmail's UI, you know the pain. Obfuscated class names, aggressive keyboard event capturing, mutation storms that freeze your tab — Gmail is a hostile environment for extension developers.

I spent weeks building SnapReply for Gmail, a template insertion extension that lets you fire off common email replies in seconds. Along the way, I accumulated a collection of hard-won lessons about wrangling Gmail's DOM. This article shares the technical challenges and the patterns I used to solve them.

The Problem: Email Replies Are Repetitive

Most knowledge workers send dozens of emails a day, and a surprising number of those are near-identical responses. Gmail does have a built-in Templates feature (formerly Canned Responses), but it's buried under menus and lacks variable support, shortcuts, or any real customization.

I wanted something that would let me type /thanks in a compose window and have it instantly expand into a full response — complete with dynamic dates, recipient names, and conditional blocks. That meant building a content script that deeply integrates with Gmail's compose UI.

Here's where the fun begins.

Challenge 1: Selector Fallback Chains

Gmail's UI isn't built with React, Vue, or any public framework. It uses Google's proprietary closure-based rendering system. Class names like .AD, .nH, and .Am.aiL are generated by an internal build tool and can change with any deployment.

Relying on a single CSS selector is a recipe for your extension breaking every few weeks. Instead, I built a tiered selector system that tries semantically stable selectors first and falls back to fragile class-based ones:

type SelectorTier = {
  primary: string;
  fallbacks: string[];
};

const SELECTORS = {
  composeBody: {
    primary: '[role="textbox"][aria-label][g_editable="true"]',
    fallbacks: [
      'div[aria-label][contenteditable="true"][g_editable="true"]',
      '.Am.aiL',
      'div[contenteditable="true"].editable',
    ],
  } as SelectorTier,
  composeToolbar: {
    primary: 'tr.btC td.gU',
    fallbacks: ['.btC .gU', 'td.gU.aXw'],
  } as SelectorTier,
  // ... more selectors
};

function querySelector(
  selector: GmailSelector,
  root: Element | Document = document
): Element | null {
  const tier = SELECTORS[selector];
  const el = root.querySelector(tier.primary);
  if (el) return el;

  for (const fallback of tier.fallbacks) {
    const found = root.querySelector(fallback);
    if (found) return found;
  }
  return null;
}

The key insight: WAI-ARIA attributes (role, aria-label) and Gmail-specific attributes (g_editable) are far more stable than class names. Google rarely changes accessibility attributes because doing so would break their own internal testing and screen reader support. The obfuscated class names are only there as a last resort.

This pattern has kept the extension working through multiple Gmail updates without code changes.

Challenge 2: MutationObserver — The attributes Trap

To detect when a user opens a new compose window, I use a MutationObserver on document.body. This seems straightforward, but there is one critical configuration mistake that will freeze the entire Gmail tab:

this.observer = new MutationObserver(() => {
  if (this.debounceTimer) clearTimeout(this.debounceTimer);
  this.debounceTimer = setTimeout(() => this.scanForComposes(), 50);
});

this.observer.observe(document.body, {
  childList: true,
  subtree: true,
  // NEVER add attributes: true — causes infinite loops on Gmail
});

Never set attributes: true when observing Gmail's DOM tree. Gmail constantly mutates element attributes — style changes, ARIA state updates, internal state flags — at an extraordinary rate. Enabling attribute observation triggers an avalanche of mutation callbacks that creates a positive feedback loop, effectively hanging the browser tab.

The comment you see in the code isn't just documentation; it's a scar from a debugging session that cost me an entire afternoon.

Two additional patterns help here:

Debouncing the callback at 50ms to batch rapid DOM changes into a single scan
WeakMap-based tracking to avoid processing the same compose window twice:

private trackedComposes = new WeakMap<Element, boolean>();

private scanForComposes(): void {
  const composes = querySelectorAll('composeContainer');
  for (const el of composes) {
    if (!this.trackedComposes.has(el)) {
      this.trackedComposes.set(el, true);
      this.onNewCompose(el);
    }
  }
}

Using WeakMap instead of a Set means compose elements are automatically garbage-collected when Gmail removes them from the DOM, preventing memory leaks in long-lived sessions.

Challenge 3: Gmail Hijacks Your Keyboard Events

Gmail has aggressive global keyboard shortcuts. Press c anywhere on the page and it opens a new compose window. Press e and it archives the current conversation. This is great for power users, but terrible for extension developers who need text input fields.

When I added a search bar to filter templates, typing c would open a compose window instead of inserting the letter. Gmail captures keyboard events at the document level before they reach your input elements.

The fix is to stop event propagation on every keyboard-related event:

const stopGmailCapture = (
  e: React.KeyboardEvent | React.CompositionEvent
) => {
  e.stopPropagation();
};

// Applied to every input element:
<input
  onKeyDown={stopGmailCapture}
  onKeyUp={stopGmailCapture}
  onKeyPress={stopGmailCapture}
  onCompositionStart={stopGmailCapture}
  onCompositionUpdate={stopGmailCapture}
  onCompositionEnd={stopGmailCapture}
  // ...
/>

Notice the three composition* event handlers. These are critical for CJK (Chinese/Japanese/Korean) input methods (IMEs). Without them, typing in Japanese or Chinese triggers Gmail shortcuts during the composition phase, producing garbled input or unexpected Gmail actions. If your extension has any international user base, you cannot skip these.

Challenge 4: Shadow DOM for Style Isolation

Gmail's CSS is enormous and opinionated. If you inject a regular DOM element, Gmail's styles will immediately override your carefully crafted UI. Conversely, your styles might break Gmail's layout.

The solution is Shadow DOM with an aggressive reset:

const host = document.createElement('div');
host.id = 'snapreply-root';
document.body.appendChild(host);

const shadowRoot = host.attachShadow({ mode: 'closed' });

const sheet = new CSSStyleSheet();
sheet.replaceSync(`:host { all: initial; }\n${contentCss}`);
shadowRoot.adoptedStyleSheets = [sheet];

Three things to note:

:host { all: initial; } resets every inherited CSS property. Without this, Gmail's font sizes, colors, and line heights leak into your shadow tree.
mode: 'closed' prevents Gmail's scripts from reaching into your shadow root via element.shadowRoot.
adoptedStyleSheets injects your CSS (I use Tailwind) without <style> tags, which is more performant for constructable stylesheets.

This approach means your extension's UI is a completely self-contained island inside Gmail's page. No style conflicts, no z-index wars, no specificity battles.

Challenge 5: Template Insertion and the execCommand Dilemma

Gmail's compose editor is a contenteditable div — essentially a rich text editor built on browser primitives. When you insert HTML into it, you need to consider undo/redo support. If you naively set innerHTML, the user loses their entire undo history.

The strategy is a two-tier fallback:

function insertAtCursor(body: HTMLElement, html: string): boolean {
  // Tier 1: execCommand for undo support
  try {
    const success = document.execCommand('insertHTML', false, html);
    if (success) return true;
  } catch {
    // Fall through to Range API
  }

  // Tier 2: Range API (no undo support, but reliable)
  const selection = window.getSelection();
  if (selection && selection.rangeCount > 0) {
    const range = selection.getRangeAt(0);
    range.deleteContents();
    const frag = range.createContextualFragment(html);
    range.insertNode(frag);
    range.collapse(false);
    return true;
  }

  return false;
}

Yes, document.execCommand is officially deprecated. But for contenteditable environments, it remains the only way to insert HTML while preserving the browser's native undo stack. The Clipboard API and Input Events Level 2 spec offer insertReplacementText and insertFromPaste, but browser support is inconsistent and Gmail's editor doesn't respond to them reliably.

There is also a subtlety with setting the subject line. Gmail uses React-like controlled inputs where setting .value directly doesn't trigger internal state updates. You need to use the native property setter:

const nativeSetter = Object.getOwnPropertyDescriptor(
  HTMLInputElement.prototype, 'value'
)?.set;

if (nativeSetter) {
  nativeSetter.call(subjectInput, subject);
} else {
  subjectInput.value = subject;
}

subjectInput.dispatchEvent(new Event('input', { bubbles: true }));
subjectInput.dispatchEvent(new Event('change', { bubbles: true }));

This bypasses any framework-level getter/setter overrides and ensures Gmail's internal model sees the change.

Challenge 6: Shortcut Expansion in contenteditable

One of SnapReply's features is slash-command shortcuts: type /thanks and press Space, and it expands into a full template. Implementing this inside a contenteditable div is trickier than it sounds.

You can't just listen for input events and regex the entire textContent — that would be O(n) on every keystroke and would fail with rich text nodes. Instead, the watcher reads only the text node at the current cursor position:

private getTextBeforeCursor(): string | null {
  const sel = window.getSelection();
  if (!sel || sel.rangeCount === 0) return null;

  const range = sel.getRangeAt(0);
  if (!range.collapsed) return null;

  const textNode = range.startContainer;
  if (textNode.nodeType !== Node.TEXT_NODE) return null;

  return (textNode.textContent || '').slice(0, range.startOffset);
}

When a match is found and the user hits Space, the watcher needs to surgically remove just the shortcut text and replace it with the template. This uses Range API manipulation on the specific text node — deleting only the /keyword characters and repositioning the cursor at the deletion point before the template engine takes over.

Bonus: Dark Mode Detection Without Gmail APIs

Gmail doesn't expose a public API for its current theme. To support dark mode, I calculate the perceived luminance of document.body's background color:

function isGmailDarkMode(): boolean {
  const bg = getComputedStyle(document.body).backgroundColor;
  const match = bg.match(/\d+/g);
  if (!match || match.length < 3) return false;
  const [r, g, b] = match.map(Number);
  const luminance = (0.299 * r + 0.587 * g + 0.114 * b) / 255;
  return luminance < 0.5;
}

This uses the standard luminance formula (ITU-R BT.601) and works regardless of which specific dark theme the user has selected. Simple, but effective.

Lessons Learned

After building SnapReply, here are the principles I'd share with anyone building a Gmail extension:

Never trust class names. Use ARIA roles, name attributes, and Gmail-specific attributes as your primary selectors. Keep class-based selectors only as fallbacks.
Fear the MutationObserver. Gmail's DOM is volcanic. Observe only childList changes, debounce aggressively, and use WeakMap to deduplicate.
Stop all event propagation. Gmail's keyboard handling is greedy. If you render any interactive UI, call stopPropagation() on every keyboard and composition event.
Use Shadow DOM with :host { all: initial }. This is non-negotiable for any extension injecting UI into Gmail.
execCommand is deprecated but not dead. For contenteditable undo support, it's still the most reliable option in 2026.
Test with IME input. If you only test with a Latin keyboard, you'll miss composition event bugs that affect a large portion of your potential user base.

Try It Out

If you spend any amount of time replying to emails, give SnapReply a try. The free tier includes 10 templates with slash-command shortcuts, variable support, and folder organization — enough to cover most people's daily reply patterns.

SnapReply for Gmail - Email Templates - Chrome Web Store

Save & insert Gmail templates in one click. Canned responses, variables, rich text & shortcuts. Boost email productivity for free.

chromewebstore.google.com

If you've built a Gmail extension yourself, I'd love to hear what traps you fell into. Drop a comment below — misery loves company when it comes to Gmail's DOM.

Other tools I've built:

SnippetVault - Code Snippet Manager & Saver for Developers - Chrome Web Store

Save code snippets from any webpage with one click. Syntax highlighting, tags, search & one-click copy. Free tool for developers.

chromewebstore.google.com

PageMemo - Notes for Web Pages & URL-Linked Memos - Chrome Web Store

Take notes linked to specific web pages. Auto-save, no account required. Your notes appear when you revisit the page.

chromewebstore.google.com

More Chrome Extensions from S-Hub

If you found this useful, check out my other free tools:

All 20+ tools are free at dev-tools-hub.xyz