DEV Community: SHOTA

I Built a Scroll Position Memory Extension That Actually Works on SPAs

SHOTA — Wed, 22 Apr 2026 15:16:02 +0000

Every browser has a native scroll restoration feature. It's called scroll-restoration in the History API, it's enabled by default, and it mostly doesn't work on modern web apps.

The reason is Single Page Applications. When React Router or Next.js handles navigation client-side, the browser never gets a full page load event to trigger its scroll restoration logic. You go back to a long article you were halfway through and land at the top. Every time.

I built ReadMark to fix this reliably, and it turned out to be a more interesting engineering problem than I expected.

Basic Approach: URL-Keyed Position Storage

The obvious solution: save window.scrollY for the current URL before the user leaves, restore it when they return.

// Save position on scroll (debounced)
const savePosition = debounce(async (url: string) => {
  const result = await chrome.storage.local.get('positions');
  const positions = result.positions ?? {};

  positions[url] = {
    position: window.scrollY,
    savedAt: Date.now(),
  };

  await chrome.storage.local.set({ positions });
}, 500);

window.addEventListener('scroll', () => savePosition(window.location.href));

On page load, check if there's a saved position:

async function restorePosition(): Promise<void> {
  const url = window.location.href;
  const result = await chrome.storage.local.get('positions');
  const saved = result.positions?.[url];

  if (!saved) return;

  const expiryTime = POSITION_EXPIRY_DAYS * 24 * 60 * 60 * 1000;
  if (Date.now() - saved.savedAt > expiryTime) return; // Expired

  if (saved.position > 100) { // Skip near-top restores
    window.scrollTo({ top: saved.position, behavior: 'instant' });
    showToast('📖 Resumed from where you left off');
  }
}

This works fine for traditional server-rendered sites. The content is in the DOM when the page loads, the scroll works. Done.

The SPA Problem

SPAs break this in two ways:

Problem 1: URL changes without full page reload. When you navigate within a React app, the URL updates via history.pushState, but no real navigation happens. The extension's document_idle injection point fires once at initial load, not on each client-side route change.

Problem 2: Content isn't ready when you try to scroll. Even if you detect the URL change, the page content might still be loading. Scrolling to position 2000px does nothing if there's only 800px of content in the DOM.

Detecting Client-Side Navigation

The History API lets you intercept pushState and replaceState:

function patchHistoryAPI(): void {
  const originalPushState = history.pushState.bind(history);
  const originalReplaceState = history.replaceState.bind(history);

  history.pushState = function (state, title, url) {
    const prevUrl = window.location.href;
    originalPushState(state, title, url);
    handleNavigation(prevUrl, window.location.href);
  };

  history.replaceState = function (state, title, url) {
    const prevUrl = window.location.href;
    originalReplaceState(state, title, url);
    // replaceState often updates hash/query without intent to navigate
    // Only handle if pathname changed
    if (new URL(prevUrl).pathname !== new URL(window.location.href).pathname) {
      handleNavigation(prevUrl, window.location.href);
    }
  };

  // Handle browser back/forward
  window.addEventListener('popstate', () => {
    handleNavigation(null, window.location.href);
  });
}

The replaceState case needs care — many SPAs call replaceState to update query parameters without actual navigation intent. Checking if the pathname changed avoids spurious position resets.

Waiting for Content to Be Ready

When a navigation fires, the new content isn't rendered yet. I need to wait until the DOM has enough content at the target scroll depth:

async function waitForScrollable(targetPosition: number): Promise<void> {
  const maxWait = 3000;
  const interval = 100;
  let elapsed = 0;

  return new Promise((resolve) => {
    const check = () => {
      const documentHeight = document.documentElement.scrollHeight;
      if (documentHeight >= targetPosition + window.innerHeight) {
        resolve();
        return;
      }

      elapsed += interval;
      if (elapsed >= maxWait) {
        resolve(); // Give up and try anyway
        return;
      }

      setTimeout(check, interval);
    };
    check();
  });
}

Wait until the document is tall enough to contain the target scroll position, with a 3-second timeout. If the page never gets there, attempt the scroll anyway — better than doing nothing.

Position Expiry and Storage Management

Storing every visited URL forever would bloat chrome.storage.local. I expire positions after a configurable number of days and run cleanup periodically:

async function cleanupExpiredPositions(): Promise<void> {
  const result = await chrome.storage.local.get('positions');
  const positions: Record<string, SavedPosition> = result.positions ?? {};
  const expiryMs = POSITION_EXPIRY_DAYS * 24 * 60 * 60 * 1000;
  const now = Date.now();

  const cleaned = Object.fromEntries(
    Object.entries(positions).filter(
      ([, pos]) => now - pos.savedAt < expiryMs
    )
  );

  await chrome.storage.local.set({ positions: cleaned });
}

The cleanup runs in the service worker on a daily alarm. chrome.storage.local has a 10MB quota — with typical URL lengths and position data, you'd need to visit ~50,000 pages before hitting it, but cleanup keeps things tidy.

The Context Invalidation Edge Case

Chrome extensions get their service worker terminated when idle. If the user navigates while the service worker is waking up, chrome.runtime.id can be undefined briefly, causing any Chrome API call to throw:

function isContextValid(): boolean {
  try {
    return !!chrome.runtime?.id;
  } catch {
    return false;
  }
}

// In content script, guard all chrome.* calls
if (!isContextValid()) return;

This null-guard is easy to overlook and causes silent failures. The extension appears broken with no error in the console — the call just throws, the try-catch swallows it, and the scroll never happens.

What's Live

ReadMark v1.1 is on the Chrome Web Store. The SPA support works on Next.js, React Router, Vue Router, and Nuxt. Frameworks that use hash-based routing (/#/path) work out of the box since those trigger hashchange events which are caught separately.

Built with TypeScript + Vite. No frameworks — the content script is vanilla TS for minimal overhead.

I Built a Chrome Extension That Remembers Where You Stopped Reading

SHOTA — Wed, 22 Apr 2026 09:00:00 +0000

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

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

The Core Problem: Scroll Position Is Not a URL

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

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

The more reliable approach is document fraction position:

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

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

Challenge 1: Restoration Timing

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

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

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

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

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

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

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

Challenge 2: SPA Navigation Detection

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

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

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

Challenge 3: Auto-Save Without Spamming Storage

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

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

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

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

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

Challenge 4: Storage Key Normalization

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

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

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

UX Decision: When to Show the Restore Banner

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

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

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

Try ReadMark

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

View on Chrome Web Store

Other tools I've built:

View on Chrome Web Store
View on Chrome Web Store

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

SHOTA — Mon, 20 Apr 2026 15:16:38 +0000

The most common complaint I hear from office workers who do data entry: "I have to copy from System A and paste into System B, field by field, a hundred times a day."

Clipboard managers help a little. Spreadsheet macros help for some cases. But the fundamental problem — transferring structured data between two web UIs — has no good solution that doesn't involve custom automation or browser developer tools.

I spent a week building DataBridge, a Chrome extension that lets you visually map elements between two pages and transfer data in one click.

The Core Idea

Instead of writing a script that targets specific selectors, DataBridge lets you:

Open the source page and click each field you want to copy — the extension records the element and its current value
Open the destination page and click the corresponding input field
Save that mapping as a template
On future visits, load the template and hit Transfer — all values fill in automatically

The mapping is visual: you click on elements in the page, not on CSS selectors in a config file. No code required.

Technical Architecture

The extension uses three communicating pieces:

popup.html          — UI for managing templates and starting transfer
content-script.ts   — Injected into pages for element selection and fill
background.ts       — Message broker + template storage

The hard part is that source and destination are often in different tabs. Chrome extension messaging handles inter-tab communication:

// In content script: broadcast value captures to background
async function captureElement(element: HTMLElement): Promise<CapturedField> {
  const rect = element.getBoundingClientRect();
  const field: CapturedField = {
    selector: buildRobustSelector(element),
    value: extractValue(element),
    label: inferLabel(element),
    position: { x: rect.left, y: rect.top },
    timestamp: Date.now(),
  };

  await chrome.runtime.sendMessage({
    type: 'FIELD_CAPTURED',
    field,
    tabId: (await chrome.tabs.getCurrent())?.id,
  });

  return field;
}

Building a Robust Selector

This is the most fragile part of any DOM automation tool. A CSS selector that works today might break tomorrow when the page updates. DataBridge builds a layered selector strategy:

function buildRobustSelector(element: HTMLElement): SelectorChain {
  const strategies: SelectorStrategy[] = [];

  // 1. Stable attributes (most reliable)
  for (const attr of ['id', 'name', 'data-testid', 'aria-label']) {
    const val = element.getAttribute(attr);
    if (val) {
      strategies.push({ type: attr, value: val, confidence: 'high' });
    }
  }

  // 2. Label association (for form fields)
  const label = findAssociatedLabel(element);
  if (label) {
    strategies.push({
      type: 'label-text',
      value: label.textContent?.trim() ?? '',
      confidence: 'medium',
    });
  }

  // 3. Position-based fallback (least reliable)
  strategies.push({
    type: 'nth-child-path',
    value: buildNthChildPath(element),
    confidence: 'low',
  });

  return { strategies, preferredType: strategies[0]?.type };
}

At transfer time, it tries each strategy in order and uses the first match. The confidence level is shown in the UI so users know which mappings are fragile.

Handling Different Input Types

Web forms are messy. DataBridge handles:

function fillElement(element: HTMLElement, value: string): boolean {
  if (element instanceof HTMLSelectElement) {
    // Match by value or visible text
    const option = Array.from(element.options).find(
      o => o.value === value || o.text === value
    );
    if (option) {
      element.value = option.value;
      element.dispatchEvent(new Event('change', { bubbles: true }));
    }
    return !!option;
  }

  if (element instanceof HTMLInputElement) {
    if (element.type === 'checkbox' || element.type === 'radio') {
      element.checked = value === 'true' || value === element.value;
      element.dispatchEvent(new Event('change', { bubbles: true }));
      return true;
    }
    // Text inputs — use native input value setter for React compatibility
    const nativeInputValueSetter = Object.getOwnPropertyDescriptor(
      window.HTMLInputElement.prototype,
      'value'
    )?.set;
    nativeInputValueSetter?.call(element, value);
    element.dispatchEvent(new InputEvent('input', { bubbles: true }));
    element.dispatchEvent(new Event('change', { bubbles: true }));
    return true;
  }

  if (element.contentEditable === 'true') {
    element.textContent = value;
    element.dispatchEvent(new InputEvent('input', { bubbles: true }));
    return true;
  }

  return false;
}

The React compatibility trick (using the native value setter + dispatching synthetic events) is essential — React's synthetic event system ignores direct element.value = assignments on controlled inputs.

Template Storage

Templates are stored in chrome.storage.local with a simple schema:

interface MappingTemplate {
  id: string;
  name: string;
  sourceUrl: string;  // Used to auto-suggest on page load
  targetUrl: string;
  fields: FieldMapping[];
  createdAt: number;
  useCount: number;
}

The sourceUrl and targetUrl are stored as glob patterns so templates trigger on similar pages (e.g., https://app.example.com/orders/* matches all order pages).

What It's Good For

DataBridge works best for repetitive, structured workflows: copying order data from an ERP into a CRM, filling government forms from a spreadsheet, migrating records between two SaaS tools that don't have a native integration.

It doesn't work well for pages with heavy client-side routing that replaces the DOM on navigation (the mapped selectors become stale). That's a known limitation I'm working on for a future version using MutationObserver to reattach selectors after navigation.

The extension is live on the Chrome Web Store.

Built with WXT + React + TypeScript. Dark mode UI with element-level visual selection.

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

SHOTA — Mon, 20 Apr 2026 00:00:00 +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 Font Inspector Chrome Extension That Actually Identifies Japanese Fonts

SHOTA — Sat, 18 Apr 2026 14:40:39 +0000

There is a specific frustration that every frontend developer knows: you open a Japanese website, see a beautiful typeface, open DevTools, and font-family gives you "Hiragino Kaku Gothic ProN", "Noto Sans JP", "Meiryo", sans-serif. Which of those is actually rendering?

The browser picks the first available font from the stack. DevTools tells you the declared stack, not the resolved font. For Latin scripts this is usually fine — most machines have similar system fonts. For Japanese, it matters a lot. The difference between Noto Sans JP and Hiragino Kaku Gothic ProN is significant to a designer.

So I built Japanese Font Finder to answer that question in one click.

What It Does

Japanese Font Finder is a Chrome extension that lets you click any element on a page and get:

The actually rendered font (not the declared stack)
Full computed styles: size, weight, line-height, letter-spacing
Color and background color in HEX
Whether it's a web font, and which service serves it (Google Fonts, Adobe Fonts, etc.)
Copy-ready CSS font-family syntax

For pages with multiple typefaces, there's also a page scan mode (Ctrl+Shift+A) that lists every distinct font in use.

The Core Technical Problem

Determining which font is actually rendering is harder than it sounds. The CSS font-family property is a prioritized list; the browser tries each one and uses the first it can load. window.getComputedStyle().fontFamily still returns the full declared list, not the winner.

The standard solution is a Canvas-based width comparison:

function isFontAvailable(fontName: string): boolean {
  const fallbackFonts = ['serif', 'sans-serif', 'monospace'];
  if (fallbackFonts.includes(fontName.toLowerCase())) return true;

  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');
  if (!ctx) return false;

  // Use Japanese characters in the test string — critical for CJK fonts
  const testText = 'abcdefghijklmnopqrstuvwxyz0123456789日本語テスト';

  for (const baseFont of ['monospace', 'sans-serif', 'serif']) {
    ctx.font = `72px ${baseFont}`;
    const baseWidth = ctx.measureText(testText).width;

    ctx.font = `72px "${fontName}", ${baseFont}`;
    const testWidth = ctx.measureText(testText).width;

    if (baseWidth !== testWidth) return true;
  }
  return false;
}

The key insight: include Japanese characters in your test string. Canvas glyph rendering for CJK fonts differs enough from Latin fallbacks to produce width differences even when the font family name matches a system font.

Walk the declared stack, check each font with this method, and return the first available one.

Handling Web Font Detection

For web fonts it's not enough to know the name — you want to know the service. I detect this by inspecting loaded stylesheets:

function detectWebFontService(): WebFontService | null {
  const sheets = Array.from(document.styleSheets);
  for (const sheet of sheets) {
    try {
      const href = sheet.href ?? '';
      if (href.includes('fonts.googleapis.com')) return 'google-fonts';
      if (href.includes('use.typekit.net')) return 'adobe-fonts';
      if (href.includes('fonts.bunny.net')) return 'bunny-fonts';
    } catch {
      // Cross-origin stylesheet — skip
    }
  }
  return null;
}

Cross-origin stylesheets throw a SecurityError when you try to read cssRules, so you have to catch and skip. The href check is safe and catches the major services.

Multi-Script Font Analysis

One feature I added later: full-page font scanning that groups results by script system. Japanese pages often use different fonts for CJK characters vs. Latin text — the unicode-range descriptor in @font-face handles this. The scan surfaces these distinctions so you see the complete picture.

async function scanPageFonts(): Promise<MultiScriptFontResult> {
  const walker = document.createTreeWalker(
    document.body,
    NodeFilter.SHOW_ELEMENT
  );

  const fontSet = new Map<string, FontInfo>();
  let node: Node | null;

  while ((node = walker.nextNode())) {
    const el = node as HTMLElement;
    // Skip invisible elements
    const style = getComputedStyle(el);
    if (style.display === 'none' || style.visibility === 'hidden') continue;

    const info = detectFont(el);
    const key = `${info.renderedFont}::${info.fontSize}::${info.fontWeight}`;
    if (!fontSet.has(key)) {
      fontSet.set(key, info);
    }
  }

  return {
    fonts: Array.from(fontSet.values()),
    count: fontSet.size,
  };
}

The Japanese Font Problem Specifically

Most font detection tools are built for Latin scripts. Japanese is different in a few ways:

System fonts vary by OS: macOS has Hiragino. Windows has Meiryo and Yu Gothic. Android has Noto. iOS Safari renders San Francisco/Helvetica Neue for Latin but Hiragino for CJK.
Font stacks are long: A well-written Japanese font stack might be 8-10 fonts deep to handle macOS/Windows/Linux/mobile consistently.
Subsetting is common: Web fonts for Japanese are often subset by unicode-range to avoid loading 10MB+ files. The Noto Sans JP you see on a page might actually be a subset that only covers hiragana/katakana.

Japanese Font Finder surfaces all of this: which font is rendering, whether it's a web font subset, and what the fallback chain looks like.

Keyboard Shortcuts

Ctrl+Shift+F (Cmd+Shift+F on Mac): Toggle click-to-inspect mode
Ctrl+Shift+A (Cmd+Shift+A): Full page font scan

The extension is available on the Chrome Web Store. If you do any work with Japanese typography — or just want a faster way to inspect fonts on any page — give it a try.

Built with TypeScript + Vite. Canvas API for font detection, TreeWalker for page scanning.

I Built a Chrome Extension That Identifies Japanese Fonts on Any Web Page

SHOTA — Sat, 18 Apr 2026 00:00:00 +0000

If you have ever inspected a Japanese website and tried to figure out which font is being used, you know the pain. You open DevTools, find the element, look at the computed font-family, and see something like "Hiragino Kaku Gothic ProN", "Yu Gothic", "Meiryo", sans-serif. That tells you the CSS declaration, but not which font is actually rendering on screen. And even if you figure that out, you might not know whether it is a system font, a Google Font, or a commercial font from Morisawa or Fontworks.

I built Japanese Font Finder to solve this problem. It is a Chrome extension that lets you hover over any text element on a web page and instantly see which font is actually being rendered, with detailed metadata for Japanese fonts -- including the Japanese name, category, vendor, license type, and links to download or purchase the font.

The extension ships with a database of over 150 Japanese fonts covering system fonts across Windows, macOS, and Linux, over 60 Google Fonts with Japanese support, and commercial fonts from Morisawa, Fontworks, TypeBank, Iwata, and other major Japanese type foundries.

The Core Problem: CSS font-family vs. Rendered Font

The fundamental technical challenge is the gap between what CSS declares and what the browser actually renders. A typical Japanese website might have this in its stylesheet:

body {
  font-family: "Noto Sans JP", "Hiragino Kaku Gothic ProN",
               "Yu Gothic", "Meiryo", sans-serif;
}

This is a font stack -- an ordered list of preferences. The browser walks down the list and uses the first font that is available on the user's system. If the user is on macOS, they will probably see Hiragino Kaku Gothic ProN. On Windows, Yu Gothic or Meiryo. If the page loads Noto Sans JP from Google Fonts, that one wins.

window.getComputedStyle(element).fontFamily only gives you back the CSS declaration, not the rendered result. To figure out which font is actually being used, you need a different approach.

Font Detection via Canvas Measurement

The technique I use is Canvas-based font detection. The idea is simple: render a test string in the candidate font and in a known baseline font, then compare the measured widths. If they differ, the candidate font is available and being used.

function isFontAvailable(fontName: string): boolean {
  const fallbackFonts = [
    'serif', 'sans-serif', 'monospace',
    'cursive', 'fantasy', 'system-ui'
  ];
  if (fallbackFonts.includes(fontName.toLowerCase())) {
    return true;
  }

  const canvas = document.createElement('canvas');
  const context = canvas.getContext('2d');
  if (!context) return false;

  const testText =
    'abcdefghijklmnopqrstuvwxyz0123456789日本語テスト';
  const baseFonts = ['monospace', 'sans-serif', 'serif'];

  for (const baseFont of baseFonts) {
    context.font = `72px ${baseFont}`;
    const baselineWidth = context.measureText(testText).width;

    context.font = `72px "${fontName}", ${baseFont}`;
    const testWidth = context.measureText(testText).width;

    if (baselineWidth !== testWidth) {
      return true;
    }
  }

  return false;
}

A few important details:

The test string includes both Latin and Japanese characters. Some fonts only cover one script, so testing with both prevents false negatives. If a font only has Japanese glyphs, the Latin characters will fall through to the baseline, but the Japanese characters will cause a width difference.
We test against multiple baselines. A font might happen to have the same metrics as one baseline but not others. Testing against monospace, sans-serif, and serif catches more cases.
We use a large font size (72px). Larger sizes amplify width differences, making detection more reliable. At small sizes, subpixel rounding could mask a genuine difference.
Generic font families are skipped. If the candidate is sans-serif, serif, or another CSS generic, we just report it as-is since there is nothing to measure against.

The detectFont function wraps this into a complete pipeline that extracts all typography information from an element:

export function detectFont(element: HTMLElement): FontInfo {
  const styles = window.getComputedStyle(element);

  return {
    fontFamily: styles.fontFamily,
    renderedFont: getRenderedFont(element, styles.fontFamily),
    fontSize: styles.fontSize,
    fontWeight: styles.fontWeight,
    fontStyle: styles.fontStyle,
    lineHeight: styles.lineHeight,
    letterSpacing: styles.letterSpacing,
    color: styles.color,
    colorHex: rgbToHex(styles.color),
    backgroundColor: getBackgroundColor(element),
    backgroundColorHex: rgbToHex(getBackgroundColor(element)),
    isWebFont: detectWebFont(styles.fontFamily),
    webFontService: detectWebFontService(),
  };
}

Multi-Script Font Detection: Japanese vs. Latin

One of the most interesting challenges in Japanese web typography is that many sites use different fonts for Japanese and Latin characters. A CSS font stack like Arial, "Hiragino Sans", sans-serif will render English text in Arial but Japanese text in Hiragino Sans, because Arial does not contain Japanese glyphs.

The Pro version of the extension includes a multi-script detection feature that separately identifies which font is rendering Japanese characters and which is rendering Latin characters:

export function detectMultiScriptFonts(
  _element: HTMLElement, fontStack: string
): MultiScriptFontResult {
  const fonts = fontStack.split(',')
    .map(f => f.trim().replace(/['"]/g, ''));

  const canvas = document.createElement('canvas');
  const context = canvas.getContext('2d');
  if (!context) {
    return {
      japanese: null, latin: null, isMultiScript: false
    };
  }

  const japaneseTest = '日本語テスト東京あいう';
  const latinTest = 'ABCDEFGHabcdefgh0123456789';

  let japaneseFont: string | null = null;
  let latinFont: string | null = null;

  for (const font of fonts) {
    for (const baseFont of baseFonts) {
      context.font = `72px ${baseFont}`;
      const jaBase = context.measureText(japaneseTest).width;
      const latBase = context.measureText(latinTest).width;

      context.font = `72px "${font}", ${baseFont}`;
      const jaTest = context.measureText(japaneseTest).width;
      const latTest = context.measureText(latinTest).width;

      if (!japaneseFont && jaBase !== jaTest) {
        japaneseFont = font;
      }
      if (!latinFont && latBase !== latTest) {
        latinFont = font;
      }

      if (japaneseFont && latinFont) break;
    }
    if (japaneseFont && latinFont) break;
  }

  return {
    japanese: japaneseFont,
    latin: latinFont,
    isMultiScript: japaneseFont !== null
      && latinFont !== null
      && japaneseFont !== latinFont,
  };
}

The key insight is that we use separate test strings for each script and walk through the font stack independently. The first font in the stack that affects the width of the Japanese test string is the one rendering Japanese text. The first one that affects the Latin test string handles Latin text. If they are different, we flag it as a multi-script configuration.

The Japanese Font Database

The extension includes a curated database of over 150 Japanese fonts organized into three categories: system fonts, Google Fonts, and commercial fonts.

Each entry includes metadata relevant to designers and developers:

// System fonts (Windows, macOS, Linux)
'Noto Sans JP': {
  ja: 'Noto Sans JP',
  category: 'Gothic',
  license: 'open-source',
  commercialUse: true,
  downloadUrl: 'https://fonts.google.com/...'
},

// Commercial fonts (Morisawa)
'A-OTF Shin Go Pro': {
  ja: 'Shin Go',
  vendor: 'Morisawa',
  category: 'Gothic',
  license: 'commercial',
  commercialUse: false,
  price: 'Included in Morisawa Passport'
},

The system font section covers fonts bundled with Windows (Yu Gothic, Meiryo, BIZ UD Gothic, UD Digi Kyokasho, and more), macOS (Hiragino Sans, Hiragino Mincho, Toppan Bunkyu, Klee, and more), and Linux (IPA Gothic, Takao, VL Gothic, Sazanami, and more).

The Google Fonts section includes the Noto family, M PLUS family, Kosugi, Sawarabi, Shippori, Zen, Kaisei, Yuji, and dozens of display and handwriting fonts.

The commercial section covers major Japanese type foundries: Morisawa (Shin Go, Ryumin, Gothic MB101), Fontworks (Tsukushi, Rodin, Matisse), TypeBank, Iwata, Motoya, and Screen (Hiragino).

Font name lookup supports both exact matching and partial matching, because font names appear in different formats across different contexts:

export function getJapaneseFontInfo(
  fontName: string
): JapaneseFontInfo | null {
  const normalized = fontName.replace(/['"]/g, '').trim();

  for (const category of Object.values(JAPANESE_FONTS)) {
    if (category[normalized]) {
      return category[normalized];
    }
  }

  for (const category of Object.values(JAPANESE_FONTS)) {
    for (const [key, value] of Object.entries(category)) {
      if (normalized.includes(key) || key.includes(normalized)) {
        return value;
      }
    }
  }

  return null;
}

Web Font Service Detection

The extension detects which web font service a page is using by looking for characteristic elements in the DOM:

function detectWebFontService(): WebFontService | undefined {
  const googleFontsLink = document.querySelector(
    'link[href*="fonts.googleapis.com"]'
  );
  if (googleFontsLink) return 'google';

  const adobeScript = document.querySelector(
    'script[src*="use.typekit.net"]'
  );
  if (adobeScript) return 'adobe';

  const typeSquareScript = document.querySelector(
    'script[src*="typesquare.com"]'
  );
  if (typeSquareScript) return 'typesquare';

  const fontPlusScript = document.querySelector(
    'script[src*="fontplus.jp"]'
  );
  if (fontPlusScript) return 'fontplus';

  return undefined;
}

This covers the four main web font services used in Japan: Google Fonts, Adobe Fonts (Typekit), TypeSquare (by Morisawa), and FONTPLUS (by SB Technology). Knowing the service helps users understand the licensing situation -- a font served via Google Fonts is free to use, while one from TypeSquare requires a subscription.

The Inspector UI: Hover, Click, Scan

The extension has three interaction modes:

Hover mode activates when you click the extension icon or press Ctrl+Shift+F. Moving your mouse over any text element shows a tooltip with the font name, size, weight, and color. The element gets a visual highlight so you can see exactly what you are inspecting.

Click mode captures a click on the hovered element and opens a detailed panel with the full font information, Japanese name, category, web font service, similar font suggestions, font pairing recommendations, and links to download or purchase the font.

Page scan mode (Ctrl+Shift+A) scans every text element on the page and produces a summary of all fonts used, sorted by frequency of use. This is useful for getting a quick overview of a site's typography system.

The content script manages these modes with clean activation and deactivation:

function activateInspector(): void {
  document.body.classList.add('jff-active');
  tooltip = createTooltip();

  document.addEventListener('mouseover', handleMouseOver, true);
  document.addEventListener('mouseout', handleMouseOut, true);
  document.addEventListener('click', handleClick, true);
  document.addEventListener('keydown', handleKeyDown, true);

  refreshUsageCache();
  showActivationMessage();
}

function deactivateInspector(): void {
  document.body.classList.remove('jff-active');

  document.removeEventListener('mouseover', handleMouseOver, true);
  document.removeEventListener('mouseout', handleMouseOut, true);
  document.removeEventListener('click', handleClick, true);
  document.removeEventListener('keydown', handleKeyDown, true);

  removeTooltip();
  removeDetailPanel();
  removeHighlight();
}

All event listeners are registered with useCapture: true to intercept events before the page's own handlers, and click events call preventDefault() and stopPropagation() to prevent navigation while the inspector is active.

Font Highlighting

There is also a font highlighting feature that visually marks all elements on the page that use a specific font. This is triggered from the popup's page scan results -- click on a font name, and every element using that font gets a colored outline:

function highlightFontElements(fontName: string): void {
  clearFontHighlight();

  const walker = document.createTreeWalker(
    document.body,
    NodeFilter.SHOW_ELEMENT,
    null
  );

  const elements: HTMLElement[] = [];
  let node: Node | null;

  while ((node = walker.nextNode())) {
    const element = node as HTMLElement;
    if (isOwnElement(element)) continue;
    if (!hasTextContent(element)) continue;

    const style = window.getComputedStyle(element);
    if (style.fontFamily.includes(fontName)) {
      elements.push(element);
    }
  }

  elements.forEach((el, index) => {
    el.classList.add('jff-font-highlight');
    el.setAttribute(
      'data-jff-highlight-index', String(index + 1)
    );
  });

  if (elements.length > 0) {
    elements[0].scrollIntoView({
      behavior: 'smooth', block: 'center'
    });
  }
}

The TreeWalker API is more efficient than querySelectorAll('*') for traversing the DOM when you need to check computed styles on each element. It also makes it easy to skip the extension's own UI elements to avoid infinite recursion.

Freemium with Usage Limiting

The extension uses a freemium model. Free users get 15 font detections per day. After that, a polite upgrade modal appears. The usage counter resets daily and is tracked in chrome.storage.local.

The usage check happens in two places: a cached synchronous check during hover (to avoid lag) and an authoritative async check on click (to prevent stale cache from allowing extra detections):

// During hover - fast cached check
if (usageLimitReached) return;

// During click - authoritative check with increment
const response = await chrome.runtime.sendMessage({
  action: 'checkUsageLimit'
});
if (!response?.allowed) {
  usageLimitReached = true;
  hideTooltip();
  showUpgradeModal();
  return;
}

This two-tier approach keeps the hover experience smooth while ensuring accurate enforcement on actual font inspections.

Internationalization

The extension supports English and Japanese through a lightweight i18n system. All user-facing strings go through a t() function that looks up translations based on the user's language setting:

const overlay = document.createElement('div');
overlay.innerHTML = `
  <h2>${t('upgrade.title')}</h2>
  <p>${t('upgrade.desc')}</p>
  <button id="jff-upgrade-cta">
    ${escapeHtml(t('upgrade.cta'))}
  </button>
`;

All dynamic content is escaped with escapeHtml() before insertion to prevent XSS, even for strings that come from the extension's own translation files. Defense in depth.

Technical Decisions and Trade-offs

Canvas detection has limitations. It measures text width, not individual glyphs. Two fonts with similar metrics for the test string could produce false matches. Using a longer test string with both Latin and Japanese characters minimizes this risk, but it is not eliminated.

The font database is manually curated. There is no API for getting the full list of fonts installed on a user's system (and for good reason -- it would be a fingerprinting vector). The database covers the fonts most commonly encountered on Japanese websites, which means obscure custom fonts might show as "unknown."

Bundle size matters. The Japanese font database with 150+ entries adds weight to the content script. I kept the data structure flat and avoided importing external font databases to stay under Chrome Web Store's recommended limits.

Event capture phase is necessary. Without useCapture: true, click events on links and buttons would navigate away before the extension could intercept them. The capture phase ensures the extension gets first shot at every event.

What I Learned

Building a font inspection tool for Japanese web content revealed some interesting aspects of how browsers handle CJK typography:

Font fallback in CJK is more complex than Latin. A single element can use three different fonts for Japanese, Latin, and numeric characters, all determined by the browser's fallback behavior.
Japanese web font services are a distinct ecosystem. TypeSquare and FONTPLUS are major players in Japan but virtually unknown outside it. Supporting them matters for the target audience.
Commercial font identification is valuable. Designers often spot a font they like on a website and want to know what it is. Telling them it is Morisawa Shin Go and that they need a Morisawa Passport subscription is actionable information.
The Canvas API is surprisingly useful for font detection. It gives you rendering-level information that is not available through any other standard web API.

If you work with Japanese websites -- whether as a designer, developer, or typographer -- give it a try.

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

Other tools I've built:

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

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 Transfer Data Between Web Pages Without Copy-Paste ? Free Chrome Extension

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

The Mental Model: Numbered Badges

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,
    },
  });
}

CSS Selector Generation: The Hard Problem

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;
}

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

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 }));
  }
}

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.

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;
}

The Side Panel Architecture

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

// 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 Notepad Mode

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

Technical Challenges and Solutions

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)

Try It Out

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

Free Chrome Extension for SEO Analysis ? Page Score, 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 Without Leaving It ? 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.

How to Auto-Generate Step-by-Step Browser Guides ? Free Screenshot Extension

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

Best Chrome Extension for Code Snippets ? VS Code-Style Snippet Manager

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

How to Block Low-Quality News on Yahoo Japan - Free Chrome Extension

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 Chrome Extension

ZenRead Chrome Extension